Was tun, wenn das Google Schema Testing Tool keine Daten erkennt?

Auf der Seite wurde bereits JSON-LD-Code eingefügt, doch beim Öffnen des google schema testing tool wird „keine strukturierten Daten erkannt“ angezeigt. Schreiben Sie nicht sofort die gesamte Auszeichnung neu. Dieses Ergebnis bedeutet in der Regel nicht zwangsläufig, dass das Schema ungültig ist. Häufiger stimmen die vom Testtool abgerufenen Seiteninhalte nicht mit den im Browser sichtbaren Inhalten überein, oder es gibt Probleme mit der Platzierung der Auszeichnung, der Codesyntax oder dem Zugriffsstatus der Seite.

In der Praxis führen besonders häufig folgende Situationen zu Fehleinschätzungen: Entwickler sehen in der Testumgebung, dass der Code korrekt funktioniert, nach der Veröffentlichung kann das Tool ihn jedoch nicht erfassen; oder im Website-Backend wurden bereits Felder für Produkte, Breadcrumbs und Artikel gespeichert, doch die Frontend-Seite gibt tatsächlich keine strukturierten Daten aus. Prüfen Sie zunächst, ob die vom Tool abgerufene HTML-Ausgabe die Auszeichnung enthält, dann, ob die Auszeichnung analysierbar ist, und erst danach, ob Typen und Eigenschaften den Anforderungen entsprechen.

Zunächst unterscheiden: Nicht erkannt oder erkannt, aber nicht für Rich Results geeignet

„Keine Daten erkannt“ und „Daten erkannt, aber mit Warnungen“ sind zwei unterschiedliche Probleme. Ersteres bedeutet, dass das Tool auf der aktuellen Seite keine erkennbaren Microdata, RDFa oder JSON-LD analysieren konnte; Letzteres bedeutet, dass die Auszeichnung vorhanden ist, aber bestimmte empfohlene Felder fehlen, was die grundlegende Erkennung nicht zwingend beeinträchtigt.

Das ursprüngliche Structured Data Testing Tool von Google wird nicht mehr gepflegt. Verwenden Sie bei der Fehleranalyse je nach Zweck das Rich-Results-Testtool, um zu prüfen, ob die Seite die von Google unterstützten Voraussetzungen für Rich-Results-Darstellungen erfüllt, oder den Schema Markup Validator, um Schema.org-Syntax und -Hierarchie zu überprüfen. Nur weil ein Tool keine Ergebnisse anzeigt, sollten Sie nicht direkt davon ausgehen, dass sämtliche strukturierten Daten der Seite unwirksam sind. Verschiedene Tools unterscheiden sich in ihrer Unterstützung von Typen, der JavaScript-Renderung und den Validierungsregeln.

Erster Schritt: Sicherstellen, dass die endgültig erreichbare Seite übermittelt wird

Öffnen Sie zunächst die zu testende URL in einem Inkognito-Fenster und vergewissern Sie sich, dass sie direkt erreichbar ist, eine normale Seite zurückgibt und weder Anmeldung, Captcha, regionale Einschränkungen noch spezielle Cookies erfordert. Testtools können blockierte Inhalte, fehlerhafte Weiterleitungen oder Inhalte mit eingeschränktem Zugriff nicht lesen.

• Prüfen Sie, ob die URL automatisch von http auf https oder von non-www auf www weiterleitet; getestet werden sollte die endgültige Zieladresse.
• Stellen Sie sicher, dass es sich nicht um einen Entwurf, einen Vorschau-Link, eine Backend-Bearbeitungsseite oder eine nur im Intranet sichtbare Testadresse handelt.
• Prüfen Sie, ob mehrere Weiterleitungen stattfinden. Ist die Weiterleitungskette zu lang oder führt sie zu einer Sprachauswahlseite oder Fehlerseite, erkennt das Tool nicht die gewünschte Inhaltsseite.
• Prüfen Sie, ob der Server für Crawler unterschiedliche Inhalte zurückgibt, etwa durch Sicherheitsvorkehrungen, Ratenbegrenzungen, 403, 503 oder leere Seiten.

Manche Websites liefern je nach Sprache, IP oder User-Agent des Besuchers unterschiedliche Versionen aus. Ein normaler Browserzugriff bedeutet nicht, dass das Abruf-Tool korrektes HTML erhält. Prüfen Sie in diesem Fall anhand von Serverprotokollen, CDN-Schutzregeln oder Abrufresultaten der Seite, ob die Anfrage blockiert wurde.

Zweiter Schritt: Strukturierte Daten im Seitenquelltext suchen

Suchen Sie nicht nur über „Element untersuchen“ im Browser. Die Entwicklertools zeigen das DOM nach der Ausführung von JavaScript an, während das Testtool Skripte möglicherweise nicht auf dieselbe Weise ausführt. Nutzen Sie „Seitenquelltext anzeigen“ und suchen Sie nach application/ld+json, schema.org, itemtype oder itemscope.

Bei JSON-LD werden Inhalte üblicherweise innerhalb des Tags <script type="application/ld+json"> platziert. Fehlt dieser Abschnitt im Quelltext und erscheint er nur im dynamischen DOM, liegt das Problem meist an einer asynchronen Einbindung im Frontend. Insbesondere bei Single-Page-Anwendungen, Filterseiten und Pop-up-Produktdetailseiten können strukturierte Daten erst nach Rückgabe der Schnittstelle erzeugt werden. Unterschiedliche Abrufzeitpunkte können dann dazu führen, dass das google schema testing tool sie nicht erkennt.

Zuverlässiger ist es, JSON-LD für zentrale Seiten zusammen mit dem initialen HTML auszugeben oder eine verlässliche serverseitige Rendering- bzw. Pre-Rendering-Lösung einzusetzen. Die Hauptinformationen von Produktdetailseiten, Artikeldetailseiten und Kategorieseiten sollten bereits in der initialen Antwort lesbar sein und nicht vollständig erst nach Benutzeraktionen geladen werden.

Dritter Schritt: JSON-LD-Syntax prüfen, nicht nur Feldinhalte

Beim Kopieren von Code können leicht typografische Anführungszeichen, nachgestellte Kommas, nicht maskierte doppelte Anführungszeichen oder unvollständige Klammern eingefügt werden. Sobald die JSON-Analyse fehlschlägt, ignoriert das Tool in der Regel den gesamten Datenabschnitt. Dass der Code wie Schema aussieht, bedeutet nicht, dass es sich um gültiges JSON handelt.

Prüfen Sie außerdem, ob @context auf https://schema.org gesetzt ist und @type korrekt geschrieben wurde. Eigenschaftswerte sollten mit den sichtbaren Seiteninhalten übereinstimmen. So dürfen Produktpreis, Lagerbestand, Bewertung, Veröffentlichungsdatum und ähnliche Angaben nicht dauerhaft veraltet sein oder Informationen enthalten, die auf der Seite nicht vorhanden sind. Dass ein Tool die Daten analysieren kann, bedeutet nicht, dass die Suchmaschine diese Informationen für die Darstellung übernimmt.

Probleme durch Templates, Plugins und Cache sind schwerer zu erkennen

Bei der Verwendung eines Website-Baukastens oder CMS werden strukturierte Daten nach der Aktivierung von „Strukturierte Daten aktivieren“ im Backend oft trotzdem nicht erkannt. Häufig liegt das nicht an einem falsch gewählten Schema-Typ, sondern daran, dass das Template die entsprechende Komponente nicht aufruft. Beispielsweise gibt ein Artikel-Template Titel und Text aus, lässt jedoch das Artikel-Schema-Modul aus; Produktdaten werden zwar im Shopsystem gepflegt, aber die aktuelle Detailseite verwendet ein benutzerdefiniertes Template, in das die betreffenden Felder nicht übernommen wurden.

Ein weiteres häufiges Problem ist der Cache. Nach einer Seitenaktualisierung hat sich die Backend-Konfiguration bereits geändert, doch CDN-, Seiten- oder Objekt-Cache liefern weiterhin die alte HTML-Version aus. Die Prüfungsreihenfolge sollte lauten: Einstellungen speichern und Seite veröffentlichen, Website-Cache und CDN-Cache leeren, den Quelltext über die endgültige öffentliche URL prüfen und anschließend den Test erneut starten. Wenn neuer Code nur auf der Backend-Vorschauseite sichtbar ist, beweist das nicht, dass die Online-Seite aktualisiert wurde.

Keine widersprüchlichen Daten mehrfach auf derselben Seite ausgeben

Manche Websites aktivieren gleichzeitig SEO-Markup des Themes, Markup eines Shop-Plugins und ein SEO-Plugin eines Drittanbieters. Dadurch erscheinen auf einer Produktseite zwei Product- und zwei Offer-Auszeichnungen, deren Preise oder Lagerbestände sogar voneinander abweichen. Solche Seiten zeigen nicht unbedingt „keine Daten erkannt“ an, erschweren jedoch die spätere Diagnose und können die Glaubwürdigkeit der Auszeichnung verringern.

Es wird empfohlen, je nach Seitenfunktion die primäre Entität beizubehalten: Auf Artikeldetailseiten sollte Article oder BlogPosting im Mittelpunkt stehen, auf Produktdetailseiten Product; im Navigationsbereich kann BreadcrumbList ergänzt werden. Entfernen oder deaktivieren Sie zunächst doppelte Quellen und testen Sie erneut. Auch bei websiteweiten Entitäten wie Organization und WebSite sollten Name, Website-Adresse, Logo und weitere Informationen einheitlich bleiben; verschiedene Plugins sollten nicht jeweils unterschiedliche Versionen erzeugen.

Validierungsreihenfolge nach der Fehlerbehebung

1. Öffnen Sie den Quelltext der öffentlichen Seite und bestätigen Sie, dass die strukturierten Daten tatsächlich ausgegeben werden.
2. Validieren Sie den JSON-LD-Codeausschnitt separat, um Fehler bei Kommas, Anführungszeichen, Klammern und der Kodierung auszuschließen.
3. Bestätigen Sie mit einem Schema-Validierungstool, dass Entitätstypen, Eigenschaftshierarchien und Referenzbeziehungen analysierbar sind.
4. Prüfen Sie anschließend mit dem Rich-Results-Testtool die von Google unterstützten konkreten Darstellungsarten und fehlenden Felder.
5. Testen Sie die URL nach dem Leeren des Caches erneut; wenn die Seite bereits indexiert ist, können Sie in der Search Console eine erneute Indexierung anfordern.

Abschließend sollte eine wichtige Grenze beachtet werden: Dass strukturierte Daten die Validierung bestehen, bedeutet lediglich, dass Maschinen bestimmte Seiteninformationen verstehen können, garantiert jedoch keine Rich-Results-Darstellung. Umgekehrt bedeutet es nicht zwingend, dass eine Auszeichnung wertlos ist, wenn ein bestimmter Schema-Typ nicht im Rich-Results-Tool angezeigt wird. Bei dem Problem „keine Daten erkannt“ ist es in der Regel wirksamer, zunächst Erreichbarkeit der Seite, initiale HTML-Ausgabe, JSON-Syntax und Cache-Version zu prüfen, als wiederholt weitere Felder hinzuzufügen.