Strukturierte Daten testen und Fehler beheben

Den zu prüfenden Stand eindeutig festhalten

Notieren Sie URL, Zeitpunkt und den tatsächlichen Auslieferungsstand. Ein eingefügter Codeausschnitt kann etwas anderes enthalten als die veröffentlichte Seite. Deshalb benötigen Sie bei einer späteren Freigabe immer auch einen Test der öffentlichen Fassung. Prüfen Sie bei dynamischer Ausgabe, ob die erforderlichen Daten unter den untersuchten Bedingungen tatsächlich verfügbar sind.

Sichern Sie den konkreten Befund mit betroffener Eigenschaft und Meldung. „Schema funktioniert nicht“ ist kein brauchbarer Arbeitsauftrag. Entwicklung und Redaktion müssen erkennen, welches Objekt betroffen ist, welcher Wert erwartet wird und woher dieser Wert kommen soll. So werden technische Korrekturen nicht mit ungesicherten inhaltlichen Ergänzungen verwechselt.

Allgemeines Vokabular und Syntax kontrollieren

Ein Schema.org-Validator hilft dabei, die strukturierte Beschreibung und die verwendeten Typen zu untersuchen. Syntaxfehler, falsch geschriebene Eigenschaften oder unerwartete Verschachtelungen lassen sich damit gezielt eingrenzen. Lesen Sie die Ausgabe im Zusammenhang mit der geplanten Modellierung, statt nur nach einer grünen Gesamtmeldung zu suchen.

Ein vorhandener Wert kann technisch lesbar und trotzdem fachlich unzutreffend sein. Auch eine formal korrekt dargestellte Organisation könnte die falsche sein. Deshalb ist diese Prüfung eine Ebene des Verfahrens. Sie beantwortet nicht sämtliche Fragen zur Wahrheit der Angaben oder zur Unterstützung einer besonderen Darstellung in einem Suchdienst.

Anforderungen einer konkreten Suchfunktion prüfen

Der Google Rich Results Test untersucht unterstützte strukturierte Daten im Hinblick auf entsprechende Suchfunktionen. Ein allgemeiner Schema.org-Typ ohne unterstützte Google-Funktion ist deshalb nicht automatisch fehlerhaft, wenn er dort keine passende Erweiterung ergibt. Klären Sie vor dem Test, welche Aussage das Werkzeug überhaupt prüfen kann.

Unterscheiden Sie gemeldete Fehler von Empfehlungen oder Warnungen und lesen Sie die Dokumentation des konkreten Typs. Ergänzen Sie keine erfundenen Werte, nur um einen Hinweis zu beseitigen. Wenn eine erforderliche Angabe sachlich nicht vorhanden ist, muss die Eignung dieses Anwendungsfalls neu bewertet werden. Die Lösung ist dann nicht zwingend ein zusätzliches Feld.

Den sichtbaren Inhalt als fachliche Gegenprüfung verwenden

Vergleichen Sie Überschrift, Autor oder Organisation, Bild, Datumsangaben und gegebenenfalls FAQ mit der sichtbaren Seite. Besonders Fragen und Antworten sollten aus einem gemeinsamen Bestand erzeugt werden. Sonst kann nach einer redaktionellen Änderung eine längst entfernte Aussage im Markup weiterleben.

Kontrollieren Sie außerdem Links und Bildadressen. Ein korrekt geschriebenes Feld mit einem nicht erreichbaren Ziel ist für die praktische Veröffentlichung unzureichend. Bei Datumswerten prüfen Sie die tatsächliche Bedeutung: Eine automatische tägliche Neusetzung ist kein Nachweis einer täglich fachlich überarbeiteten Seite. Der veröffentlichte Datensatz muss den realen Stand nachvollziehbar beschreiben.

Fehler nach Ursache statt nur nach Meldung sortieren

Die Einordnung grenzt Zuständigkeiten ein, ohne eine Ursache voreilig zu behaupten. Bestätigen Sie den tatsächlichen Auslöser im jeweiligen System. Bei einem Templatefehler untersuchen Sie zusätzlich andere Seiten desselben Typs, damit nicht nur das zuerst gemeldete Beispiel repariert wird.

Fiktives Beispiel: ein grüner Test mit falschen Fragen

Ein Ratgeber wurde fachlich überarbeitet. Auf der Seite stehen sechs neue Kundenfragen, im gesondert gepflegten strukturierten Block aber noch zwei alte Antworten. Die Syntaxprüfung meldet keinen grundlegenden Schreibfehler. Erst der direkte Inhaltsvergleich zeigt die Abweichung.

Das Team führt die beiden Bestände zusammen und erzeugt anschließend beide Darstellungen aus derselben Quelle. Es testet den Code und die öffentliche Seite erneut. Danach wird eine zweite Artikelseite desselben Templates kontrolliert. Das Beispiel zeigt, warum ein bestandener technischer Test allein keine vollständige Qualitätsfreigabe ist. Eine konkrete Suchdarstellung oder zusätzliche Reichweite wird daraus nicht abgeleitet.

Mehrere ausgebende Systeme gezielt untersuchen

Wenn nach einer Korrektur weiterhin widersprüchliche Angaben erscheinen, erfassen Sie alle beteiligten Ausgabestellen. Ein Template und eine zusätzliche Erweiterung können dieselbe Eigenschaft unabhängig voneinander erzeugen. Vergleichen Sie die tatsächlich ausgelieferten Blöcke mit ihren jeweiligen Datenquellen. Korrigieren Sie nicht nur einen sichtbaren Wert im Testausschnitt. Legen Sie fest, welche Ausgabe künftig verantwortlich ist und wie die andere angepasst wird. Nach dieser Änderung werden die öffentliche Seite und ein weiterer typischer Vertreter desselben Seitentyps erneut geprüft. So wird ein systematischer Fehler nicht nur an einer einzelnen URL verdeckt.

Eine nachvollziehbare Freigabe dokumentieren

Halten Sie nach der Korrektur fest, welche öffentlichen Beispiele geprüft wurden und welche Grenzen bleiben. Ein vollständiger Testdatensatz enthält den betroffenen Seitentyp, relevante Werkzeugmeldungen, das fachliche Vergleichsergebnis und den Zeitpunkt. Das macht spätere Unterschiede bei erneuter Ausgabe verständlicher.

Planen Sie Wiederholungen bei Inhalts- oder Templateänderungen ein. Ein früherer erfolgreicher Test gilt nicht automatisch für jede neue Variante. Beobachten Sie zusätzliche verfügbare Meldungen in der Search Console, ohne sie mit einer garantierten Indexierung zu verwechseln. Ziel ist eine wahre, konsistente und technisch lesbare Beschreibung. Die Qualität der eigentlichen Antwort und ihre Eignung für die Suchfrage bleiben eigenständige Aufgaben.

Häufige Fragen.