SEO & KI · Suche & KI
Die wichtigsten Schema.org-Typen
Schema.org kennt über 800 Typen, aber nur eine Handvoll davon führt bei Google tatsächlich zu einer sichtbar anderen Darstellung im Suchergebnis – allen voran Organization, Article, BreadcrumbList und Product. Welchen Typ du brauchst, entscheidet daher nicht der Ehrgeiz, möglichst viel auszuzeichnen, sondern die Frage, welche Darstellung deine Seite überhaupt erreichen kann und was sichtbar auf ihr steht.
Die Grundlagen zu strukturierten Daten klären das Warum und das Format JSON-LD. Diese Seite geht eine Ebene tiefer: Sie zeigt die Typen, die im Alltag wirklich etwas bringen, jeweils als kopierbares Beispiel, erklärt wie du sie über @id zu einem zusammenhängenden Graphen verknüpfst – und ordnet ein, was nach dem Aus für die FAQ-Rich-Results im Mai 2026 von diesem Typ noch übrig ist.
Das Wichtigste in Kürze
- JSON-LD ist das von Google empfohlene Format – ein
<script>-Block im<head>, unabhängig vom sichtbaren Markup. - Nur auszeichnen, was wirklich sichtbar auf der Seite steht. Alles andere ist ein Richtlinienverstoß und kann eine manuelle Maßnahme auslösen.
-
Articlehat keine Pflichtfelder – Google empfiehlt lediglich; ohne sinnvolle Angaben passiert dafür aber auch nichts. -
FAQPageerzeugt seit dem 7. Mai 2026 keine Rich Results mehr. Der Typ bleibt gültig, die Auszeichnung darf stehen bleiben. - Verschachteln statt vervielfachen: ein Graph mit
@id-Verweisen statt fünf isolierter Blöcke. - Immer testen – mit dem Rich-Results-Test und dem Schema-Markup-Validator, die prüfen unterschiedliche Dinge.
Welche Typen 2026 noch eine Darstellung erzeugen
Das ist die entscheidende Vorfrage, und sie wird selten sauber beantwortet. Schema.org ist ein offenes Vokabular – du darfst alles auszeichnen. Aber nur für einen begrenzten, von Google gepflegten Katalog gibt es überhaupt eine besondere Darstellung im Suchergebnis. Aktuell umfasst dieser Katalog unter anderem:
| Bereich | Typen mit möglicher Sonderdarstellung |
|---|---|
| Inhalte | Article, Video, Image metadata, Speakable, Discussion forum, Q&A |
| Unternehmen | Organization, Local business, Profile page, Job posting |
| Handel | Product, Review snippet, Vacation rental |
| Navigation | Breadcrumb, Carousel |
| Spezialfälle | Event, Recipe, Course, Movie, Dataset, Software app, Math solver |
Zwei dieser Typen haben eine Entsprechung in der Barrierefreiheit, die man gleich miterledigen kann. VideoObject verlangt unter anderem eine Beschreibung und – für die Kapitelmarken – eine Zeitstruktur; wer ohnehin
Untertitel und ein Transkript
bereitstellt, hat den Text dafür schon und braucht ihn nur noch auszuzeichnen. Und
BreadcrumbList beschreibt exakt die Struktur, die eine
barrierefreie Brotkrumen-Navigation
im Markup sowieso hat. In beiden Fällen ist das Schema die zweite Verwendung derselben Arbeit, nicht eine zusätzliche.
FAQPage und HowTo existieren weiter – nur zeigt Google sie nicht mehr an.Alles außerhalb dieses Katalogs bleibt trotzdem sinnvoll, wenn es der maschinellen Einordnung dient – es führt nur zu keinem anderen Aussehen des Suchergebnisses.
Die vier Arbeitspferde
Organization und WebSite
Der Sockel, den jede Website haben sollte – einmal auf allen Seiten ausgeliefert. Er sagt Maschinen, wer hinter dem Angebot steht:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://html-einfach.de/#organization",
"name": "html-einfach.de",
"url": "https://html-einfach.de/",
"logo": "https://html-einfach.de/img/logo.png",
"sameAs": ["https://www.linkedin.com/in/jakobsommer/"]
}
</script>sameAs ist der unterschätzte Teil: Die Liste offizieller Profile ist das, woran Suchmaschinen und KI-Systeme deine Entität mit bereits bekannten Datenquellen verknüpfen. Das zahlt direkt auf E-E-A-T ein.
BreadcrumbList
Bildet den Brotkrumen-Pfad ab und ersetzt im Suchergebnis die nackte URL durch den lesbaren Pfad:
<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": "Schema.org-Typen" }
]
}
</script>Der letzte Eintrag – die aktuelle Seite – bekommt kein item. Das ist kein Schönheitsfehler, sondern die dokumentierte Schreibweise, und einer der häufigsten Validierungsfehler überhaupt.
Article
Für redaktionelle Inhalte mit Autor und Datum. Bemerkenswert: Google definiert für Article keine Pflichtfelder – es gibt nur Empfehlungen. Das heißt aber nicht, dass die Angaben egal wären; ohne Autor und Datum fehlt genau das Signal, das den Typ nützlich macht.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Die wichtigsten Schema.org-Typen",
"image": ["https://example.de/og/schema-typen.png"],
"author": {
"@type": "Person",
"name": "Jakob Sommer",
"url": "https://example.de/ueber-mich.html"
},
"datePublished": "2026-06-28T09:00:00+02:00",
"dateModified": "2026-07-26T18:30:00+02:00"
}
</script>Vier Details aus Googles Vorgaben, die in der Praxis immer wieder falsch sind:
-
headlinekurz halten – lange Titel werden auf manchen Geräten abgeschnitten. - Bilder großzügig liefern: mindestens 50 000 Pixel Fläche, am besten in den Seitenverhältnissen 16:9, 4:3 und 1:1, crawlbar und indexierbar.
-
author.urloderauthor.sameAsmitgeben. Ein Name allein ist keine Entität. Und niemals mehrere Autoren in ein Feld quetschen – jeder bekommt sein eigenesauthor-Objekt. -
Kein Verlagsname im
author.name. Der Herausgeber gehört inpublisher.
Die Datumsangaben folgen ISO 8601; die Zeitzone anzugeben ist ausdrücklich empfohlen.
Product
Für Shops – und hier lohnt eine Unterscheidung, die Google inzwischen deutlich macht:
- Product Snippets sind für Seiten ohne direkte Kaufmöglichkeit gedacht, etwa redaktionelle Testberichte. Hier zählen vor allem Bewertungen und Vor-/Nachteile.
- Merchant Listings sind für Seiten, auf denen man kaufen kann. Sie erwarten deutlich mehr: Preis, Verfügbarkeit, Versanddetails, Rückgabebedingungen.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Beispielprodukt",
"image": ["https://example.de/img/produkt.jpg"],
"offers": {
"@type": "Offer",
"price": "29.90",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock",
"url": "https://example.de/produkt.html"
}
}
</script>Wer die Anforderungen der Merchant Listings erfüllt, ist automatisch auch für Product Snippets qualifiziert – nicht umgekehrt.
Randnotiz – Bewertungen, die man sich selbst ausstellt. Sterne im Suchergebnis sind verlockend, und genau deshalb ist der Bereich streng reguliert. Bewertungen, die der Anbieter über sich selbst schreibt oder schreiben lässt, sind ausdrücklich unzulässig, und
aggregateRatingohne echte, auf der Seite sichtbare Einzelbewertungen ist einer der häufigsten Gründe für manuelle Maßnahmen. Wenn du keine echten Bewertungen hast, lass das Feld weg.
FAQPage und HowTo: der Stand nach der Abschaltung
Hier hat sich 2026 etwas Grundsätzliches geändert, und viele Anleitungen im Netz sind noch auf dem alten Stand.
Die Geschichte in drei Schritten: Im August 2023 schränkte Google die FAQ-Rich-Results massiv ein – sie erschienen nur noch bei bekannten behördlichen und Gesundheits-Websites; die HowTo-Rich-Results wurden gleich ganz abgeschafft. Am 7. Mai 2026 wurde dann auch die FAQ-Darstellung endgültig abgeschaltet, angekündigt lediglich über einen Hinweis in der Entwicklerdokumentation. Im Juni 2026 verschwand die Dokumentationsseite, zusammen mit dem Filter in der Search Console, dem Rich-Results-Bericht und der Unterstützung im Testwerkzeug.
Was heißt das praktisch?
- Der Typ bleibt gültig.
FAQPageist Teil des Schema.org-Vokabulars und wird das bleiben. Google selbst schreibt, dass man die Auszeichnung stehen lassen kann – für andere Suchmaschinen und Dienste, die sie weiterhin auswerten. - Erwarte keine Aufklapper mehr in der klassischen Google-Suche. Wer FAQ-Markup gerade wegen der Sterne oder der zusätzlichen SERP-Fläche eingebaut hat, hat den Grund verloren.
- Für die maschinelle Einordnung bleibt es nützlich. Ein sauber ausgezeichneter Frage-Antwort-Block sagt einem KI-System unmissverständlich, welcher Text die Antwort auf welche Frage ist. Beweisen lässt sich der Nutzen schwer – schaden tut es nachweislich nicht.
Meine Haltung dazu: Wenn die Auszeichnung ohnehin automatisch aus dem Inhalt entsteht, lass sie drin. Wenn du sie von Hand pflegen müsstest, ist die Zeit anderswo besser investiert.
Verschachteln statt vervielfachen
Der häufigste Anfängerfehler ist nicht das falsche Feld, sondern die falsche Struktur: fünf voneinander unabhängige <script>-Blöcke, die alle dieselbe Organisation neu definieren. Sauberer ist ein Graph, in dem jede Entität genau einmal beschrieben und danach über @id referenziert wird.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.de/#organization",
"name": "Beispiel GmbH"
},
{
"@type": "Person",
"@id": "https://example.de/#autor-jakob",
"name": "Jakob Sommer",
"url": "https://example.de/ueber-mich.html"
},
{
"@type": "Article",
"headline": "Die wichtigsten Schema.org-Typen",
"author": { "@id": "https://example.de/#autor-jakob" },
"publisher": { "@id": "https://example.de/#organization" }
}
]
}
</script>
Der Gewinn ist nicht bloß Ordnung. Ein @id ist ein stabiler Bezeichner: Taucht dieselbe Person auf 50 Artikeln unter derselben @id auf, ist maschinell klar, dass es sich um dieselbe Person handelt – und nicht um 50 Namensvettern.
Was diese Website ausliefert
Ich halte es hier bewusst schlank. Über alle 188 Seiten hinweg liefert der Build folgende Typen aus:
| Typ | Seiten | Zweck |
|---|---|---|
Organization |
alle | wer dahintersteht |
WebSite |
alle | Name und Startpunkt der Site |
BreadcrumbList |
alle Unterseiten | Pfad im Suchergebnis |
Article |
alle Wissensseiten | Autor, Erst- und Änderungsdatum |
FAQPage |
113 | die „Häufige Fragen“-Blöcke |
Person |
Autorenseite | die Entität hinter dem Namen |
Kein Product, kein Event, kein Review – weil es hier nichts davon gibt. Das FAQPage-Markup entsteht automatisch aus dem Abschnitt „Häufige Fragen“ im Text und bleibt trotz der Abschaltung drin: Es kostet nichts, weil es niemand pflegen muss.
Testen: zwei Werkzeuge, zwei Aufgaben
Die beiden werden ständig verwechselt, prüfen aber Unterschiedliches:
- Rich-Results-Test (
search.google.com/test/rich-results) beantwortet die Frage: Erreicht diese Seite eine Sonderdarstellung bei Google? Er kennt nur die Typen aus Googles Katalog und ignoriert alles andere. - Schema-Markup-Validator (
validator.schema.org) beantwortet die Frage: Ist mein Markup nach Schema.org korrekt? Er prüft das gesamte Vokabular, sagt aber nichts über Google-Darstellungen.
Ein Markup kann im Validator fehlerfrei sein und im Rich-Results-Test trotzdem „keine Elemente erkannt“ melden – das ist kein Widerspruch, sondern der Normalfall bei Typen außerhalb des Katalogs. Beide Werkzeuge stehen auch in der Tools-Sammlung.
Häufige Fehler
- Daten auszeichnen, die nicht sichtbar sind – ein Richtlinienverstoß mit Risiko einer manuellen Maßnahme.
-
aggregateRatingohne echte Bewertungen oder selbst verfasste Bewertungen. -
Letzter Breadcrumb-Eintrag mit
itemstatt ohne. -
Mehrere Autoren in einem
author-Feld oder der Verlagsname imauthor.name. - Fünf isolierte Blöcke statt eines Graphen mit
@id. - Falsche oder veraltete Preise im Markup, die nicht zur Seite passen.
- FAQ-Rich-Results erwarten, die es seit Mai 2026 nicht mehr gibt.
- Nie getestet – Tippfehler im JSON fallen sonst nie auf.
Häufige Fragen
Welche Typen sollte ich zuerst umsetzen?
Organization und WebSite als Sockel, BreadcrumbList für die Navigation und Article mit Person für Inhalte. Damit sind die meisten Wissens- und Firmenseiten abgedeckt. Shops ergänzen Product.
Schaden zu viele Typen?
Unnötige oder falsche Auszeichnung schadet mehr, als sie hilft – nicht durch eine Rangstrafe, sondern weil widersprüchliche Angaben das Vertrauen in die Daten untergraben und im schlimmsten Fall eine manuelle Maßnahme auslösen. Setze nur, was zur Seite passt und sichtbar belegt ist.
Sollte ich mein FAQ-Markup jetzt entfernen?
Nein, das ist nicht nötig. Google sagt ausdrücklich, dass es stehen bleiben darf. Entfernen lohnt nur, wenn du es bisher manuell gepflegt hast – dann sparst du dir die Arbeit.
Microdata oder JSON-LD?
JSON-LD. Google empfiehlt es ausdrücklich, es lässt sich unabhängig vom sichtbaren Markup pflegen, und es ist das Format, das auch KI-Systeme am zuverlässigsten verarbeiten. Microdata und RDFa funktionieren weiterhin, sind aber mühsamer zu warten.
Garantieren strukturierte Daten ein Rich Result?
Nein. Sie machen eine Seite lediglich dafür in Frage kommend. Ob Google die Darstellung wählt, hängt zusätzlich von Qualität, Suchanfrage und Gerät ab.
Fazit
Organization, WebSite, BreadcrumbList und Article sind die zuverlässigen Arbeitspferde; Product kommt in Shops dazu. FAQPage und HowTo bleiben gültiges Vokabular, erzeugen bei Google aber keine Sonderdarstellung mehr – FAQ seit dem 7. Mai 2026, HowTo schon seit 2023.
In allen Fällen gilt dasselbe: ehrlich auszeichnen, was auf der Seite steht, Entitäten über @id einmal beschreiben und danach referenzieren, und das Ergebnis mit beiden Werkzeugen prüfen. Den größeren Rahmen spannen die Grundlagen strukturierter Daten und GEO auf.
Quellen
- Übersicht der Suchergebnisfunktionen (Google Search Central – der maßgebliche Katalog der Typen mit möglicher Sonderdarstellung)
- Article (Artikel) – strukturierte Daten (Google Search Central – empfohlene Eigenschaften, Bildanforderungen und Autorenregeln)
- Changes to HowTo and FAQ rich results (Google Search Central Blog – die Einschränkung von 2023 als Vorstufe der Abschaltung)