Was sollte man bei einem Fehler der Google-Validierung strukturierter Daten zuerst prüfen?

Was sollte bei einem Fehlschlag der Google-Validierung strukturierter Daten zuerst geprüft werden? Prüfungsreihenfolge von Syntax bis Crawling

Ein Fehlschlag bei der Google-Validierung strukturierter Daten bedeutet weder zwingend, dass die Seite nicht indexiert werden kann, noch muss der gesamte Markup-Abschnitt vorschnell entfernt werden. Für technische Prüfer ist entscheidend, zunächst zwischen der Frage zu unterscheiden, ob strukturierte Daten der Schema.org-Syntax entsprechen, und der Frage, ob sie die speziellen Voraussetzungen von Google für Rich Results erfüllen. Erstere betrifft die korrekte Interpretierbarkeit des Codes, während Letztere zusätzlich Seiteninhalte, Pflichtattribute, Crawling-Status und die Eignung des Typs prüft. Wird die Prüfungsreihenfolge vertauscht, werden häufig wiederholt einzelne Attribute geändert, während übersehen wird, dass die Seite selbst nicht erreichbar ist oder das Markup nicht mit den sichtbaren Inhalten übereinstimmt.

Insbesondere bei mehrsprachigen Unternehmenswebsites, B2B-Produktkatalogen, grenzüberschreitenden Onlineshops und Anzeigen-Landingpages bestehen häufig gleichzeitig Templates, Plugins, Frontend-Rendering und regionale Versionen. JSON-LD für dasselbe Produkt kann jeweils durch das Theme-Template, ein SEO-Plugin und das Produktsystem ausgegeben werden. Das Validierungstool erkennt dann nicht einfach nur ein fehlendes Feld, sondern eine Kombination aus doppelten Entitäten, widersprüchlichen Preisen oder ungültigen Links.

Zunächst feststellen: In welchem Tool und auf welcher Ebene tritt der Fehler auf?

Der erste Schritt bei der Prüfung ist nicht die Änderung des Codes, sondern die vollständige Fehlermeldung zu sichern und den Prüfzugang zu bestätigen. Der Schema Markup Validator kann bei der Prüfung der Struktur allgemeiner Schema.org-Markups helfen; der Rich-Results-Test von Google konzentriert sich stärker auf die Unterstützungsvoraussetzungen bestimmter Ergebnistypen. Unterschiedliche Ergebnisse beider Tools sind normal: Ein Product-Markup kann bei der allgemeinen Validierung syntaktisch korrekt sein, aber wegen fehlender von Google geforderter Felder zu Preis, Verfügbarkeit oder Bewertungen nicht für Produkt-Rich-Results qualifiziert sein.

Auch zwischen „Fehlern“ und „Warnungen“ muss unterschieden werden. Fehler bedeuten in der Regel, dass eine Entität nicht wie erwartet interpretiert werden kann oder ein für diese Funktion erforderliches Feld fehlt; Warnungen weisen häufig darauf hin, dass ergänzende Informationen unzureichend sind. Auf Websites von B2B-Fertigungsunternehmen zeigen viele Seiten kundenspezifische Anlagen, Parameterbereiche oder Anfrageoptionen und keine öffentlich verfügbaren Transaktionspreise. In diesem Fall sollten Offer, price oder availability nicht erfunden werden, nur um Warnungen zu beseitigen. Liegt kein überprüfbares öffentliches Angebot vor, sollte bewertet werden, ob Product der geeignete Typ ist, oder es sollten nur Markups wie Organization, BreadcrumbList und WebPage beibehalten werden, die den tatsächlichen Seiteninhalten entsprechen.

Korrekte Syntax bedeutet nicht, dass der Typ richtig gewählt wurde

In der Praxis besteht die häufigste Fehleinschätzung darin, alle Detailseiten als Product zu kennzeichnen. Für standardisierte SKUs und öffentlich kaufbare Produkte in grenzüberschreitenden Onlineshops ist dies in der Regel sinnvoll; bei Industrieanlagen, ODM-Dienstleistungen, Engineering-Projekten oder Seiten mit Katalogen, die nur zum Download bereitstehen, kann der Kern der Seite jedoch die Vorstellung einer Lösung und nicht ein direkt abschließbares Produktangebot sein. Wenn der Inhalt nur „Bitte Preis anfragen“ lautet, aber ein fester Preis und Lagerbestand ausgegeben werden, entsteht nicht nur ein Validierungsrisiko, sondern auch eine Abweichung zwischen der Suchdarstellung und den Erwartungen der Nutzer.

Ebenso sollten Typen wie FAQPage, Review und AggregateRating nicht als Schalter zur Traffic-Generierung betrachtet werden. Fragen und Antworten müssen tatsächlich auf der Seite erscheinen; Bewertungen sollten über nachvollziehbare Quellen und eine angemessene Zuordnung verfügen; aggregierte Bewertungen dürfen nicht aus Marketingtexten erzeugt werden. Eine technische Umsetzung kann die Validierung bestehen, doch das bedeutet nicht, dass die Seite für die entsprechende Suchdarstellung geeignet ist. Google entscheidet eigenständig über die Anzeige von Rich Results; eine erfolgreiche Validierung ist keine Zusage für eine Darstellung.

Die Crawlability der Seite wird häufig übersehen, insbesondere bei dynamischen Frontend-Websites

Wenn JSON-LD nach dem Kopieren des Seitenquelltexts nicht auffindbar ist oder das Tool andere Inhalte erkennt als im Browser angezeigt werden, sollte die Erzeugungsmethode des Markups geprüft werden. Einige Websites sind darauf angewiesen, dass Client-seitiges JavaScript Daten nach dem Laden der Seite einfügt. Bei Skriptfehlern, Zeitüberschreitungen von Schnittstellen, nicht geladenen Inhalten vor der Cookie-Einwilligung oder eingeschränkten Rendering-Ressourcen kann die vom Crawler abgerufene Version unvollständig sein. Sicherer ist es, wichtige strukturierte Daten im initialen HTML oder in zuverlässigen serverseitig gerenderten Ergebnissen sichtbar zu machen und sich bei der Bewertung auf tatsächliche Crawling-Ergebnisse statt auf lokale Vorschauen zu stützen.

Eine weitere grundlegende Prüfung betrifft Statuscodes und kanonische Adressen. Gibt eine Seite 302, 404 oder Soft 404 zurück, ist noindex gesetzt oder verweist canonical auf eine andere URL, wird das Markup der aktuellen URL möglicherweise selbst dann nicht übernommen, wenn es perfekt ist. Bei mehrsprachigen Websites sollten außerdem für jede Seite Sprachversion, hreflang, canonical sowie die URLs, Bildadressen und Währungsinformationen in den strukturierten Daten aufeinander abgestimmt werden. Eine englische Seite sollte weder chinesische Produktbilder oder Preise der Hauptwebsite referenzieren, noch sollten mehrere Sprachseiten ein Offer gemeinsam verwenden, das nicht zur jeweiligen Version passt.

Bei der Prüfung doppelter Markups zunächst ansehen, „wer sie ausgibt“

Viele Validierungsprobleme entstehen durch überlagerte Systeme und nicht durch manuelle Fehler. Das Website-Theme gibt Organization und BreadcrumbList aus und ein SEO-Plugin ergänzt diese erneut; eine Shop-Anwendung generiert Product und ein vom Betriebsteam eingebetteter Codeblock erzeugt eine weitere Version. Die name- und url-Werte der beiden Entitäten können identisch sein, während Preis, Marke oder Bild voneinander abweichen. Tools führen manchmal mehrere Elemente separat auf, doch das eigentliche Problem ist, dass Suchmaschinen nicht beurteilen können, welche Version vertrauenswürdiger ist.

Es wird empfohlen, strukturierte Daten in den Veröffentlichungsprozess einzubinden: eindeutig festlegen, welches Modul den jeweiligen Seitentyp ausgibt, und eine Zuordnung zwischen Seitentypen und Schema-Typen erstellen; nach Überarbeitungen, Plugin-Installationen oder dem Wechsel von Sprach-Templates sollten Startseite, Kategorieseiten, Detailseiten, Artikelseiten und Landingpages stichprobenartig geprüft werden. Bei größeren Websites ist es besser, zuerst die Template-Quelle zu bereinigen, als einzelne Seiten zu reparieren, da sonst bei der nächsten Massenveröffentlichung dieselben Fehler erneut auftreten.

Validierung in die Zusammenarbeit zwischen Website und Marketing integrieren, nicht als einmalige Entwicklungsaufgabe behandeln

Strukturierte Daten verbinden Inhalte, Produktdaten, technische Architektur und Suchdarstellung. Wenn das Marketingteam eine Reihe neuer Landingpages hinzufügt, das Entwicklungsteam URL-Regeln anpasst oder das Produktteam Währungen beziehungsweise Bestandslogiken ändert, kann dies bestehende Markups beeinflussen. Für Außenhandelsunternehmen übernehmen internationale Websites häufig zugleich die Aufgaben der organischen Suche, Anzeigenweiterleitung, Social-Media-Traffic-Generierung und Anfragekonvertierung; die technische Validierung sollte nicht von diesen tatsächlichen Seitenpfaden getrennt betrachtet werden.

Yiyingbao Information Technology (Beijing) Co., Ltd. bietet seit 2013 Dienstleistungen rund um intelligente Website-Erstellung, SEO-Optimierung und internationales digitales Marketing an. Im systematischen Ansatz für mehrsprachige Unternehmenswebsites, B2B-Marketing-Websites und grenzüberschreitende Onlineshops sollten strukturierte Daten als Teil der Datenverwaltung einer Website betrachtet werden: Ob Seiteninhalte authentisch sind, Templates stabil funktionieren und Sprach- sowie Regionsversionen konsistent sind, sollte in der Regel vorrangiger geprüft werden als das bloße Ergänzen einiger Felder.

Bei einem Fehlschlag der Google-Validierung strukturierter Daten kann daher in der Reihenfolge „Fehlerquelle – Syntax – Typ und Attribute – Crawling und Rendering – Inhaltskonsistenz – Template-Duplikate“ vorgegangen werden. Testen Sie nach der Behebung die entsprechende URL erneut und beachten Sie die anschließenden Rückmeldungen der Suchplattform. Konzentriert sich das Problem auf Mehrsprachigkeit, Shops oder dynamische Templates, ist es in der Regel zuverlässiger, zuerst Datenquellen und Seitenregeln zu klären, statt Seiten einzeln manuell zu korrigieren.