Structured Data testen und debuggen — Tools, Fehler und ein sauberer Workflow
Structured Data testen und debuggen — Tools, Fehler und ein sauberer Workflow
Structured Data ist nur dann etwas wert, wenn Google sie korrekt liest. Ein Tippfehler in einem Property-Namen, ein falscher Datentyp oder ein fehlendes Pflichtfeld — und der Rich Result, auf den du gehofft hast, erscheint nicht. Das Tückische: Solche Fehler sind im Quelltext unsichtbar, der HTML-Code sieht aus wie immer. Deshalb braucht es Werkzeuge, die dir zeigen, was Google tatsächlich aus deinem Markup macht. Dieser Artikel sortiert die drei wichtigsten Tools, erklärt den Unterschied zwischen Fehler und Warnung und gibt dir einen Debug-Workflow, der reproduzierbar funktioniert.
Die drei Werkzeuge — und was jedes zeigt
Es gibt nicht das eine Tool, sondern drei, die unterschiedliche Fragen beantworten. Sie verwechseln heißt, am falschen Bild zu verzweifeln.
Rich Results Test (Google). Zeigt, welche Google-Rich-Results dein Markup auf einer konkreten Seite auslösen kann, und liefert eine Vorschau, wie der Rich Result in der Suche aussehen könnte (Quelle: Google Search Central, abgerufen 2026-06-06). Das ist die Google-Brille: Es prüft nicht jedes Schema-Detail, sondern nur die Typen, die Google überhaupt für Rich Results unterstützt. Du kannst eine Live-URL oder einen Code-Schnipsel einwerfen.
Schema-Markup-Validator (schema.org). Validiert jegliches schema.org-basierte Markup auf einer Seite — ohne Google-spezifische Warnungen. Das ist die generische Brille: breiter, weil er auch Typen kennt, die Google nicht für Rich Results verwertet, aber neutraler, weil ihn nicht interessiert, ob Google daraus ein hübsches Suchergebnis baut. Google hat sein altes Structured-Data-Testing-Tool eingestellt und die reine Schema-Validierung an diesen Validator abgegeben.
Search-Console-Berichte (Rich-Result-Statusberichte). Zeigen das Aggregat über deinen echten Index — also welche strukturierten Daten Google auf deiner ganzen Site gefunden hat und ob sie gültig sind, inklusive Trend über die Zeit (Quelle: Search Console Help, abgerufen 2026-06-06). Der Bericht hat eine Übersichtsseite mit einem Chart aus Fehlern, Warnungen und gültigen Elementen sowie eine Detailseite pro Problemtyp. Das ist die Realitätsbrille: Hier siehst du nicht eine Testseite, sondern was Google im laufenden Betrieb auf allen deinen URLs registriert.
Kurz: Rich Results Test und Validator prüfen eine Seite jetzt, die GSC-Berichte zeigen die ganze Site über Zeit.
Fehler vs. Warnung — der entscheidende Unterschied
Sowohl der Rich Results Test als auch die GSC-Berichte trennen scharf zwischen zwei Schweregraden, und diese Trennung musst du verstehen, sonst jagst du die falschen Probleme.
Fehler (rot). Ein Element mit mindestens einem kritischen Problem — typischerweise ein fehlendes Pflichtfeld (required property). Ein Element mit fehlenden Pflicht-Properties ist nicht für Rich Results berechtigt (Quelle: Search Console Help, abgerufen 2026-06-06). Fehler blockieren also den Rich Result vollständig. Das ist das, was du zuerst beheben musst.
Warnung (gelb). Das Markup ist gültig, könnte aber besser sein — meist fehlt eine empfohlene Property (recommended property). Die Seite kann trotzdem als Rich Result erscheinen. Je mehr empfohlene Properties du lieferst, desto hochwertiger ist das Ergebnis für die Nutzer. Warnungen sind also Optimierungspotenzial, kein Blocker.
Erst die Fehler, dann die Warnungen
In den GSC-Berichten lohnt es sich, Warnungen und gültige Elemente erst auszublenden und sich auf die Fehler zu konzentrieren. Ein behobener Fehler schaltet einen Rich Result frei; eine behobene Warnung macht ihn nur etwas besser.
Typische Fehler — und warum sie passieren
Drei Fehlerklassen tauchen immer wieder auf:
Fehlende Pflicht-Properties. Der häufigste Fehler. Jeder Rich-Result-Typ hat eine Liste erforderlicher Properties in der Google-Doku. Fehlt eine davon, ist das Element rot und disqualifiziert. Beispiel: Ein Product-Markup ohne name oder ein Recipe ohne recipeIngredient.
Markup für nicht sichtbaren Content. Google verbietet ausdrücklich: Markiere keinen Content aus, der für die Leser der Seite nicht sichtbar ist (Quelle: Google Search Central, abgerufen 2026-06-06). Strukturierte Daten müssen den sichtbaren Seiteninhalt abbilden. Wer eine Bewertung von 4,9 Sternen ins Markup schreibt, die nirgends auf der Seite steht, verstößt gegen die Richtlinien — und riskiert eine manuelle Maßnahme, die die Rich-Result-Berechtigung entzieht (sie betrifft nicht das normale Web-Ranking).
Falsche Datentypen. Ein Datum als Freitext statt im ISO-Format, ein Preis als String mit Währungssymbol statt als sauberer Zahlenwert, eine URL ohne Protokoll. Solche Typfehler bemerkt man im HTML nicht, der Validator schon.
Ein sauberer Debug-Workflow
Damit das Debuggen nicht zum Rätselraten wird, hilft eine feste Reihenfolge:
- Code isolieren mit dem Schema-Validator. Wirf den Markup-Schnipsel zuerst in den schema.org-Validator. Er sagt dir neutral, ob das Schema syntaktisch korrekt und typrichtig ist — ohne Google-Logik dazwischen.
- Google-Sicht prüfen mit dem Rich Results Test. Erst danach prüfst du, ob Google daraus einen Rich Result bauen kann. Hier siehst du fehlende Pflichtfelder für den konkreten Typ und die Vorschau.
- Sichtbarkeit gegenchecken. Stelle sicher, dass jeder Wert im Markup auch real auf der Seite steht. Das ist der Richtlinien-Check, den kein Tool für dich macht.
- Im echten Index beobachten mit der GSC. Nach dem Deployment kontrollierst du den Rich-Result-Statusbericht über Tage und Wochen — er zeigt dir, ob Google das Markup auf allen betroffenen URLs annimmt und ob neue Fehler auftauchen.
Die ersten drei Schritte sind Vorab-Validierung an einer Seite, der vierte ist die laufende Überwachung der ganzen Site. Beides zusammen verhindert, dass ein stiller Fehler monatelang Rich Results kostet.
FAQ
Was ist der Unterschied zwischen Rich Results Test und Schema-Markup-Validator?
Der Rich Results Test ist Googles Brille: Er zeigt nur die Typen, die Google für Rich Results unterstützt, und liefert eine Suchvorschau. Der schema.org-Validator ist generisch: Er prüft jegliches schema.org-Markup auf syntaktische Korrektheit, ohne Google-spezifische Warnungen, und kennt auch Typen ohne Rich-Result-Bezug. Für die Fehlersuche nutzt du beide nacheinander.
Warum erscheint mein Rich Result nicht, obwohl der Test grün ist?
Ein grüner Test heißt nur: Das Markup ist gültig und berechtigt dich für einen Rich Result. Eine Garantie ist es nicht. Google entscheidet selbst, ob und wann ein Rich Result ausgespielt wird — abhängig von Qualität, Sichtbarkeit des Contents und algorithmischer Einschätzung. Außerdem braucht Google Zeit, die Seite neu zu crawlen, bevor sich etwas in der Suche zeigt.
Muss ich alle Warnungen beheben?
Nein. Warnungen betreffen empfohlene, nicht erforderliche Properties — die Seite kann auch mit Warnungen als Rich Result erscheinen. Sie sind aber Qualitätspotenzial: Je vollständiger dein Markup, desto reicher und nützlicher das Ergebnis. Priorisiere immer zuerst die roten Fehler, danach lohnen sich die Warnungen.
Was passiert, wenn ich Content auszeichne, der nicht sichtbar ist?
Das ist ein Richtlinienverstoß. Strukturierte Daten müssen den für Nutzer sichtbaren Seiteninhalt abbilden. Markierst du Unsichtbares — etwa erfundene Bewertungen oder versteckte Texte — kann Google eine manuelle Maßnahme verhängen. Die Folge: Die Seite verliert die Berechtigung für Rich Results. Das normale Web-Ranking bleibt davon unberührt, aber der Rich Result ist weg.
Reicht der Rich Results Test allein zur Überwachung?
Nein. Der Rich Results Test prüft immer nur eine URL zu einem Zeitpunkt. Für die laufende Kontrolle über die ganze Site brauchst du die Rich-Result-Statusberichte der Search Console — sie aggregieren über den echten Index und zeigen Trends, sodass du neu auftretende Fehler nach einem Deployment früh bemerkst.
Entdecke mehr
Technisches SEO — was Google wirklich crawlen, rendern und indexieren muss
Wie Crawl-Budget, Robots, Sitemap, JS-Rendering, Indexierung, Canonical und Core Web Vitals zusammenspielen — der vollständige Bogen für produktive Sites.
GlossarAuthor Schema / sameAs
Strukturierte Auszeichnung des Autors einer Seite via Schema.org `Person` mit `sameAs`-Array auf Profil-URLs (LinkedIn, ORCID, Mastodon) — unterstützt E-E-A-T und Knowledge-Graph-Erkennung.
LexikonJSON-LD und strukturierte Daten — Grundlagen
Strukturierte Daten machen Inhalte maschinenlesbar. Warum Google JSON-LD bevorzugt, wie ein Block aufgebaut ist und warum Markup kein Rich Result garantiert.