Ein Sprachmodell schreibt Ihnen in zehn Sekunden ein vollständiges JSON-LD für Ihre Website. Das ist der einfache Teil. Der schwierige Teil kommt danach: KI-generiertes Schema Markup sieht fast immer korrekt aus und ist es oft nicht. Erfundene Properties, falsche Typen, Verweise ins Leere und Angaben, die auf der Seite gar nicht stehen, fallen im Chat nicht auf, weil die JSON-Syntax stimmt.
Deshalb geht es hier um beides: die Prompts, die brauchbaren Code liefern, und die Prüfung, ohne die der Code nichts wert ist. Unten steht ein vollständiger Block zum Kopieren, daneben die typischen Fehler, die Modelle genau an dieser Stelle einbauen.
Warum Schema Markup für SEO entscheidend ist
Schema Markup übersetzt menschenlesbare Informationen in maschinenlesbare Daten. Eine Adresse, eine Bewertung, ein Preis oder eine Öffnungszeit wird dadurch eindeutig als das gekennzeichnet, was sie ist. Suchmaschinen müssen den Zusammenhang dann nicht mehr aus dem Fließtext raten.
Der sichtbare Vorteil sind Rich Snippets: Sternebewertungen, Preise, Öffnungszeiten direkt im Suchergebnis. Der zweite Vorteil ist seit 2026 mindestens genauso wichtig. AI Overviews und Chat-Antworten greifen auf strukturierte Daten zurück, wenn sie eine Aussage über ein Unternehmen, ein Produkt oder einen Artikel absichern wollen. Welche Typen dabei bevorzugt ausgewertet werden, haben wir in einer eigenen Auswertung zu Schema.org für KI-Systeme zusammengetragen.
Nicht jede Seite profitiert gleich stark. Ein Onlineshop holt sich über Product und Offer die Preisangabe direkt ins Suchergebnis, eine Praxis über LocalBusiness die Öffnungszeiten, ein Blog über Article vor allem die saubere Zuordnung von Autor und Datum. Google listet in seiner Dokumentation rund 30 Rich-Result-Typen, für die meisten Websites sind davon zwei oder drei relevant. Die Lücke im Suchergebnis ist trotzdem auffällig: Wer nur den blauen Link hat, steht neben Ergebnissen mit doppelt so viel Fläche.
Wichtig ist die Reihenfolge: Erst müssen Sie wissen, welche Typen Ihre Seite überhaupt braucht, dann lohnt sich die Automatisierung. Die Grundlagen zu Schema.org und strukturierten Daten sollten Sie also gelesen haben, bevor Sie ein Modell Code schreiben lassen. Sonst prüfen Sie etwas, das Sie nicht beurteilen können.
Wie Sprachmodelle Schema Markup erzeugen, Stand Q4 2026
Modelle kennen die schema.org-Vokabulare aus ihren Trainingsdaten. Das war im Frühjahr die einzige Quelle und der Grund für die meisten Fehler. Seitdem hat sich eine Sache verändert, die praktisch zählt: Die aktuellen Chat-Modelle von OpenAI, Anthropic und Google können während der Antwort im Web nachschlagen und Code ausführen. Ein Modell, das die Google-Dokumentation zu Rich Results währenddessen öffnen darf, liefert deutlich seltener veraltete Pflichtfelder als eines, das aus dem Gedächtnis antwortet.
Für Sie heißt das: Nicht die Modellversion entscheidet, sondern der Zugriff. Modellnamen wechseln inzwischen schneller, als schema.org sich ändert. Schalten Sie die Websuche ein und geben Sie die Google-Dokumentationsseite zum gewünschten Rich-Result-Typ als Quelle mit in den Prompt.
Stärken. Schnelle Generierung, saubere JSON-Syntax, Kenntnis der gängigen Typen, zuverlässige Verschachtelung bei einfachen Strukturen, gute Übersetzung von Tabellen und CSV-Zeilen in JSON-LD.
Schwächen. Erfundene Property-Namen, überholte Google-Anforderungen, fehlende Pflichtfelder, Verschachtelung auf der falschen Ebene bei mehrstufigen Typen, und die grundsätzliche Neigung, jedes Feld zu füllen, auch wenn es die Daten dafür nicht gibt.
Der letzte Punkt ist der teuerste. Fragen Sie nach einem LocalBusiness-Block, bekommen Sie oft ungefragt ein „aggregateRating" mit erfundenen 4,9 Sternen bei 127 Bewertungen dazu.
Den Wissensstand eines Modells können Sie in einem Satz testen, bevor Sie ihm Ihre Daten geben: Fragen Sie, welche Rich-Result-Typen Google aktuell für die Websuche unterstützt und seit wann. Kommt eine Aufzählung mit HowTo und FAQ als selbstverständlichen Snippet-Typen zurück, arbeitet das Modell aus altem Gedächtnis, und Sie prüfen den Output besser doppelt.
Bei den Anforderungen selbst hat Google in den vergangenen Jahren mehr gestrichen als ergänzt, und die Modelle hängen genau da hinterher. FAQ-Rich-Results zeigt Google nur noch für Behörden- und Gesundheitsseiten, HowTo-Snippets wurden ganz eingestellt. Ein Modell schlägt Ihnen FAQPage und HowTo trotzdem als Weg zum Rich Snippet vor. Beide Typen bleiben sinnvoll, weil sie den Inhalt maschinenlesbar machen, aber die Erwartung an das Suchergebnis stimmt nicht mehr. Welches Werkzeug wie oft danebenliegt, ordnet unser Vergleich der KI-Tools im SEO-Alltag ein.
Prompt-Vorlagen für die wichtigsten Schema-Typen
Der Unterschied zwischen unbrauchbarem und einsatzbereitem Code liegt fast vollständig im Prompt. Geben Sie alle Daten mit, nennen Sie das Zielformat und verbieten Sie ausdrücklich, was Sie nicht haben.
LocalBusiness. Firmenname, Straße, PLZ, Stadt, Telefonnummer im internationalen Format, URL, Öffnungszeiten je Wochentag, der passende Untertyp nach schema.org. Bitten Sie um PostalAddress und GeoCoordinates als Unterobjekte und um einen stabilen „@id"-Wert. Für lokale Unternehmen ist das LocalBusiness Schema die Grundlage, auf die alles andere verweist.
Product. Produktname, Beschreibung, Preis mit Währung, Verfügbarkeit, Marke, GTIN oder SKU, Produkt-URL. Sagen Sie dazu, ob es ein Angebot ist oder mehrere Varianten. Bewertungen nur dann, wenn sie auf der Seite tatsächlich stehen.
FAQPage. Fragen und Antworten vollständig auflisten, ohne HTML in den Antworten. Wichtig ist der Hinweis, dass jede Frage-Antwort-Kombination genau so auch auf der Seite steht. Modelle formulieren die Antworten sonst gern eleganter, und damit weicht das Markup vom Text ab.
Article und BlogPosting. Titel, Autor beziehungsweise herausgebende Organisation, Veröffentlichungs- und Aktualisierungsdatum, Beschreibung, Bild-URL. Fordern Sie ISO-8601-Datumsangaben mit Zeitzone an, sonst kommt „19. März 2026" zurück.
Der Satz, der jeden Prompt verbessert. „Verwende ausschließlich Properties, die in der schema.org-Spezifikation existieren. Lass jedes Feld weg, für das ich keine Daten geliefert habe. Erfinde nichts."
Wichtig: Geben Sie echte Daten an, keine Platzhalter. Schreiben Sie „Zahnarztpraxis Dr. Müller, Hauptstraße 15, 90402 Nürnberg" statt „Firmenname, Adresse, Stadt". Modelle füllen Platzhalter mit erfundenen Werten, und die übersehen Sie beim Kopieren zuverlässig.
Bei hunderten Seiten arbeiten Sie nicht Block für Block, sondern über Vorlagen. Lassen Sie ein Template je Typ erzeugen, prüfen Sie dieses eine Template gründlich und geben Sie es danach als Muster mit: „Gleiches Format wie dieses Beispiel, andere Daten." Für Produkt- oder Filialdaten aus einer CSV lohnt sich der Umweg über ein Skript, das die Zeilen in JSON-LD wandelt. Dann prüfen Sie einmal das Skript statt tausend Blöcke. Wie sich das sauber in ein CMS oder einen Build einhängen lässt, steht in unserer Anleitung zur technischen Umsetzung von Schema.org.
Ein vollständiges Beispiel und was Modelle daran falsch machen
Der folgende Block ist vollständig, validiert und kopierbar. Er beschreibt eine Zahnarztpraxis und verknüpft zwei Knoten über „@id", damit später jede Unterseite auf dieselbe Praxis verweisen kann statt eine zweite Organisation anzulegen.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Dentist",
"@id": "https://www.beispielpraxis.de/#praxis",
"name": "Zahnarztpraxis Dr. Müller",
"url": "https://www.beispielpraxis.de/",
"telephone": "+4991112345670",
"image": "https://www.beispielpraxis.de/images/praxis.jpg",
"address": {
"@type": "PostalAddress",
"streetAddress": "Hauptstraße 15",
"postalCode": "90402",
"addressLocality": "Nürnberg",
"addressCountry": "DE"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 49.4521,
"longitude": 11.0767
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday"],
"opens": "08:00",
"closes": "18:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": "Friday",
"opens": "08:00",
"closes": "13:00"
}
]
},
{
"@type": "WebPage",
"@id": "https://www.beispielpraxis.de/#webpage",
"url": "https://www.beispielpraxis.de/",
"name": "Zahnarztpraxis Dr. Müller in Nürnberg",
"about": { "@id": "https://www.beispielpraxis.de/#praxis" },
"inLanguage": "de-DE"
}
]
}
</script>Und so sieht dasselbe Markup aus, wenn es ungeprüft aus dem Chat kommt. Vier Zeilen, vier verschiedene Fehlerarten:
"telephone": "0911 1234567",
"businessHours": "Mo-Do 8-18 Uhr",
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.9",
"reviewCount": "127"
},
"about": { "@id": "https://www.beispielpraxis.de/#organization" }Zeile 1, falsches Format. Die Telefonnummer gehört international geschrieben. Google akzeptiert die lokale Schreibweise zwar, verknüpft sie aber schlechter mit dem Unternehmenseintrag.
Zeile 2, erfundene Property. „businessHours" existiert in schema.org nicht. Richtig ist „openingHoursSpecification" mit eigenem Unterobjekt. Ähnliche Erfindungen: „pricingRange" statt „priceRange", „companyName" statt „name". Die Validatoren melden das als nicht erkannte Property, und im Zweifel ignoriert Google den ganzen Block.
Zeile 3, Angaben ohne Deckung. Das Modell hat sich Bewertung und Anzahl ausgedacht. Wenn diese Sterne nirgends auf der Seite stehen, ist das kein Schönheitsfehler, sondern ein Verstoß gegen Googles Richtlinien für strukturierte Daten. Alles, was im Markup steht, muss sichtbar auf der Seite stehen. Im schlimmsten Fall folgt eine manuelle Maßnahme, und dann verschwinden die Rich Results für die gesamte Domain, nicht nur für die eine Seite.
Zeile 4, Verweis ins Leere. Der „about"-Verweis zeigt auf „#organization", der Knoten oben heißt aber „#praxis". Solche @id-Verweise brechen still. Die Syntax ist gültig, der Graph zerfällt trotzdem in zwei unverbundene Teile. Kein Tool schreit hier laut, Google verknüpft die Angaben einfach nicht.
KI-generiertes Schema Markup validieren
Die Prüfung dauert wenige Minuten und ist der Schritt, der über Nutzen oder Schaden entscheidet. Aus unserer Arbeit an Kundenprojekten ist das eher die Regel als die Ausnahme: Rund jeder dritte ungeprüfte KI-Block fällt bei uns beim ersten Test durch, meist wegen erfundener Properties oder fehlender Pflichtfelder.
Rich Results Test. Zeigt, ob Google aus Ihrem Markup ein Rich Result bauen würde. Googles Anforderungen sind enger als der schema.org-Standard, deshalb ist das der erste Test.
Schema Markup Validator. Prüft gegen den vollständigen schema.org-Standard und findet genau die Fehler, die der Rich Results Test nicht anzeigt, weil sie keinen Rich-Result-Typ betreffen. Erfundene Properties fallen hier auf.
Search Console. Nach dem Livegang zeigt der Bereich Verbesserungen, was Google tatsächlich gelesen hat. Erst dieser Bericht beweist, dass das Markup im gerenderten HTML ankommt und nicht von einem Skript verschluckt wird.
Vier Dinge prüft kein Tool für Sie. Erstens die Deckung: Steht jede Angabe aus dem Markup auch im sichtbaren Text? Zweitens die Auflösung der @id-Werte, dafür reicht ein Blick, ob jeder Verweis auf einen Knoten zeigt, den es im selben Graph gibt. Drittens Doppel-Markup: Viele CMS-Plugins schreiben bereits ein Organization- oder WebSite-Schema, das eigene kommt dann als zweite Organisation dazu. Viertens die Aktualität, denn Preise und Öffnungszeiten im Markup veralten schneller als der Fließtext.
Ein Fehler taucht dabei erst spät auf und kostet Wochen: Das Markup steht im Quelltext, aber Google sieht es nicht, weil es erst per JavaScript nachgeladen wird oder weil ein Consent-Banner das Skript blockiert. Der Rich Results Test rendert die Seite und meldet das, wenn Sie die Live-URL prüfen statt den kopierten Code. Prüfen Sie deshalb immer beides, erst den Codeschnipsel, nach dem Livegang die Adresse.
Für das systematische Vorgehen samt Fehlermeldungen im Klartext hilft die Anleitung zum Testen und Debuggen strukturierter Daten. Wer viele Seiten betreut, hängt die Prüfung besser in den Build als sie von Hand zu wiederholen.
Praxis-Tipp: Lassen Sie das Modell nach dem Code eine zweite Runde drehen: „Liste jede verwendete Property auf und schreibe dahinter, ob sie in schema.org existiert und wo die Angabe auf der Seite sichtbar ist." Die Selbstprüfung entlarvt einen Teil der erfundenen Felder, bevor Sie überhaupt einen Validator öffnen. Sie ersetzt ihn nicht.
Häufige Fragen zur KI-gestützten Schema-Erstellung
Kann Google erkennen, ob Schema Markup von einer KI stammt? Nein, und es spielt keine Rolle. JSON-LD trägt keine stilistischen Spuren. Bewertet wird, ob der Code korrekt ist und ob er zum Seiteninhalt passt.
Wie oft muss Schema Markup aktualisiert werden? Immer dann, wenn sich die Angaben ändern. Preise, Öffnungszeiten und Bewertungen im Markup, die nicht mehr stimmen, sind schlechter als gar kein Markup.
Braucht jede Seite eigenes Markup? Ein Organization- oder LocalBusiness-Knoten gehört auf jede Seite, seitenspezifische Typen wie Article oder Product nur dorthin, wo sie inhaltlich passen. Über „@id" verweisen die Einzelseiten auf denselben Unternehmensknoten.
Muss ich die generierten Blöcke wirklich einzeln prüfen? Nur solange Sie einzeln arbeiten. Sobald ein geprüftes Template steht, prüfen Sie die Vorlage und die Datenquelle, nicht mehr jede Seite. Bei kleinen Websites mit fünf bis zehn Blöcken ist die Einzelprüfung trotzdem schneller als jede Automatisierung.
Welcher Typ bringt am meisten? Für lokale Anbieter LocalBusiness mit vollständigen Öffnungszeiten, für Shops Product und Offer, für Redaktionen Article. FAQPage und HowTo bringen kein Snippet mehr, helfen aber beim maschinellen Verständnis.
Fazit
Sprachmodelle sind beim Schema Markup schnelle Schreiber und schlechte Prüfer. Sie liefern in Sekunden, was von Hand eine Stunde dauert, und bauen dabei Fehler ein, die im Chat unsichtbar bleiben. Nehmen Sie die Geschwindigkeit mit, aber geben Sie die Kontrolle nicht ab: erst Validator, dann Livegang, dann Search Console.
