Korrigiert am 17. September 2026
Die erste Fassung führte Course Info und FAQPage als unterstützte Rich Results (entfernt 2025 und im Mai 2026), nannte in der Liste abgekündigter Typen Namen, die es auf schema.org nicht gibt, behauptete, KI-Engines würden JSON-LD auslesen und zitieren, nannte CTR-Studien ohne Quelle und versprach ein „Brand-Panel mit Haken“. Der Next.js-Tipp war falsch, und Luminas Schema Validator wurden seitenübergreifende @id-Auflösung und Bulk-Validierung zugeschrieben, die das Tool nicht hat. Für das „Live-Audit“ von fünf Konkurrenz-Guides gab es keine gespeicherten Daten, deshalb habe ich es entfernt.
Strukturierte Daten gehören zu den günstigsten technischen SEO-Aufgaben mit sichtbarem Ergebnis. Du fügst einen JSON-LD-Block in eine Seite ein, und wenn die Seite die Voraussetzungen erfüllt, kann Google sie mit erweiterten Ergebnissen zeigen: Preise, Bewertungen, Event-Termine, Breadcrumbs, Video-Vorschaubilder. Das Vokabular ist frei verfügbar auf schema.org.
Wenn dich der KI-Aspekt interessiert: Schema Markup für KI-Suche zeigt, was dazu belegt ist.
Was strukturierte Daten wirklich sind
Schema Markup ist ein gemeinsames Vokabular, um zu beschreiben, worum es auf einer Seite geht. Schema.org wurde 2011 von Google, Microsoft und Yahoo gestartet, Yandex kam im selben Jahr dazu, und seit 2015 wird es über eine W3C Community Group weiterentwickelt. Das Vokabular umfasst mehr als 800 Typen und 1.500 Properties für Artikel, Produkte, Events, Personen, Organisationen, Rezepte, Bewertungen, Software und mehr.
Das Vokabular selbst ist nur eine Taxonomie. Das Markup ist die Art, wie du es in eine Seite einbaust, damit Crawler es lesen können. Für die meisten Seiten heißt das heute JSON-LD: ein Script-Block, der Entitäten und ihre Eigenschaften deklariert.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Strukturierte Daten: Der komplette Leitfaden",
"author": { "@type": "Person", "name": "Julien El-Bahy" },
"datePublished": "2026-04-21"
}
</script>Der Block sagt Suchmaschinen: Diese Seite ist ein Article, das ist die Überschrift, das der Autor, das das Veröffentlichungsdatum. Google kann vieles davon auch aus der Seite ableiten, aber das Markup macht es eindeutig, und für Rich Results ist es Pflicht.
Strukturierte Daten sind kein Rankingfaktor. Google hat das mehrfach gesagt, zum Beispiel John Mueller in dieser Antwort, über die Search Engine Journal berichtet hat. Sie machen Seiten aber für Rich Results berechtigt, und die können verändern, wie dein Ergebnis aussieht und wie oft es angeklickt wird.
JSON-LD vs Microdata vs RDFa
Es gibt drei Formate, und Google unterstützt alle drei.
JSON-LD (JavaScript Object Notation for Linked Data) steht in einem <script type="application/ld+json">-Block, im <head> oder im <body>. Es ist vom sichtbaren HTML getrennt, du kannst es also ändern, ohne den Rest der Seite anzufassen. Google empfiehlt JSON-LD, wenn dein Setup es zulässt.
Microdata schreibt Attribute direkt ins sichtbare HTML: itemscope, itemtype, itemprop. Das funktioniert, macht Templates aber unübersichtlich und Änderungen schwerer nachvollziehbar. Ältere CMS-Plugins geben es noch aus. Wenn es funktioniert, musst du es nicht entfernen. Achte nur darauf, dass es JSON-LD, das du ergänzt, nicht widerspricht.
RDFa ist das Attribut-Format des W3C. Gültig, aber außerhalb von Verlagen und Behördendaten selten.
Nimm JSON-LD.
Ein Script-Block, am besten mit einem @graph für alle Entitäten der Seite. Jedes Rich Result, das Google dokumentiert, akzeptiert es. Für eine Seite, die du aktiv baust, gibt es kaum einen Grund für etwas anderes.
Die Schema-Typen, die wirklich zählen
Du brauchst keine hundert Typen. Nimm die, die beschreiben, was deine Seite tatsächlich ist. Diese acht decken die meisten Unternehmens- und Content-Seiten ab.
1. Article / BlogPosting
Redaktionelle Inhalte: Blogartikel, News, Ratgeber. Laut Googles Article-Dokumentation hilft das Markup, die Seite zu verstehen und Titel, Bild und Datum besser anzuzeigen. Pflichtfelder gibt es keine. Empfohlen sind author, dateModified, datePublished, headline und image.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Strukturierte Daten: Der komplette Leitfaden",
"datePublished": "2026-04-21",
"dateModified": "2026-04-21",
"author": { "@id": "https://deine-seite.de/#founder" },
"publisher": { "@id": "https://deine-seite.de/#organization" }
}2. Product
Alles, was du verkaufst. Product-Markup kann Preis, Verfügbarkeit und Bewertungen in den Ergebnissen zeigen. Für Produkt-Snippets verlangt Google name plus eins von review, aggregateRating oder offers. Händlereinträge haben eigene, strengere Anforderungen.
3. LocalBusiness
Unternehmen mit festem Standort. Das Markup kann Google Angaben wie Öffnungszeiten, Adresse und Telefonnummer liefern. Pflicht sind name und address; empfohlen sind unter anderem telephone, openingHoursSpecification, geo und url. Für Maps und das Local Pack zählt dein Google-Unternehmensprofil deutlich mehr als Markup.
4. FAQPage
Frage-Antwort-Blöcke. Google hat FAQ-Rich-Results 2023 auf bekannte Behörden- und Gesundheitsseiten beschränkt und sie am 7. Mai 2026 ganz abgeschaltet (Details im Abschnitt zu abgekündigten Rich Results). Das Markup bleibt gültig. Wenn du es behältst, halte den Text wortgleich zur sichtbaren FAQ, damit sich die Seite nicht selbst widerspricht.
5. BreadcrumbList
Deine Seitenhierarchie. Google zeigt Breadcrumb-Pfade in den Ergebnissen auf dem Desktop; seit Januar 2025 steht mobil nur noch die Domain. Jedes itemListElement braucht position und name, jedes außer dem letzten auch item.
6. Organization
Deine Marke: Name, Logo, URL, Kontaktdaten und sameAs-Links zu offiziellen Profilen. Laut Googles Organization-Dokumentation hilft das Markup, Angaben zu deiner Organisation zu verstehen und sie eindeutig zuzuordnen, und es kann beeinflussen, welches Logo Google zeigt. Deklarier sie einmal, etwa auf der Startseite unter /#organization, und referenziere sie sonst per @id.
7. Person
Der Autor. Sinnvoll als author von Artikeln, mit name, url, jobTitle und sameAs-Links zu Profilen. Googles Article-Doku empfiehlt, den Autor mit Name und URL auszuzeichnen. Ein eigenes Rich Result hat Person nicht.
8. Event
Alles mit Startdatum und Ort: Webinare, Konzerte, Konferenzen. Pflicht sind name, startDate und location. Empfohlen sind unter anderem endDate, eventStatus, eventAttendanceMode und offers bei kostenpflichtigen Events.
Weitere Typen, die du kennen solltest
- Recipe. Rezepte, mit Rich Results für Zeit, Bewertungen und Bilder.
- VideoObject. Seiten mit Video, für Vorschaubilder und wichtige Abschnitte in Google.
- SoftwareApplication / WebApplication. Apps und Tools. Luminas Tool-Seiten nutzen WebApplication.
- Review / AggregateRating. Meist verschachtelt in Product, LocalBusiness oder einem anderen bewertbaren Typ.
- Kursliste (Course list). Weiterhin unterstützt für Seiten mit mehreren Kursen.
- JobPosting. Stellenanzeigen in Googles Jobsuche.
Bau keine Typen ein, die nicht zur Seite passen. Ein Dataset-Block auf einem Blogartikel oder ein Vehicle-Block auf der Startseite beschreibt nichts Reales, und Googles Richtlinien verbieten irrelevantes oder irreführendes Markup.
Wie du strukturierte Daten einbaust
Drei übliche Wege. Nimm den, der zu deinem Stack passt.
Reines HTML: einfügen und fertig
Wenn du das HTML direkt kontrollierst, füg den JSON-LD-Block in die Seite ein. Ein Block mit @graph kann alle Entitäten aufnehmen:
<head>
<!-- ...weitere Head-Tags... -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "BlogPosting",
"@id": "https://deine-seite.de/blog/artikel/#article",
"headline": "...",
"author": { "@id": "https://deine-seite.de/#founder" },
"publisher": { "@id": "https://deine-seite.de/#organization" },
"datePublished": "2026-04-21",
"dateModified": "2026-04-21"
},
{
"@type": "Person",
"@id": "https://deine-seite.de/#founder",
"name": "Name des Autors",
"jobTitle": "Titel",
"sameAs": ["https://www.linkedin.com/in/..."]
},
{
"@type": "Organization",
"@id": "https://deine-seite.de/#organization",
"name": "Deine Marke",
"url": "https://deine-seite.de",
"logo": "https://deine-seite.de/logo.png"
}
]
}
</script>
</head>Person und Organization sind einmal mit @id definiert und werden vom Artikel referenziert. So bleibt das Markup einheitlich und leicht zu pflegen. Validatoren prüfen in der Regel jede Seite einzeln, bau die vollständige Entität also auf jeder Seite ein, auf der sie geprüft werden soll.
WordPress: Plugin oder Theme
Unter WordPress ist Schema meist schon halb eingerichtet. Yoast SEO und Rank Math geben standardmäßig Article-, Organization-, WebSite- und BreadcrumbList-Markup aus, und beide haben FAQ- und HowTo-Blöcke im Editor. The SEO Framework ergänzt Article-Markup nur über seine Articles-Erweiterung.
Der Haken: Plugin-Markup ist generisch. Organization.sameAs bleibt leer, bis du Social-Profile in den Plugin-Einstellungen einträgst, und Autoren haben oft nur einen Namen. Das behebst du in den Einstellungen des Plugins, nicht im Code.
Für Markup, das das Plugin nicht abdeckt (mehrere Standorte, Produktvarianten mit ProductGroup, Event-Reihen), ergänzt du handgeschriebenes JSON-LD über einen wp_head-Hook im Child-Theme. Arbeite neben dem Plugin, nicht gegen es, und gib dieselbe Entität nicht zweimal mit unterschiedlichen Werten aus.
Next.js, React, Vue, Astro: Muster in Frameworks
Next.js empfiehlt, ein natives <script type="application/ld+json"> in der Page- oder Layout-Komponente zu rendern. Das Objekt läuft durch JSON.stringify(), und < wird durch < ersetzt, damit niemand Script-Code einschleusen kann:
<script
type="application/ld+json"
dangerouslySetInnerHTML={{
__html: JSON.stringify(jsonLd).replace(/</g, '\\u003c'),
}}
/>In Nuxt nimmst du das Composable useHead mit einem Script-Eintrag. In Astro funktioniert <script type="application/ld+json" set:html={JSON.stringify(jsonLd)} /> in der Komponente und wird als statisches HTML ausgeliefert.
Ein typischer React-Fehler: JSON als Text-Kind rendern statt über dangerouslySetInnerHTML. React escaped den Inhalt, und im Output steht " statt Anführungszeichen, was kein gültiges JSON ist. Prüf das gerenderte HTML, nicht den Komponenten-Code.
Helfen strukturierte Daten 2026 noch im SEO?
Sie schieben deine Position nicht nach oben. Zwei Dinge leisten sie aber weiterhin.
Rich Results. Passendes Markup qualifiziert Seiten für erweiterte Ergebnisse: Produktpreise und Bewertungen, Rezeptkarten, Event-Details, Video-Vorschaubilder, Breadcrumbs auf dem Desktop. Berechtigung ist keine Garantie; Google entscheidet, wann es sie zeigt. Googles eigene Fallstudien nennen zum Beispiel eine um 25 Prozent höhere Klickrate bei Rotten-Tomatoes-Seiten mit strukturierten Daten und eine um 82 Prozent höhere Klickrate bei Nestlé-Seiten, die als Rich Result erscheinen. Das sind von Google ausgewählte Beispiele, aber sie zeigen, welche Wirkung möglich ist.
Entitäten verstehen. Organization- und Person-Markup mit sameAs-Links hilft Google, deine Seiten der richtigen Organisation oder Person zuzuordnen. Das kann beeinflussen, welches Logo und welche Angaben Google zu deiner Marke zeigt. Ein Knowledge Panel ist nicht garantiert, und ein „Verifiziert“-Abzeichen gibt es nicht.
Und die KI-Suche? Google sagt, dass AI Overviews und AI Mode keine speziellen strukturierten Daten brauchen, und eine kontrollierte Ahrefs-Studie fand nach dem Einbau von JSON-LD keinen nennenswerten Effekt auf KI-Zitate. Bau Markup also nicht in der Erwartung ein, dadurch zitiert zu werden. Details stehen in Schema Markup für KI-Suche.
Was strukturierte Daten nicht können: dünne Inhalte, kaputte interne Links, langsame Seiten oder fehlende Crawlbarkeit ausgleichen. Ist die Seite schwach, rettet sie kein JSON-LD-Block.
Abgekündigte Rich Results
Google hat seit 2023 viele Rich Results gestrichen. Die schema.org-Typen gibt es weiterhin, und sie validieren auch. Es fällt nur die Funktion in Google weg. Stand laut Googles Dokumentations-Updates:
Weiterhin unterstützt (Beispiele). Article, Breadcrumb, Event, Stellenanzeigen, Local Business, Logo über Organization, Produkt-Snippets und Händlereinträge, Recipe, Review Snippet, Video, Kursliste, Diskussionsforum, Profilseite, Q&A (für Seiten, auf denen Nutzer Antworten schreiben), Math Solver, Dataset. Die aktuelle Liste steht in Googles Search Gallery.
Entfernt:
- HowTo: Rich Result im September 2023 entfernt.
- Sitelinks-Suchfeld: im November 2024 entfernt,
SearchAction-Markup bewirkt in Google also nichts mehr. - Aufräumaktion Juni 2025: Google hat angekündigt, Book Actions, Course Info, ClaimReview, Estimated Salary, Learning Video, Special Announcement und Vehicle Listing auslaufen zu lassen. ClaimReview bleibt im Fact Check Explorer unterstützt.
- FAQ: Rich Result seit dem 7. Mai 2026 weg, Doku im Juni 2026 entfernt.
Speakable ist ein Sonderfall: weiterhin eine Beta, nur für News-Publisher auf US-Englisch.
Abgekündigtes Rich Result heißt nicht kaputtes Markup.
Beschreibt das Markup deinen Inhalt korrekt, schadet es nicht, ihn stehen zu lassen. Gültiges Markup aus Hunderten Seiten zu entfernen, lohnt selten den Aufwand. Bau nur kein neues Markup für eine Funktion ein, die es nicht mehr gibt.
Die häufigsten Schema-Fehler
Ich habe Luminas Schema Validator an Luminas eigenen Seiten und an einer Reihe externer Seiten getestet. Diese sechs Muster verursachen die meisten echten Probleme.
1. Markup, das nicht zur Seite passt. Bewertungen, Preise oder FAQ-Antworten, die nur im JSON-LD stehen, oder Schema-Text, der etwas anderes sagt als der sichtbare Inhalt. Googles Richtlinien für strukturierte Daten verlangen, dass Markup die Seite wiedergibt, und Verstöße können zu einer manuellen Maßnahme führen. Bei FAQ-Markup hilft eine einfache Prozessregel: HTML und Schema im selben Commit ändern und vor dem Deploy gegeneinander prüfen.
2. Doppelte oder unverbundene Entitäten. Der Autor steht als {"@type":"Person","name":"Autor"} inline im Artikel, während ein separater Person-Block mit den echten Angaben unverbunden daneben steht. Oder ein Plugin und ein handgeschriebener Block geben beide eine Organization mit unterschiedlichen Logos aus. Definier jede Entität einmal und referenziere sie per @id.
3. Unzuverlässiges dateModified. Zwei spiegelbildliche Fehler. Der Inhalt ändert sich, das Datum nicht, oder das Datum ändert sich bei jeder CSS-Anpassung. Google verlangt korrekte Datumsangaben und rät davon ab, sie künstlich aufzufrischen. Ändere dateModified nur bei echten inhaltlichen Änderungen.
4. Erfundene Properties. applicationArea gibt es auf schema.org nicht, coverImage auch nicht. Unbekannte Properties werden ignoriert. Der Schema Markup Validator meldet sie, Googles Rich-Results-Test prüft nur die Properties, die für Google-Funktionen relevant sind. Im Zweifel schau auf der schema.org-Seite des Typs nach.
5. Viele Typen, wenig Bezug. Vierzehn Typen auf einem Blogartikel, von DefinedTerm bis ReadAction, obwohl die Hälfte die Seite gar nicht beschreibt. Das macht Pflege aufwendiger und öffnet Raum für Widersprüche. Drei bis fünf gut verbundene Entitäten, die zur Seite passen, lassen sich leichter korrekt halten.
6. HTML-Tags in Textfeldern. Nennt eine FAQ-Antwort Tag-Namen wie <nav> oder <main>, können Parser sie als Markup behandeln und entfernen, und im Text steht dann „Elemente wie , ,“. Ich habe das am 9. Mai 2026 auf Luminas eigener Seite gefunden, in 14 von 656 FAQ-Antworten über 102 Dateien. Escape spitze Klammern als < und >, wenn du sie als Text meinst.
Wie du strukturierte Daten validierst
Drei Tools, die unterschiedliche Probleme finden:
- Google Rich-Results-Test. Prüft eine URL oder ein Code-Snippet auf die Rich Results, die Google unterstützt, und meldet fehlende Pflicht- und empfohlene Felder. Er deckt nur Google-Funktionen ab und testet FAQ-Markup deshalb nicht mehr.
- Schema Markup Validator. Prüft Markup gegen das komplette schema.org-Vokabular und meldet unbekannte Typen und Properties.
- Lumina Schema Validator. Kostenlos, ohne Anmeldung. Prüft JSON-Syntax sowie Pflicht- und empfohlene Felder für Google-Funktionen, warnt vor Typen, deren Rich Results Google entfernt hat, und vergleicht FAQPage-Text mit der sichtbaren FAQ auf der Seite.
Dieser FAQ-Abgleich ist der Teil, den die anderen beiden nicht machen. Luminas Validator liest JSON-LD und sichtbare FAQ-Einträge aus und vergleicht sie Frage für Frage und Antwort für Antwort, inklusive Anzahl, Reihenfolge und Wortlaut. Er prüft jede Seite für sich und folgt keinen @id-Referenzen auf andere URLs.
Ein praktischer Ablauf: beim Schreiben das Vokabular mit dem Schema Markup Validator prüfen, vor dem Release die Eignung für Google mit dem Rich-Results-Test prüfen und nach dem Deploy Luminas Validator über die Live-URL laufen lassen, um FAQ-Drift zu finden.
FAQ
Wo du anfängst
Fünf Schritte, der Reihe nach. Für eine kleine Seite etwa ein bis zwei Stunden:
Lass Luminas Schema Validator und den Rich-Results-Test über Startseite, zwei Landingpages und zwei Artikel laufen. Notier Fehler, fehlende Pflichtfelder und doppelte Entitäten.
Schema Validator →Eine Organization mit Name, Logo, URL und sameAs-Links. Eine Person pro Autor. Gib jeder eine @id und referenziere sie aus dem übrigen Markup.
BlogPosting auf Artikeln, Product auf Produktseiten, LocalBusiness auf Standortseiten, BreadcrumbList auf der ganzen Seite. Nur Typen, die passen.
Ergebnis validieren →Kein neues FAQ-, HowTo- oder SearchAction-Markup für Rich Results. Wo FAQ-Markup bleibt, halte es wortgleich zur sichtbaren FAQ.
FAQ-Abgleich →Nimm den Rich-Results-Test in deine Release-Checkliste auf und lass Luminas Schema Validator nach dem Deploy über geänderte Seiten laufen. So findest du Rückschritte, bevor ein Kunde es tut.
Schema Validator →Prüf deine strukturierten Daten in 30 Sekunden
Luminas kostenloser Schema Validator prüft JSON-LD-Syntax, Pflicht- und empfohlene Felder für Google-Funktionen, entfernte Rich-Result-Typen und ob FAQ-Markup zur sichtbaren Seite passt. Code einfügen oder URL eingeben, ohne Anmeldung.
Schema Validator starten →