So testen Sie Rich Snippets (und beheben Schema-Fehler)

TL;DR: Teste die Berechtigung für Rich Snippets mit Googles Rich Results Test. Nutze den URL-Modus für die veröffentlichte Seite, behebe alle Fehler und behandle Warnungen als optionale Verbesserungen. Danach beobachte den entsprechenden Bericht in der Google Search Console. Ein bestandener Test bedeutet: Die Seite ist für ein Rich Result berechtigt, aber ein solches Ergebnis ist nicht garantiert.

Die Tool-Auswahl ist wichtig. Google beschreibt den Rich Results Test als „das offizielle Google-Tool, um dein strukturiertes Datenmaterial zu testen und zu sehen, welche Google-Rich-Results sich aus den strukturierten Daten auf deiner Seite erzeugen lassen“, in seiner Search Central-Dokumentation zu structured data.

Genau damit fange ich an, wenn jemand mich bittet, die Berechtigung für Rich Snippet(s) zu prüfen. Nicht mit einer Browser-Erweiterung, einem grünen Häkchen eines Plugins oder dem inzwischen eingestellten Structured Data Testing Tool, das in alten Tutorials genannt wird.

Eine Terminologie-Korrektur vorweg: Google nennt diese rich results jetzt so. „Rich snippet“ ist die ältere Formulierung, die viele noch verwenden. Beides beschreibt erweiterte Suchlisten, die z. B. Bewertungen, Preise, Bilder, Breadcrumbs, Event-Daten, Rezeptdetails und andere Informationen enthalten können – also mehr als nur der Standard aus Titel und Beschreibung.

Die strukturierten Daten sind nicht das eigentliche Suchergebnis. Es handelt sich um eine maschinenlesbare Beschreibung der Seite, üblicherweise als JSON-LD formuliert. Google kann auch Microdata und RDFa verarbeiten, aber JSON-LD ist in der Praxis meist einfacher zu erzeugen, zu prüfen und zu pflegen – ohne dass das Markup in sichtbares HTML „verstrickt“ wird.

Gültige strukturierte Daten schaffen Berechtigung. Google entscheidet weiterhin, ob eine Verbesserung für eine bestimmte Seite und eine bestimmte Suchanfrage erscheint. Genau diese Trennung erklärt einen großen Teil der Meldungen „Der Test ist bestanden, aber ich sehe kein Rich Snippet“.

So testest du ein Rich Snippet korrekt

Der Rich Results Test hat URL- und Code-Modus. Sie überlappen sich, beweisen aber nicht dasselbe.

1. Öffne Googles Rich Results Test.
2. Wähle URL für eine veröffentlichte Seite oder Code für HTML bzw. JSON-LD, das noch nicht ausgerollt wurde.
3. Führe den Test aus und lass Google den Input abrufen, rendern oder verarbeiten.
4. Öffne jeden erkannten Rich-Result-Typ, statt bei der Zusammenfassung zu stoppen.
5. Prüfe die Fehler, Warnungen und geparsten Properties jedes einzelnen Elements.
6. Behebe jeden Fehler und starte den Test erneut.
7. Deploye die Änderung, lösche relevante Caches und teste die Live-URL noch einmal.
8. Nachdem Google die betroffenen Seiten erneut gecrawlt hat, prüfe den passenden Search-Console-Bericht und validiere dort den Fix.

Starte im URL-Modus für Produktionsseiten

Der URL-Modus beantwortet die relevante Produktionsfrage: Was kann Google aus dieser URL gerade jetzt abrufen?

Dein JSON-LD kann in einem CMS-Feld perfekt sein und trotzdem auf der veröffentlichten Seite fehlen. Eine Template-Bedingung kann es unterdrücken, ein Cache kann noch die vorherige Version ausliefern, ein JavaScript-Fehler kann das Injizieren stoppen, oder das Production-Deployment kann die Komponente komplett weglassen. Der Editor ist ein Hinweis auf die Absicht. Die Live-URL ist ein Beleg für die Ausgabe.

Der URL-Modus rendert Seiten außerdem, dadurch kann er auch strukturierten Inhalt erkennen, der über JavaScript eingefügt wird. Trotzdem bevorzuge ich, wo es praktikabel ist, server-gerendertes JSON-LD, weil es einen weiteren Fehlerpunkt eliminiert (nicht jede Implementierung braucht noch ein zusätzliches bewegliches Teil).

Während unserer Migration im Januar 2026 von seojuice.io zu seojuice.com waren repräsentative Live-URL-Tests Teil der Release-Checkliste. Eine Migration kann das Schema-Template beibehalten, während Canonicals, Produktionspfade, Caches und die Seitenausgabe darum herum geändert werden. Nur den JSON-LD-Snippet zu testen, hätte den Großteil des Migrationsrisikos ignoriert.

Nutz den Code-Modus vor dem Publishing

Der Code-Modus ist praktisch, wenn du Markup baust oder bearbeitest. Füge das relevante HTML oder JSON-LD ein, führe den Test aus und repariere die Struktur, bevor du an der Produktion drehst.

Für hartnäckige Probleme: teste beides. Der Code-Modus sagt dir, ob das vorgeschlagene Markup akzeptiert wird. Der URL-Modus sagt dir, ob diese Version die Seite tatsächlich erreicht hat. Diese Ergebnisse laufen oft auseinander – und genau das ist der Hinweis, nicht die Unannehmlichkeit.

Wenn du erst einmal das JSON-LD bauen musst, nutze unseren Schema-Markup-Generator und leite dann dessen Output durch den Test von Google. Ein Generator kann Fehler bei Klammern, Verschachtelung und Property-Namen reduzieren. Er kann aber nicht prüfen, ob dein CMS die richtigen Daten liefert oder ob die Produktion den finalen Block tatsächlich rendert.

Errors blockieren die Berechtigung; Warnings meist nicht

Das ist die Unterscheidung, die du beim Lesen der Testausgabe im Kopf behalten solltest.

Ein „Item“ bedeutet ein konkretes, auf der Seite erkanntes strukturiertes-Daten-Objekt. Eine URL kann mehrere Items und mehrere Schema-Typen enthalten – jeweils mit unterschiedlichem Status.

Ich habe es schon erlebt, dass Teams Dutzende Warnungen weggeräumt haben, aber eine einzige erforderliche-Property-Fehlermeldung unbehandelt ließen. Das dreht die Prioritäten komplett um. Fixiere zuerst Blocker, starte dann den Test neu, und verschiebe wirklich hilfreiche Warnungen in ein Optimierungs-Backlog.

Eine Warning kann trotzdem auf schwache Quelldaten hinweisen. Beispiel: Ein optionales Bild oder ein Identifier kann Google helfen, ein Product besser zu verstehen und vollständiger darzustellen. Aber „recommended“ heißt nicht „heimlich erforderlich“ (und erfundene Werte hinzuzufügen, um eine Warning zu „stillen“, ist schlimmer als sie einfach stehen zu lassen).

So behebst du wiederkehrende Schema-Fehler

Fehlende erforderliche Properties

Der Rich Results Test nennt die fehlende Property normalerweise. Setz genau dort an, statt Plugins zu tauschen oder das JSON-LD einer anderen Website zu kopieren.

Ein Product-Item könnte z. B. seinen Namen vermissen oder die nötigen Informationen zu Offers, Review(s) oder Aggregate-Rating. Ein Recipe könnte ein Bild vermissen. Die Anforderungen unterscheiden sich je Rich-Result-Typ – öffne daher Googles Dokumentation für die erkannte Funktion und vergleiche die erwartete Struktur mit dem geparsten Item.

Verfolge die fehlende Property dann „upstream“. Wenn ein Template z. B. ein Preis-, Autor-, Bild- oder Datumsfeld erwartet und der CMS-Datensatz leer ist, behandelt das Bearbeiten des generierten JSON-LD nur das Symptom. Korrigiere stattdessen Content-Modell, Validierungsregel oder Template-Fallback.

Aus dem, was wir bei SEOJuice über mehrere Websites hinweg sehen, passieren die „unangenehmen“ Ausfälle meist genau an dieser Übergabestelle zwischen gültiger Schema-Logik und unvollständigen Seitendaten. Der Generator weiß, wohin ein Wert gehört; er kann keinen echten Preis oder sichtbare Reviews „herbeizaubern“, die auf der Seite gar nicht vorhanden sind. Und das sollte er auch nicht.

Falsche Typen und ungünstige Wertformate

Nicht alle Schema-Properties akzeptieren reinen Text. Eine Property verlangt möglicherweise eine Zahl, eine URL, ein Offer, eine PostalAddress oder ein anderes verschachteltes Objekt. Ein Wert kann für Leser plausibel wirken – und trotzdem maschinenlesbar vom falschen Typ sein.

Öffne das betroffene Item im Test, lokalisere die genaue Property und vergleiche ihren Wert mit dem erwarteten Typ. Wenn das Template denselben Fehler auf einer URL erzeugt, teste mehrere andere Seiten, die dieses Template nutzen. Ein einzelner Fehler ist oft ein Hinweis auf ein größeres Muster – kein isoliertes Seitenproblem.

Template einmal zu fixen ist der effiziente Schritt. 80 generierte Seiten manuell zu korrigieren sind 80 neue Gelegenheiten, denselben Fehler erneut zu machen (oder 79, wenn Glück dich beim ersten Edit nicht vollständig ausbremst).

Ungültige Datumsangaben

Properties wie datePublished, dateModified und startDate benötigen maschinenlesbare ISO-8601-Werte. Ein CMS kann „19. Juli 2026“ korrekt für Leser anzeigen und gleichzeitig eine lokalisierten oder mehrdeutigen Zeichenkette ins Schema geben.

Korrigiere das Date-Formatting auf Template-Ebene. Außerdem prüfe Zeitzonen für Events und Offers: Ein syntaktisch gültiger Zeitstempel kann trotzdem die falsche Start- oder Ablaufzeit kommunizieren.

Schema ist im Editor vorhanden, aber auf der Seite fehlt es

Lass die Produktions-URL durch den Rich Results Test laufen. Wenn der erwartete Typ nicht erkannt wird, prüfe die tatsächliche Ausgabe statt wiederholt am Schema-Objekt herumzuschrauben.

• Prüfe, ob das JSON-LD auf der ausgelieferten oder gerenderten Seite tatsächlich erscheint.
• Kontrolliere CMS- und Theme-Bedingungen, die steuern, wo es eingefügt wird.
• Überprüfe Plugin-Einstellungen und Ausschlüsse.
• Lösche relevante Page-, CDN- und Application-Caches (falls zutreffend).
• Prüfe, ob JavaScript fehlschlägt, bevor das Schema injiziert wird.
• Stelle sicher, dass Consent- oder Personalisierungslogik es nicht vor Crawlern „versteckt“.

SEOJuice generiert Schema automatisch auf den Seiten, die wir verwalten, aber Lida und ich testen dennoch repräsentative Ausgaben. Wir sind ein Team aus zwei Personen – Automatisierung ist daher essenziell. Automatisierung als unfehlbar zu behandeln, würde nur unsere blinden Flecken automatisiert mitlaufen lassen.

Doppeltes oder widersprüchliches Markup

Eine Seite kann Schema gleichzeitig von ihrem Theme, einem SEO-Plugin, einem Commerce-Plugin, einem spezialisierten Schema-Plugin und einem eigenen JSON-LD bekommen. Der Rich Results Test trennt die erkannten Items, wodurch unvollständige oder unerwartete Kopien leichter zu finden sind.

Feiere nicht ein einzelnes korrektes Product-Item, während du ein zweites kaputtes Product-Block ignorierst. Identifiziere, welches System jedes Objekt ausgibt, und bestimme einen Owner für diesen Schema-Typ. Redundante Ausgabe zu deaktivieren ist in der Regel sicherer, als mehrere Generatoren synchron halten zu wollen.

Sei aber vorsichtig, bevor du scheinbar doppelte Organization- oder WebSite-Elemente löschst. Ähnlich aussehende Objekte können unterschiedliche Entitäten beschreiben oder unterschiedliche Zwecke auf Seitenebene erfüllen. Vergleiche zuerst ihre Identifier, Typen und Beziehungen (das ist eine der Stellen, an der „duplicates entfernen“ zu grob ist).

Dein Markup muss zu sichtbarem Seiteninhalt passen

Technisch gültiges Markup kann trotzdem gegen Googles Richtlinien für strukturierte Daten verstoßen. Ein Validator prüft, ob die Daten geparst werden können; er bestätigt nicht, dass die Aussagen auch wahrheitsgemäß sind.

„Markiere keinen Content, der für Leser der Seite nicht sichtbar ist.“

Googles allgemeine Richtlinien zu structured data ergänzen: „Deine strukturierten Daten müssen eine echte Darstellung des Seiteninhalts sein.“ Die Konsequenz ist ebenfalls eindeutig: „Eine manuelle Maßnahme für strukturierte Daten bedeutet, dass eine Seite die Berechtigung für die Darstellung als Rich Result verliert.“

Füge keine aggregierten Review-Sterne hinzu, wenn Nutzer diese Reviews auf der Seite nicht finden können. Markiere kein Event-Datum, das die Seite nie anzeigt. Verwandle einen normalen Artikel nicht in ein Recipe-Objekt, nur weil das Recipe-Ergebnis prominenter wirkt.

Das gilt auch für veraltete Werte. Wenn sich der sichtbare Produktpreis ändert, aber gecachtes JSON-LD den alten Preis weiterführt, repräsentiert das Markup die Seite nicht mehr. Es kann perfekte Syntax haben – und trotzdem falsch sein.

Das alte Structured Data Testing Tool ist weg

Google hat sein altes Structured Data Testing Tool 2020 abgekündigt. Die generische schema.org-Validierung läuft jetzt über den Schema Markup Validator weiter. Für die Prüfung der Rich-Result-Berechtigung verweist Google auf den Rich Results Test.

• Rich Results Test: prüft, ob Google eine der unterstützten Suchfunktionen aus der Seite oder dem Code erzeugen kann.
• Schema Markup Validator: prüft das Markup gegen das breitere Schema.org-Vokabular – einschließlich Typen, die Google nicht als Rich Results darstellt.

Daher kann ein schema.org-Typ gültig sein, ohne jemals eine Google-Enhancement zu erzeugen. Das ist kein Widerspruch: schema.org beschreibt deutlich mehr Entitäten und Beziehungen, als Googles Suchgalerie unterstützt.

Nutze den Validator, um „Ist dieses Schema.org-Markup gültig?“ zu beantworten. Nutze Googles Tool, um „Ist es für ein Google Rich Result berechtigt?“ zu beantworten. Wenn du die tiefere Unterscheidung brauchst: Unser Schema.org-2026-Guide zeigt, was Google aktuell liest und nutzt.

Jag keine FAQ- oder HowTo-Rich-Results hinterher

Viele Schema-Tutorials, die ansonsten kompetent wirken, sind inzwischen veraltet.

Googles Live structured-data search gallery bleibt die Quelle, um vor der Implementierung eines Typs für Suchsichtbarkeit zu prüfen. Unterstützte Features sind u. a. Article, Breadcrumb, Dataset, Discussion forum, Event, Job posting, Local business, Organization, Product, Profile page, Q&A, Recipe, Review snippet, Software app, Vacation rental und Video.

FAQ und HowTo fehlen.

Google hat HowTo 2023 als Suchfeature entfernt. Im Dokumentations-Changelog steht: „How-to-structured-data-Dokumentation entfernt, da dieses Rich Result nicht mehr in den Suchergebnissen angezeigt wird – auf Desktop und Mobile.“

FAQ hielt sich zwar länger in einer eingeschränkten Form, aber auch das endete. Barry Schwartz berichtete in Search Engine Land, dass Google FAQ-Rich-Results zum 7. Mai 2026 eingestellt hat. Der Hinweis in Googles Dokumentation lautete:

„FAQ-Rich-Results erscheinen nicht mehr in der Google-Suche. Wir beenden im Juni 2026 die FAQ-Suchdarstellung, den Rich-Result-Bericht und den Support im Rich-results-test.“

FAQPage bleibt Teil von schema.org, und andere Systeme können es verarbeiten. Es wird kein Google-FAQ-Rich-Result generieren. HowTo-Markup kann weiterhin allgemein als instruktionaler Content beschrieben werden, aber es gibt in Google Search kein HowTo-Enhancement mehr.

Behalte sinnvolle FAQs und Schritt-für-Schritt-Anleitungen für Leser bei. Plane aber keine Implementierungszeit ein, weil du annimmst, diese beiden Schema-Typen würden Google-Rich-Snippets erzeugen. Diese Taktik ist abgelaufen.

Von One-Page-Tests zu Site-weitem Monitoring wechseln

Der Rich Results Test ist eine Diagnose auf Seitenebene. In der Search Console siehst du, was Google über alle gecrawlten Seiten hinweg gefunden hat.

Öffne den relevanten Bericht – z. B. Breadcrumbs, Product-Snippets oder Merchant-Listings. Prüfe die betroffenen URLs, finde das gemeinsame Template oder die gemeinsame Datenquelle, roll die Korrektur aus und wähle, sobald verfügbar, Fix validieren. Google muss die URLs erneut crawlen und verarbeiten, bevor sich der Bericht aktualisiert.

Die Search Console ist langsamer als Tests mit eingefügtem Code, weil sie den Crawl-Zyklus von Google abbildet – nicht deine aktuellste lokale Änderung. Diese Verzögerung kann nerven (ich habe diese Berichte schon mehrfach aktualisiert und wusste dabei genau, dass sich nichts ändert), aber sie ist auch der Grund, warum die Daten wertvoll sind: Sie repräsentieren Produktionsseiten in großem Maßstab.

Unser kostenloser SEO-Audit kann helfen, breitere Probleme auf der Website zu identifizieren, bevor du die Untersuchung auf einzelne URLs eingrenzt. Bestätige die Rich-Result-Berechtigung anschließend im eigenen Test von Google; ein Audit von Drittanbietern sollte nicht die finale Autorität für Googles Feature sein.

Warum ein bestandener Test kein Rich Result erzeugen kann

Ein gültiges Ergebnis bedeutet Berechtigung – nicht garantierte Anzeige.

Google entscheidet, ob es für jede Suchanfrage und jedes Ergebnis ein Enhancement zeigt. Die Suchdarstellung kann außerdem durch die Seitenqualität, irreführendes oder nicht zusammenpassendes Markup, nicht unterstützte Feature-Typen und manuelle Maßnahmen zu strukturierten Daten beeinflusst werden.

Wenn der Test besteht, aber kein Enhancement erscheint:

1. Stell sicher, dass du die finalen Canonical-URL getestet hast.
2. Prüfe, dass die markierten Informationen sichtbar und aktuell sind.
3. Überprüfe den entsprechenden Search-Console-Bericht.
4. Prüfe in der Search Console nach manuellen Maßnahmen.
5. Verifiziere, dass der Schema-Typ weiterhin in der Google-Suchgalerie erscheint.
6. Beobachte mehrere relevante Suchanfragen – statt eine manuelle Suche als endgültig zu betrachten.

Diese Diagnose-Reihenfolge ist für mich schlüssig. Exakt vorherzusagen, wann Google ein berechtigtes Ergebnis mit einem Rich Feature auszeichnet, ist weniger sicher, weil Google keine Anzeige-Garantie gibt. Bereits korrektes JSON-LD jedes Mal neu zu schreiben, wenn ein Rich Result verschwindet, kann neue Fehler erzeugen – ohne die zugrunde liegende Entscheidung zu verändern.

Berechtigung und Darstellung sind nicht nur beim Schema getrennt. Unser Guide zu SERP snippets und AI visibility erklärt, warum Indexierung und Snippet-Kontrolle weiterhin relevant sind – auch dann, wenn Suchplattformen am Ende selbst über die finale Darstellung entscheiden.

Häufig gestellte Fragen

Wie teste ich, ob meine Seite für Rich Results qualifiziert?

Füge die veröffentlichte URL in Googles Rich Results Test ein. Nutze den Code-Modus für HTML oder JSON-LD, das noch nicht veröffentlicht wurde. Das Tool identifiziert unterstützte Rich-Result-Typen und listet Fehler, Warnungen sowie geparste Properties. Für aggregierte Informationen über gecrawlte Seiten nutzt du die Search Console.

Was ist mit dem Structured Data Testing Tool passiert?

Google hat das alte Structured Data Testing Tool abgeschaltet. Nutze den Rich Results Test für die Googlesche Rich-Result-Berechtigung und den Schema Markup Validator unter validator.schema.org für die breitere schema.org-Validierung.

Was ist der Unterschied zwischen dem Rich Results Test und dem Schema Markup Validator?

Der Rich Results Test prüft, ob das Markup ein von Google unterstütztes Rich Result erzeugen kann. Der Schema Markup Validator prüft die generelle schema.org-Gültigkeit – einschließlich Vokabular, das Google nicht für Such-Enhancements verwendet. Dass der Validator „passiert“, beweist keine Googlesche Berechtigung.

Was ist der Unterschied zwischen einem Schema-Fehler und einer Warning?

Ein Fehler bedeutet: Eine erforderliche Property fehlt oder ist ungültig, wodurch das betroffene Item nicht berechtigt ist. Eine Warning heißt meist: Eine empfohlene Property fehlt, während das Item weiterhin berechtigt bleibt. Behebe zuerst alle Fehler und bewerte dann Warnungen anhand ihrer Nützlichkeit und der Daten, die tatsächlich auf der Seite angezeigt werden.

Generiert FAQ-Schema 2026 noch Rich Results?

Nein. Google hat FAQ-Rich-Results am 7. Mai 2026 vollständig entfernt und anschließend auch den zugehörigen Test- und Reporting-Support gestrichen. FAQPage bleibt gültiges schema.org-Vokabular, erzeugt aber kein Google-FAQ-Rich-Result mehr.

Warum wird auf meiner Live-Seite kein Schema erkannt?

Das Markup ist möglicherweise nicht bis in die Produktion gelangt, wird möglicherweise durch eine Template-Bedingung unterdrückt, steckt hinter veraltetem Caching oder hängt von JavaScript ab, das beim Rendern fehlgeschlagen ist. Vergleiche Code-Modus mit URL-Modus, prüfe dann das gerenderte Produktionsoutput und jedes System, das Schema injizieren kann.

Warum wird mein Rich Result nicht angezeigt, obwohl der Test besteht?

„Bestanden“ heißt: Die Seite ist berechtigt, aber die Anzeige eines verbesserten Eintrags ist nicht garantiert. Stelle sicher, dass das Markup zu sichtbarem Content passt, prüfe den relevanten Search-Console-Bericht, verifiziere, dass die Funktion weiterhin unterstützt wird, und stelle sicher, dass es auf der Seite keine manuelle Maßnahme zu strukturierten Daten gibt.

Wenn du JSON-LD generierst oder reparierst: Starte mit einer repräsentativen Seite, teste sie im Code-Modus, deploye sie und teste anschließend die Live-URL. Sobald diese Seite sauber ist, übertrage die Template-Level-Korrektur über die gesamte Website und lass die Search Console die Ergebnisse im großen Maßstab bestätigen.