SEO & KI · Suche & KI
Strukturierte Daten mit Schema.org
Strukturierte Daten sind maschinenlesbare Zusatzangaben im Quelltext, die einer Suchmaschine sagen, was ein Inhalt bedeutet: dass dieser Text ein Artikel mit Autor und Datum ist, jene Liste ein Brotkrumen-Pfad, dort eine Organisation beschrieben wird. Notiert werden sie am besten als JSON-LD – ein eigener <script>-Block, sauber getrennt vom sichtbaren HTML.
Sie ergänzen das Markup um eine Bedeutungsebene, die Semantik noch einmal explizit macht. Der Lohn sind zwei Dinge: Rich Results – angereicherte Suchergebnisse mit Brotkrumen, Sternen oder Produktdaten – und ein besseres Verständnis durch Such- und KI-Systeme. Beides für überschaubaren Aufwand, wenn man weiß, welche Typen sich noch lohnen.
Das Wichtigste in Kürze
- JSON-LD ist das empfohlene Format. Ein Block im Quelltext, kein Attribut-Geflecht im HTML.
- Markup garantiert kein Rich Result. Es ist die Voraussetzung, die Darstellung entscheidet die Suchmaschine.
- Der größte Teil des Markups ist unsichtbar – und trotzdem nützlich: Er ordnet Inhalte Personen, Marken und Themen zu.
- Nur auszeichnen, was auf der Seite steht. Markup für unsichtbare Inhalte ist ein Richtlinienverstoß.
- Die Typenliste ist kürzer geworden. Stand August 2026: FAQ-Rich-Results gibt es seit Mai 2026 gar nicht mehr, HowTo seit 2023 nicht.
-
@graphund@idverbinden mehrere Typen zu einem Netz, statt sie nebeneinanderzustellen.
Schema.org und JSON-LD: zwei Begriffe, ein Paar
Die beiden werden oft synonym verwendet, meinen aber Verschiedenes:
- Schema.org ist das gemeinsame Vokabular – eine große Sammlung von Typen (
Article,Organization,Product…) und deren Eigenschaften. Es wird von Google, Microsoft, Yahoo und Yandex gemeinsam gepflegt. - JSON-LD ist die Schreibweise, in der man dieses Vokabular notiert: ein
<script type="application/ld+json">-Block mit JSON darin.
Man könnte dasselbe Vokabular auch als Microdata oder RDFa direkt ins HTML schreiben. In der Praxis lohnt das selten:
| Format | Wo es steht | Wartbarkeit |
|---|---|---|
| JSON-LD | eigener <script>-Block |
hoch – ein Ort, generierbar |
| Microdata | Attribute an jedem betroffenen Element | niedrig – geht bei jedem Redesign kaputt |
| RDFa | ebenso, mit anderem Attributsatz | niedrig |
Google empfiehlt ausdrücklich JSON-LD, und der Grund ist praktischer Natur: Der Block lässt sich aus derselben Datenquelle erzeugen, aus der auch der sichtbare Inhalt kommt.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Start", "item": "https://example.de/" },
{ "@type": "ListItem", "position": 2, "name": "SEO & KI", "item": "https://example.de/seo-und-ki.html" },
{ "@type": "ListItem", "position": 3, "name": "Strukturierte Daten" }
]
}
</script>Zwei Details, die häufig falsch gemacht werden: Das letzte Element der Brotkrume bekommt kein item – es ist ja die aktuelle Seite. Und die URLs müssen absolut sein und mit der kanonischen Adresse übereinstimmen; relative Pfade sind hier keine gute Idee.
Wohin der Block gehört
In den <head> oder in den <body> – beides ist erlaubt und wird gleich behandelt. Ich lege ihn in den <head>, weil er dort thematisch zu den übrigen Dokument-Metadaten passt.
Wichtiger ist etwas anderes: Der Block sollte im ausgelieferten HTML stehen und nicht erst per JavaScript nachgeschoben werden. Google verarbeitet zwar auch nachgereichtes Markup, andere Crawler und KI-Systeme aber oft nicht. Bei einer statischen Seite entsteht er beim Build und ist damit von Anfang an da.
Die Typen, die im Alltag zählen
Eine Handvoll Typen deckt die meisten Websites ab:
| Typ | Wofür | Pflichtangaben (Kern) |
|---|---|---|
Organization |
Betreiber, Marke, Logo | name, url |
WebSite |
die Website als Ganzes | name, url |
BreadcrumbList |
der Brotkrumen-Pfad | itemListElement mit position |
Article / BlogPosting |
redaktionelle Inhalte | headline, author, datePublished |
Person |
Autorinnen und Autoren | name |
Product |
Produkte mit Preis und Bewertung | name, offers |
LocalBusiness |
Ladengeschäft, Praxis, Kanzlei | name, address |
Die vollständige Liste bei Schema.org ist um Größenordnungen länger – aber die wenigsten Typen lösen etwas aus. Wer mehr auszeichnet, gewinnt dadurch nichts und handelt sich Pflegeaufwand ein.
Was 2026 noch ein Rich Result auslöst
Hier hat sich in kurzer Zeit einiges verschoben, und veraltete Anleitungen sind zahlreich:
- FAQ-Rich-Results: in zwei Schritten verschwunden. Seit August 2023 gab es sie nur noch für bekannte Behörden- und Gesundheitsseiten, seit Mai 2026 gar nicht mehr. Der Typ
FAQPagebleibt gültiges Vokabular und erzeugt keine Fehler – die Aufklapper im Suchergebnis gibt es aber für niemanden mehr. - HowTo: seit August 2023 auf Mobilgeräten abgeschafft und auf den Desktop begrenzt, inzwischen auf keinem Gerät mehr sichtbar.
- Sieben weitere Typen kündigte Google im Juni 2025 zur Abschaffung an, darunter
ClaimReview,EstimatedSalary,SpecialAnnouncementundVehicleListing. - Practice Problem: im Januar 2026 entfernt.
Daraus lässt sich eine Regel ableiten: Markup lohnt sich nicht wegen des Snippets, sondern wegen der Einordnung. Organization, Person, BreadcrumbList und Article verändern das Suchergebnis kaum sichtbar – aber sie sagen einer Maschine, wer hinter einem Text steht und wohin er gehört. Genau das zählt, wenn eine KI-Antwort eine Quelle auswählt.
Mehrere Typen verbinden: @graph und @id
Auf einer Artikelseite kommen schnell drei, vier Objekte zusammen. Statt vier getrennte Blöcke nebeneinanderzustellen, verbindet man sie über @id-Verweise zu einem Netz:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.de/#organisation",
"name": "Beispiel GmbH",
"url": "https://example.de/"
},
{
"@type": "Person",
"@id": "https://example.de/#autor",
"name": "Jakob Sommer",
"worksFor": { "@id": "https://example.de/#organisation" }
},
{
"@type": "Article",
"headline": "Strukturierte Daten mit Schema.org",
"author": { "@id": "https://example.de/#autor" },
"publisher": { "@id": "https://example.de/#organisation" },
"datePublished": "2026-06-20",
"dateModified": "2026-07-27",
"mainEntityOfPage": "https://example.de/seo-und-ki/strukturierte-daten.html"
}
]
}
</script>Der Vorteil: Autor und Organisation werden einmal definiert und überall referenziert. Ändert sich der Firmenname, gibt es genau eine Stelle. Und für die Maschine ist erkennbar, dass es sich um dieselbe Person handelt wie auf allen anderen Seiten – nicht um zufällig gleich benannte.
Was diese Website nutzt
Gute Beispiele erklärt man am besten an echten – und diese Seite ist eins. Sie erzeugt ihr JSON-LD automatisch aus derselben Datenquelle, die auch die sichtbaren Inhalte speist:
-
Organization+WebSiteauf jeder Seite, aus der zentralen Konfiguration, -
BreadcrumbListaus der Navigationsdatenquelle – derselben, aus der auch das Mega-Menü und die sichtbaren Brotkrumen entstehen, -
Article+Personauf jeder Inhaltsseite, mit Autor Jakob Sommer und Aktualisierungsdatum, -
eine
ItemListder Themenbereiche auf der Startseite.
Weil alles aus einer Quelle stammt, können sichtbarer Inhalt und strukturierte Daten gar nicht erst auseinanderlaufen. Genau das ist der Punkt – und der häufigste Fehler bei handgepflegtem Markup. Und dann steht da plötzlich ein Preis im Quelltext, den’s auf der Seite gar nicht mehr gibt.
Regeln, an die ich mich halte
- Nur auszeichnen, was wirklich auf der Seite steht. Strukturierte Daten für unsichtbare oder abweichende Inhalte verstoßen gegen die Richtlinien und können zu einer manuellen Maßnahme führen.
- Sichtbares und Markup deckungsgleich halten. Der ausgezeichnete Preis ist der Preis, der dasteht. Das ausgezeichnete Datum ist das, was der Leser sieht.
- Keine Bewertungen für sich selbst. Sternebewertungen der eigenen Firma auf der eigenen Website sind ausdrücklich ausgeschlossen.
- Weniger Typen, dafür gepflegt. Ein korrektes
Articleschlägt fünf halbherzige Objekte. - Nach jeder Änderung testen. Ein fehlendes Komma macht den ganzen Block wirkungslos – JSON verzeiht nichts.
Testen: zwei Werkzeuge, zwei Zwecke
| Werkzeug | Prüft | Wofür |
|---|---|---|
| Rich-Results-Test (Google) | ob Google daraus ein Rich Result bauen kann | die Frage „Wird es angezeigt?“ |
| Schema Markup Validator (schema.org) | Syntax und Vokabular, unabhängig von Google | die Frage „Ist es korrekt?“ |
Beide sind kostenlos. Der Unterschied ist wichtig: Der Rich-Results-Test meldet Typen, die Google nicht unterstützt, gar nicht erst – das heißt nicht, dass das Markup falsch wäre. Umgekehrt kann der Validator zufrieden sein, während Google eine Pflichtangabe vermisst. Für den laufenden Betrieb kommt der Bericht „Verbesserungen“ in der Search Console dazu; er zeigt Fehler über alle Seiten hinweg statt nur für eine.
Der Nebeneffekt, den man mitnehmen sollte
Fast jeder Schema-Typ verlangt Angaben, die eine barrierefreie Seite ohnehin hat. VideoObject will eine Beschreibung und idealerweise ein Transkript – dieselbe Datei, die als Untertitel im Media-Player läuft. ImageObject will eine Bildbeschreibung, BreadcrumbList die Pfadstruktur, die eine Brotkrumen-Navigation sowieso auszeichnet. Wer die Reihenfolge umdreht und erst das Schema baut, schreibt dieselben Inhalte zweimal – einmal für Maschinen und einmal für Menschen, mit garantiertem Auseinanderdriften.
Häufige Fehler
- Markup für Inhalte, die es auf der Seite nicht gibt – der schwerste Verstoß.
- Relative URLs in
item,urloder@id. - Die aktuelle Seite in der Brotkrume verlinken statt sie als letztes Element ohne
itemzu führen. -
headlinemit dem Seitentitel verwechseln. Das Snippet kommt weiterhin aus<title>und Meta-Description. - Zwei widersprüchliche Blöcke auf einer Seite, etwa aus Theme und Plugin gleichzeitig.
-
FAQPagein der Hoffnung auf Aufklapper – die gibt es seit Mai 2026 nicht mehr. - Datumsangaben ohne ISO-Format.
"20.06.2026"ist kein gültigesdatePublished. - Nach dem Einbau nie wieder geprüft.
Häufige Fragen
Microdata, RDFa oder JSON-LD?
JSON-LD. Es ist das von Google empfohlene Format, am besten wartbar und sauber vom Inhalt getrennt. Microdata und RDFa funktionieren auch, sind aber bei jedem Umbau des HTML gefährdet.
Garantieren strukturierte Daten Rich Results?
Nein. Sie sind die Voraussetzung, aber ob und wie ein Rich Result erscheint, entscheidet die Suchmaschine – abhängig von Suchanfrage, Gerät und Qualität der Seite. Korrekte, richtlinienkonforme Daten erhöhen die Chance.
Sind strukturierte Daten ein Rankingfaktor?
Nicht direkt. Sie beeinflussen die Darstellung und das Verständnis, nicht die Position. Indirekt können sie über eine höhere Klickrate wirken – aber wer Positionen erwartet, wird enttäuscht.
Helfen strukturierte Daten der KI-Suche?
Sie schaden nicht und machen Entitäten und Zusammenhänge expliziter. Als Baustein von GEO sind sie sinnvoll – aber kein Ersatz für klare, gute Inhalte. Der Text selbst bleibt die Substanz.
Lohnt sich FAQPage überhaupt noch?
Als Rich Result nicht mehr – seit Mai 2026 zeigt Google die Aufklapper für keine Website mehr an. Als sauber ausgezeichneter Frage-Antwort-Block bleibt der Typ gültig und kann von anderen Systemen genutzt werden; nur sollte man ihn nicht mehr in Erwartung eines Aufklappers im Suchergebnis einbauen.
Wie viele JSON-LD-Blöcke darf eine Seite haben?
Beliebig viele. Sauberer ist ein einziger Block mit @graph, weil sich darin Objekte gegenseitig referenzieren können und Widersprüche seltener entstehen.
Muss ich das von Hand schreiben?
Nein, und ich würde davon abraten. Erzeuge das Markup aus derselben Quelle wie den sichtbaren Inhalt – im CMS, im Template oder beim Build. Handarbeit führt fast zwangsläufig irgendwann zu Abweichungen.
Fazit
Strukturierte Daten in JSON-LD machen maschinenlesbar, was eine Seite bedeutet: Organization, WebSite, BreadcrumbList, Article und Person decken den Alltag weitgehend ab, verbunden über @graph und @id. Sie ermöglichen Rich Results, wo es sie noch gibt, und schärfen davon unabhängig das Verständnis bei Such- und KI-Systemen. Wichtig ist nur, beim Tatsächlichen zu bleiben: auszeichnen, was wirklich dasteht – aus einer Quelle erzeugen, nach jeder Änderung prüfen. Welcher Typ wofür gedacht ist, zeigt die Übersicht der Schema.org-Typen.
- Richtlinien für strukturierte Daten – Google Search Central
- Schema Markup Validator – schema.org