Wie lassen sich Fehler in strukturierten Daten mit dem Google Schema Markup Validator beheben?

Fehlermeldung zuerst prüfen, nicht sofort den Code ändern

　　Bei der technischen Bewertung von Websites ist die häufigste Falle bei der Prüfung strukturierter Daten mit dem google schema markup validator nicht, dass man die Fehlermeldung nicht versteht, sondern dass man beim Anblick roter Hinweise sofort Felder ändert und dadurch alles noch unübersichtlicher macht. Effektiver ist es, zunächst festzustellen, zu welcher Kategorie die Fehlermeldung gehört: Syntaxfehler, Typfehler, fehlendes Feld, ungültiger Feldwert oder eine Abweichung zwischen Seiteninhalt und Markup. Die ersten beiden Kategorien können normalerweise zu einem Parsing-Fehler führen. Die späteren Kategorien lassen sich häufig noch parsen, beeinträchtigen jedoch das Verständnis der Daten durch Suchmaschinen und können im Ernstfall dazu führen, dass Rich Results nicht mehr funktionieren.

　　Wenn Sie für die technische Bewertung einer Website und nicht für die tägliche Pflege von Inhalten zuständig sind, sollten Sie sich auf drei Punkte konzentrieren: Blockiert der Fehler das Parsing, beeinflusst er die Darstellung der Zielseite in den Suchergebnissen oder handelt es sich um ein Problem auf Template-Ebene? Diese drei Punkte bestimmen die Priorität der Fehlerbehebung.

google schema markup validator meldet einen Fehler – wo sollte man zuerst suchen?

　　Prüfen Sie zunächst, wie die strukturierten Daten in die Seite eingebunden werden. Viele Websites schreiben JSON-LD nicht von Hand, sondern lassen es durch ein CMS, ein Theme-Template, ein Plugin, ein Tag-Management-Tool oder eine Frontend-Komponente dynamisch erzeugen. Wenn die Quelle nicht geklärt ist, lässt sich der Fehler später nur schwer lokalisieren.

　　Bei der praktischen Prüfung gehe ich normalerweise in dieser Reihenfolge vor:

1. Wie viele Abschnitte mit strukturierten Daten gibt es tatsächlich im Quellcode der Seite und welchen Typ haben sie jeweils?
2. Auf welchen Abschnitt verweist die Fehlermeldung – auf JSON-LD, Microdata oder RDFa?
3. Wer erzeugt diese Daten – das Template, ein Plugin oder eine API-Antwort?
4. Tritt derselbe Fehler auch auf vergleichbaren Seiten auf? So lässt sich feststellen, ob es sich um ein Problem einer einzelnen Seite oder um ein Massenproblem handelt.
5. Unterstützt der sichtbare Seiteninhalt diese Markierungen, damit nicht „etwas markiert wird, das auf der Seite nicht angezeigt wird“?

　　Dieser Schritt wirkt zwar grundlegend, ist aber entscheidend. Besonders wenn mehrsprachige Websites, Produktseiten und Artikelwebsites dasselbe Template verwenden, kann derselbe Code bei unterschiedlichen Seitentypen völlig verschiedene Fehler erzeugen.

Welche Fehlermeldungen treten am häufigsten auf und wie werden sie priorisiert?

　　Nicht alle Fehlermeldungen sind gleich schwerwiegend. Bei der technischen Bewertung empfiehlt es sich, sie getrennt zu betrachten.

　　Viele Teams ignorieren „Warnungen“. Wenn sich eine Warnung jedoch auf ein Rich-Results-Feld bezieht, von dem Sie abhängig sind, etwa auf den Produktpreis, den Lagerbestand oder das Veröffentlichungsdatum eines Artikels, kann sie zwar nicht unbedingt zu einem Parsing-Fehler führen, aber dennoch die Darstellung in den Suchergebnissen direkt beeinflussen.

Die Seite lässt sich öffnen – warum meldet der Validator trotzdem einen Syntaxfehler?

　　Weil Browser viele Frontend-Probleme tolerieren, Parser für strukturierte Daten dies jedoch nicht tun. Besonders häufig treten drei Situationen auf.

• Beim Zusammenfügen von JSON durch das Backend-Template ist ein Feld leer, sodass am Ende ein zusätzliches Komma entsteht.
• Ein Feldwert enthält nicht maskierte doppelte Anführungszeichen, wodurch der gesamte JSON-LD-Abschnitt unterbrochen wird.
• Strukturierte Daten werden dynamisch per Script eingefügt, die Ausgabe ist jedoch ein Objekttext und kein gültiges JSON.

　　Solche Probleme sollten Sie nicht nur mit bloßem Auge auf der Seite prüfen. Sehen Sie sich direkt den Inhalt von application/ld+json im Quellcode an. Kopieren Sie bei Bedarf einen einzelnen JSON-Abschnitt in das Prüfwerkzeug und testen Sie ihn separat. So lässt sich die Ursache meist schneller finden als bei einer Prüfung der gesamten Seite.

Was ist der grundlegende Unterschied zwischen „fehlendem Feld“ und „ungültigem Feld“?

　　Der Unterschied ist erheblich. Ein fehlendes Feld bedeutet, dass die Informationen im Markup unvollständig sind. Ein ungültiges Feld bedeutet, dass ein Wert eingetragen wurde, aber nicht in einer erkannten Form. Ersteres tritt häufig auf, wenn das Template nicht alle Geschäftsdaten ausgibt. Letzteres ist meist auf ein falsches Format, einen ungültigen Enumerationswert oder einen falschen Datentyp zurückzuführen.

　　Ein häufiges Beispiel: Auf einer Produktseite ist ein Preis vorhanden, im Schema wird der Preis jedoch als Text wie „USD 199“ eingetragen, der Währung und Zahl miteinander kombiniert. Der Validator kann dann einen ungültigen Wert melden. Ebenso kann ein Datum in einem nicht standardkonformen Format für den Nutzer verständlich sein, vom Parser aber möglicherweise nicht erkannt werden.

　　Fügen Sie bei der Fehlerbehebung daher nicht nur den Feldnamen hinzu, sondern prüfen Sie auch, ob das Format des Feldwerts den Anforderungen des jeweiligen Typs entspricht. In der Phase der technischen Bewertung lässt sich daran unmittelbar erkennen, ob das Design der Datenquelle规范 ist.

Welche Folgen hat die Wahl eines falschen Typs für strukturierte Daten?

　　Ein falscher Typ ist problematischer als ein fehlendes Feld. Denn es geht nicht nur darum, dass eine Angabe fehlt, sondern dass die gesamte semantische Bedeutung in die falsche Richtung weist. Beispielsweise kann es problematisch sein, auf einer Serviceseite eines Unternehmens ein Product zu verwenden oder eine gewöhnliche Nachrichtenseite mit FAQ oder Review zu kennzeichnen. Wenn die Seite diese Inhalte nicht tatsächlich unterstützt, kann der Validator zwar teilweise erfolgreich sein, die Suchmaschine wird die Seite später jedoch nicht wie erwartet verstehen.

　　Die Vorgehensweise ist sehr praktisch: Prüfen Sie zunächst, welchem Hauptzweck die Seite dient, und wählen Sie anschließend den Typ, der am besten zum Schwerpunkt der Seite passt. Fügen Sie nicht alle möglichen Schema-Typen hinzu, nur um mehr Sichtbarkeit in den Suchergebnissen zu erreichen. Für technische Bewerter ist die Übereinstimmung von Typ und Seitenintention ein wichtigerer Maßstab als die bloße Frage, ob Markup vorhanden ist.

Sind mehrere Schema-Abschnitte auf derselben Seite normal oder widersprüchlich?

　　Das ist normal, vorausgesetzt, sie beschreiben unterschiedliche Entitäten derselben Seite oder die Beziehungen zwischen den Entitäten sind eindeutig. Beispielsweise ist es bei einer Artikelseite in der Regel unproblematisch, wenn sie gleichzeitig Article, BreadcrumbList und Organization enthält. Problematisch sind Duplikate und Widersprüche.

　　Häufige Konflikte sind:

• Auf derselben Produktseite geben ein Plugin und ein Template jeweils einen Product-Abschnitt aus.
• Name, Preis oder URL unterscheiden sich in den beiden Datenabschnitten.
• Der Breadcrumb-Pfad stimmt nicht mit der tatsächlichen Navigation der Seite überein.

　　Auch wenn der Validator nicht alle diese Punkte rot markiert, sollten Sie sie beheben. Für Suchmaschinen erhöhen doppelte Entitäten den Interpretationsaufwand. Im schlimmsten Fall können sich wichtige Signale gegenseitig aufheben.

Warum werden in den Suchergebnissen keine Rich Results angezeigt, obwohl die Prüfung erfolgreich war?

　　Das ist ein häufiges Missverständnis im Zusammenhang mit dem google schema markup validator. Er beantwortet die Frage, ob die Daten korrekt geparst werden können, nicht die Frage, ob sie garantiert in den Suchergebnissen angezeigt werden. Eine erfolgreiche Prüfung bedeutet lediglich, dass Ihre strukturierten Daten grundsätzlich gültig sind.

　　Wenn keine Rich Results erscheinen, sollten Sie normalerweise noch einige weitere Punkte prüfen:

1. Wurde die Seite bereits gecrawlt und indexiert?
2. Erfüllt der Seiteninhalt selbst die Voraussetzungen für die entsprechende Darstellung?
3. Stimmen die strukturierten Daten mit den sichtbaren Informationen auf der Seite überein?
4. Gehört der Zieltyp zu den Darstellungsformen, die von der Suchmaschine derzeit unterstützt werden?

　　Mit anderen Worten: Der Validator ist die erste Prüfung, nicht das endgültige Instrument zur Beurteilung der Darstellung. Technische Mitarbeiter sollten bei der Bewertung „korrektes Parsing“ und „erzielte Darstellung“ getrennt berichten.

Wie erkennt man einen Fehler auf Template-Ebene und warum sollte er gegenüber einem Fehler auf einer einzelnen Seite priorisiert werden?

　　Prüfen Sie, ob der Fehler regelmäßig bei URLs desselben Typs auftritt. Wenn beispielsweise auf allen Produktdetailseiten das Feld brand fehlt oder das Veröffentlichungsdatum auf allen Blogdetailseiten im falschen Format ausgegeben wird, handelt es sich um ein typisches Problem auf Template-Ebene. Das Risiko liegt nicht bei einer einzelnen Seite, sondern darin, dass sich der Fehler mit jeder neuen Seite weiter ausbreitet.

　　Die Vorgehensweise ist einfach: Prüfen Sie stichprobenartig Seiten aus demselben Verzeichnis und mit demselben Template in unterschiedlichen Sprachversionen. Wenn das Fehlermuster gleich ist, sollte die Korrektur vorrangig auf Template- oder Daten-API-Ebene erfolgen. Für Teams, die ein intelligentes Website-Baukastensystem oder ein einheitliches Backend für mehrere Websites verwenden, kann eine Änderung an einer Stelle häufig eine ganze Gruppe von Seiten abdecken. Der Nutzen der Fehlerbehebung ist dann am höchsten.

Auf welche Felder sollte man bei der Bewertung besonders achten?

　　Sie müssen nicht alle Attribute einzeln im Detail prüfen. Konzentrieren Sie sich zunächst auf die Felder, die für den Wert der jeweiligen Seite am relevantesten sind. Je nach Seitentyp sind unterschiedliche Angaben wichtig:

• Produktseite: Name, Bild, Preis, Währung, Lagerbestand und URL.
• Artikelseite: Titel, Veröffentlichungsdatum, Aktualisierungsdatum, Autor und Hauptbild.
• Unternehmensseite: Organisationsname, Website, Logo und Kontaktdaten.
• Breadcrumbs: Sind die hierarchischen Namen und Ziel-URLs tatsächlich erreichbar?

　　Wenn diese Kernfelder selbst nicht stabil sind, bringt es wenig, anschließend noch weitere Long-Tail-Attribute zu ergänzen. Sorgen Sie zuerst für ein korrektes Grundgerüst und erweitern Sie erst danach.

Wie lässt sich nach der Behebung bestätigen, dass das Problem tatsächlich gelöst ist?

　　Verlassen Sie sich nicht nur darauf, dass ein lokaler Test erfolgreich ist. Sicherer ist eine Prüfung in drei Schritten: auf Code-, Seiten- und Stichprobenebene.

1. Code-Ebene: Stellen Sie sicher, dass die Erzeugungslogik im richtigen Template oder in der richtigen Schnittstelle geändert wurde und nicht nur vorübergehend auf einer einzelnen Seite.
2. Seitenebene: Rufen Sie den Quellcode der Online-Seite erneut ab und prüfen Sie, ob sich die ausgegebenen Inhalte geändert haben.
3. Stichprobenebene: Prüfen Sie stichprobenartig vergleichbare Seiten, um sicherzustellen, dass nicht nur eine einzelne URL zufällig korrekt funktioniert.

　　Wenn Sie die technische Abnahme eines Website- oder internationalen Marketingprojekts durchführen, darf dieser Schritt nicht ausgelassen werden. Fehler bei strukturierten Daten sind häufig nicht deshalb problematisch, weil sie sich nicht beheben lassen, sondern weil zwar diese Seite korrigiert wurde, auf anderen Seiten aber weiterhin Fehlermeldungen auftreten.

Nach welchem Maßstab lässt sich abschließend beurteilen, ob strukturierte Daten den Anforderungen entsprechen?

　　Ein ausreichender Maßstab lautet: Die Daten lassen sich stabil parsen, der Typ stimmt mit der Seite überein, die Kernfelder sind vollständig, die Feldwerte haben das richtige Format und stimmen mit den sichtbaren Inhalten der Seite überein. Wenn diese fünf Punkte erfüllt sind, ist die Prüfung der Fehlermeldungen im google schema markup validator im Wesentlichen korrekt durchgeführt.

　　Bei der technischen Bewertung muss nicht jedes empfohlene Attribut ergänzt werden. Beseitigen Sie zunächst die entscheidenden Probleme, die Parsing, Verständnis und Darstellung beeinflussen, und prüfen Sie anschließend, ob eine weitere Erweiterung der Schema-Typen erforderlich ist. Das entspricht eher dem Ablauf realer Projekte und erleichtert es, die Korrekturen in Templates und Prozesse zu übertragen, statt bei einer einmaligen manuellen Fehlersuche stehen zu bleiben.