Ein Schema-Markup zu testen beantwortet zwei Fragen, die oft verwechselt werden: Ist der Code formal in Ordnung, und spielt Google daraus etwas in den Suchergebnissen aus. Der Rich Results Test beantwortet die erste zuverlässig. Die zweite beantwortet er nur teilweise, und genau dort hängen die meisten Projekte fest.
Die Werkzeuge selbst setze ich hier voraus. Wie Rich Results Test, Schema Markup Validator und die Berichte unter „Verbesserungen" im Einzelnen funktionieren, steht in unserem Artikel zu den Grundlagen der Schema-Prüfung. Dieser Text baut darauf auf und behandelt den Teil danach: die Lücke zwischen gültig und sichtbar, die Prüfung von hunderten Seiten statt einer, und die Fehlerbilder, die formal korrekt sind und trotzdem schaden.
Gültig heißt nicht, dass Google es ausspielt
Ein Validator prüft Syntax und Pflichtfelder gegen eine Spezifikation. Ob ein Rich Result erscheint, entscheidet Google zusätzlich anhand von Dingen, die kein Validator sehen kann: Ist die Seite überhaupt indexiert, gehört der Typ noch zu den ausgespielten Formaten, hält die Seite die Richtlinien ein, und passt das Ergebnis nach Googles Einschätzung zur Suchanfrage. Ein Anspruch auf Darstellung entsteht durch korrektes Markup nicht.
In der Praxis stecken Sie also an einer von zwei getrennten Hürden fest, und die Unterscheidung spart Ihnen Tage. Erkennen lässt sie sich so:
Der Test erkennt gar nichts. Dann liegt es am Code oder am Rendering. Prüfen Sie im Tab mit dem gerenderten HTML, ob der JSON-LD-Block überhaupt ankommt. Markup, das erst ein Skript nachträglich einfügt, fehlt manchmal in der Version, die Google indexiert hat.
Der Test zeigt ein gültiges Element samt Vorschau, die Suche zeigt nichts. Dann ist der Code nicht das Problem. Jetzt hilft die URL-Prüfung in der Search Console, weil sie den indexierten Stand zeigt und nicht den Live-Abruf. Weichen beide ab, testen Sie gerade eine Seite, die Google so nie gesehen hat.
Beides stimmt, trotzdem nichts. Dann bleiben drei Ursachen: der Typ wird für Ihre Art von Seite nicht mehr ausgespielt, eine manuelle Maßnahme liegt an, oder Google hält das Ergebnis schlicht nicht für passend. Die ersten beiden können Sie prüfen, die dritte nicht.
Gut zu wissen: Die Berichte in der Search Console hinken dem Live-Stand etwa zwei bis drei Tage hinterher. Wer eine Stunde nach dem Deploy dort nachsieht und nichts findet, hat nichts gemessen.
Schema-Markup validieren im Massenbetrieb statt Seite für Seite
Bei 500 Produktseiten fällt der einzelne Validator-Klick aus. Was Sie stattdessen brauchen, ist ein Vorgang in vier Schritten, den jeder gängige Crawler mit Extraktionsfunktion abbilden kann.
Zuerst sammeln Sie ein: ein Crawl über die Sitemap, aus jeder Seite alle Blöcke vom Typ application/ld+json. Wenn Ihr Markup aus JavaScript stammt, muss der Crawl rendern, sonst messen Sie das falsche Dokument.
// je Seite: alle JSON-LD-Bloecke einsammeln und parsen
const bloecke = [...document.querySelectorAll('script[type="application/ld+json"]')]
.map((el) => JSON.parse(el.textContent));Dann parsen Sie. Alles, was hier eine Ausnahme wirft, ist der erste Fehlertopf: ein Komma zu viel, ein nicht maskiertes Anführungszeichen aus einem Produkttitel, ein abgeschnittener Block. Diese Fehler kosten Sie das komplette Markup der Seite, nicht nur ein Feld.
Der dritte Schritt ist der eigentliche Kern: Sie hinterlegen je Seitenvorlage ein erwartetes Schema. Nicht die Schema.org-Spezifikation, sondern Ihre eigene Erwartung an diese Vorlage.
{
"Produktseite": {
"typen": ["Product", "BreadcrumbList"],
"pflicht": ["name", "image", "offers.price", "offers.priceCurrency"],
"formate": { "offers.price": "^[0-9]+\\.[0-9]{2}$" }
}
}Zuletzt der Bericht. Sortieren Sie ihn nach Vorlage, nicht nach URL. Wenn 480 von 500 Produktseiten dasselbe leere Feld haben, ist das ein Befund und keine 480. Welche Typen zu welcher Vorlage überhaupt gehören, klärt vorher unser Überblick über die passenden Schema.org-Typen.
Auf seofx.de läuft dieselbe Prüfung über die über 200 Lexikon-Seiten, die jeweils einen Graph aus vier Typen tragen. Ein einziges Feld, das die Vorlage nicht mehr füllt, wäre dort sofort 205 Mal falsch.
Regressionen erkennen, bevor sie jemand meldet
Markup verschwindet selten mit einem Knall. Häufiger passiert das hier: Ein Plugin-Update ändert einen Filter, ein Feld bleibt leer, und niemand merkt es, weil die Seite optisch identisch aussieht. Wer Schema über Plugins bezieht, ist davon stärker betroffen als jemand, der JSON-LD direkt im Theme pflegt, weil die Änderung von außen kommt.
Die Gegenmaßnahme ist der Vergleich mit dem Vortag, nicht die erneute Prüfung gegen die Spezifikation. Speichern Sie das Ergebnis jedes Massenlaufs und melden Sie Abweichungen: Die Zahl der Seiten mit Product ist gefallen. Die Füllquote von offers.price ist von 100 auf 92 Prozent gesunken. Ein Typ ist neu aufgetaucht, den niemand bestellt hat.
Für den Weg in die Entwicklung reicht ein kleinerer Aufbau: eine Beispiel-URL je Vorlage, deren JSON-LD als Referenzdatei im Repository liegt. Der Build vergleicht und bricht ab, wenn sich etwas ändert, das niemand geändert haben wollte. Das kostet einmal eine Stunde Einrichtung und fängt genau die Klasse von Fehlern, die sonst erst Wochen später in einem Bericht auftaucht.
Praxis-Tipp: Prüfen Sie nach jedem Plugin- oder Theme-Update gezielt die Vorlagen, die Umsatz tragen, statt die ganze Domain. Fünf Seitentypen in fünf Minuten schlagen einen vollständigen Crawl, den Sie erst nächsten Monat auswerten.
Fehlerbilder, die kein Validator meldet
Die unangenehmen Fälle sind formal sauber. Der Validator zeigt grün, und trotzdem ist das Markup falsch oder sogar gefährlich.
Angaben ohne sichtbare Entsprechung. Im Markup steht ein Preis, eine Bewertung oder eine Frage, die auf der Seite nirgends steht. Das verstößt gegen Googles Richtlinien für strukturierte Daten und kann eine manuelle Maßnahme nach sich ziehen. Dann verschwinden die Rich Results komplett, nicht nur die eine Angabe. Die Regeln dazu stehen in der Google-Dokumentation zu strukturierten Daten.
Verweise ins Leere. Ein @id zeigt auf einen Knoten, den es im Graph nicht gibt, weil ein Bezeichner beim Umbau umbenannt wurde. Syntaktisch korrekt, inhaltlich ein Bruch. Prüfen Sie im Massenlauf, ob jede referenzierte Kennung auch als Knoten existiert.
Veraltete Werte. Preis und Verfügbarkeit werden aus einem Cache erzeugt, der Seitenkörper aus der Datenbank. Beide sind gültig, beide widersprechen sich. Das ist der häufigste stille Fehler in Shops.
Bewertungen ohne Bewertungen. Ein aggregateRating mit vier Sternen aus 87 Stimmen, während auf der Seite keine einzige Bewertung zu lesen ist. Google hat diese Konstruktion 2019 ausdrücklich als Missbrauch eingestuft.
Meine Meinung dazu: Ein grüner Haken im Validator ist eine Zusage über Syntax, sonst nichts. Wer ihn als Abnahme ausgibt, verkauft eine Prüfung, die über die Suchergebnisse keine Aussage macht.
Was Sie gar nicht mehr testen müssen
Zwei Typen können Sie von der Liste streichen. HowTo-Rich-Results hat Google 2023 abgeschaltet, das Markup erzeugt in der Suche nichts mehr. FAQ-Rich-Results zeigt Google seither nur noch für Behörden- und Gesundheitsseiten. Wer weiter Zeit in FAQ-Fehler aus alten Berichten steckt, optimiert an einer Darstellung, die für ihn ohnehin nicht erscheint.
Weiterhin sinnvoll zu testen sind unter anderem Product, Recipe, Event, JobPosting, BreadcrumbList und VideoObject. Bei Videos lohnt der genaue Blick besonders, weil dort Dauer und Vorschaubild eigene Formatregeln haben: die Pflichtfelder eines VideoObject sind schnell falsch gefüllt und fallen im Validator nur zum Teil auf.
Fazit
Testen Sie in zwei Schritten: erst die Gültigkeit, dann die Auslieferung. Wer diese beiden Fragen trennt, sucht den Fehler an der richtigen Stelle, statt ein bereits korrektes Markup immer wieder umzubauen. Ab einigen Dutzend Seiten gehört die Prüfung automatisiert, und ab dem ersten Plugin-Update gehört ein Vergleich mit dem Vorlauf dazu.
