Strukturierte Daten debuggen.
Fehler in strukturierten Daten zeigen auf der Seite kein Symptom; sichtbar werden sie nur durch ein Validierungswerkzeug oder einen Test.
Die heimtückischste Eigenschaft strukturierter Daten ist ihr lautloses Brechen. Geht ein Schemablock kaputt, sieht die Seite weiter normal aus, keine Fehlermeldung erscheint, kein sichtbares Symptom. Nur die Maschinen können den Block nicht mehr lesen — und niemand sagt es Ihnen. Der Defekt kann Monate leben.
Deshalb kann Schema nicht einmal nach dem Schreiben validiert und dann liegen gelassen werden. Die Validierung muss Teil des Deployment-Prozesses sein; sonst bricht die nächste Inhaltsänderung sie lautlos.
Zwei Schichten: Syntax und Bedeutung
Das Debugging hat zwei getrennte Schichten, und sie fangen Verschiedenes. Die erste ist die Syntax: Ist der Block eine gültige Datenstruktur, lässt er sich parsen? Ein einziges fehlendes Komma oder ein nicht maskiertes Anführungszeichen macht sämtliche strukturierten Daten dieser Seite ungültig — ein teilweises Lesen gibt es nicht.
Die zweite ist die Bedeutung: Beschreibt die entstandene Knotenliste, was die Website wirklich ist? Ein Graph mit fehlerfreier Syntax und sinnlosem Inhalt ist technisch gültig und nützt nichts. Validierungswerkzeuge fangen die erste Schicht automatisch; die zweite verlangt menschliches Urteil.
- Syntax — lässt sich der Block parsen? Automatische Werkzeuge fangen das.
- Pflichtfelder — sind die vom Typ verlangten Felder gefüllt? Automatische Werkzeuge warnen.
- Format — sind Datums-, Dauer- und Zahlenfelder in der erwarteten Form? Automatisch.
- Identitätsverknüpfungen — sind die referenzierten Kennungen wirklich definiert? Teilweise automatisch.
- Konsistenz mit dem Bildschirm — steht, was das Schema sagt, auch auf dem Bildschirm? MENSCHLICHES Urteil.
- Bedeutung — beschreibt der Graph die Website richtig? MENSCHLICHES Urteil.
Die letzten beiden Zeilen sind die wichtigsten, und kein Werkzeug deckt sie ab. Eine Information, die im Schema steht, aber nicht auf dem Bildschirm, erscheint im Validierungswerkzeug grün — denn das Werkzeug liest nicht die Seite, nur den Block. Diesen Verstoß fängt nur ein Mensch oder ein eigens geschriebener Test.
Häufige Bruchstellen
Die auf echten Websites wiederkehrenden Fehler sind bekannt, und die meisten entstehen aus Inhaltsänderungen.
Nicht maskierte Sonderzeichen. Ein Anführungszeichen oder ein Backslash im Inhalt, direkt in den Schemablock geschrieben, bricht die Struktur. Das ist die häufigste Bruchursache bei handgeschriebenem Schema — und kommt in generiertem Schema nie vor, weil dort automatisch maskiert wird.
Leer gebliebene Felder. Wird ein Inhaltsfeld gelöscht, kann im Schema ein leerer Wert zurückbleiben. Ein leeres Feld ist schlimmer als ein fehlendes: Es sieht aus, als sei der Typ gefüllt, trägt aber keine Information.
Gerissene Identitätsverweise. Ein Knoten kann auf die Kennung eines Knotens zeigen, der nicht mehr erzeugt wird. Der Graph bleibt technisch gültig, aber der Verweis führt ins Leere, und die Struktur löst sich auf.
Veraltete Daten. Die Seite wird aktualisiert, das Datum im Schema bleibt. Das verfälscht das Frischesignal und führt mit der Zeit dazu, dass die Maschine ihm nicht mehr vertraut.
Die dauerhafte Lösung: an einen Test binden
Manuelle Validierung hilft genau einmal. Die dauerhafte Lösung ist, die Schemaprüfung an den Deployment-Prozess zu binden: Die Blöcke jeder Seite werden geparst, die Knotentypen gelistet und mit der erwarteten Struktur verglichen.
Auf dieser Website lebt diese Prüfung in der Prüfsuite. Bei jedem Lauf wird gemessen, dass der Schemagraph jeder Route die erwarteten Knoten trägt, dass keine Identitätsverknüpfung gerissen ist und dass die Frage-Antwort-Blöcke auf dem Bildschirm mit dem Schema übereinstimmen. Bricht eine Inhaltsänderung das Schema, wird der Defekt im Moment des Deployments sichtbar — nicht bei der nächsten Prüfung.
Und die wertvollste Testart ist der umgekehrte Wächter: der Test, der verifiziert, dass etwas, das nicht existieren sollte, nicht hinzugefügt wurde. Ein erfundener Profil-Link, eine ungemessene Ergebniszahl, ein unveröffentlichter Preis — alle drei können in guter Absicht ergänzt werden, und alle drei sind Regelverstöße. Der umgekehrte Wächter kontrolliert auch die guten Absichten der Zukunft.
Validierungswerkzeuge und ihre Grenzen
Es gibt einige Werkzeuge, und jedes beantwortet eine andere Frage. Der eigene Validator von schema.org prüft Syntax und Typgültigkeit — er hat den breitesten Umfang. Die Rich-Ergebnis-Testwerkzeuge der Suchmaschinen stellen dagegen eine enge Frage: Genügt dieser Block, damit wir ein Rich-Ergebnis erzeugen? Beides sind verschiedene Dinge, und eines kann bestehen, während das andere durchfällt.
Diese Unterscheidung verwirrt in der Praxis. Eine „nicht geeignet“-Warnung im Rich-Ergebnis-Werkzeug heißt nicht, dass das Schema kaputt ist — sie zeigt nur, dass die Felder fehlen, die diese Maschine für diese Darstellung will. Das Schema kann trotzdem gültig sein und für Antwortmaschinen seine Arbeit tun.
- Allgemeiner Validator — Syntax und Typgültigkeit. Breitester Umfang.
- Rich-Ergebnis-Test — Eignung für eine bestimmte Darstellung. Enger Umfang.
- Search-Console-Berichte — auf Live-Seiten erkannte Fehler. Verzögert, aber real.
- Der eigene Test — projektspezifische Regeln. Stellt die Fragen, die die Werkzeuge nicht stellen.
Die vierte Zeile ist die wertvollste, weil sie die Lücke füllt, die die anderen drei lassen: dass die Information im Schema auch auf dem Bildschirm existiert, dass kein erfundenes Feld hinzugekommen ist und dass die Daten wirklich aktuell sind — nichts davon kann ein allgemeines Werkzeug prüfen, und alles davon kann ein Test prüfen.
Die Reihenfolge des Debuggens
Wird bei einer Seite ein Schemaproblem vermutet, spart eine feste Reihenfolge Zeit. Zuerst: Steht der Block wirklich auf der Seite — in den Quelltext schauen und die Existenz bestätigen; in überraschend vielen Fällen hängt der Block an einer Bedingung und wurde nie gedruckt. Dann: Lässt er sich parsen — in einen Validator einfügen. Dann: Stimmen die Typen, sind die Felder gefüllt. Zuletzt: Ist er konsistent mit dem Bildschirm.
Wird diese Reihenfolge übersprungen, ist der häufigste Fehler, Stunden auf der Bedeutungsschicht zu verbringen und zu spät zu merken, dass das Problem ein simpler Syntaxbruch war. Die ersten beiden Schritte dauern eine Minute und lösen die Mehrzahl der Fälle.
Und jeder einmal gelöste Fehler sollte in einen Test verwandelt werden. Fast alle Schemabrüche wiederholen sich — denn ihre Ursachen sind strukturell, nicht zufällig. Ein Maskierungsfehler, der einmal passiert ist, passiert wieder; ein Test, der ihn fängt, erspart es, dieselben Stunden noch einmal auszugeben.