Rich Results Test und Google Search Console: Wie lassen sich Probleme mit strukturierten Daten beheben?

Rich Results Test und Google Search Console: Wie lassen sich Probleme mit strukturierten Daten untersuchen?

Wenn strukturierte Daten auf Produkt-, Artikel- oder Serviceseiten Probleme aufweisen, ändern viele Teams direkt den Schema-Code und klicken wiederholt auf „Fehlerbehebung validieren“. Das Problem ist, dass Fehler bei strukturierten Daten nicht zwangsläufig durch die Markup-Syntax selbst verursacht werden: Sie können durch das Rendern der Seite, die Vorlagenvererbung, die Crawling-Version, den Indexierungsstatus oder sogar durch Inkonsistenzen zwischen Inhalt und Markup entstehen. Um die Ursache präzise zu ermitteln, sind rich results test - google search console keine alternative Werkzeugkombination, sondern zwei Beobachtungsmechanismen: Ersteres zeigt, „was Google aktuell analysiert“, Letzteres zeigt, „was Google bereits auf Website-Ebene erkannt hat“.

Für technische Prüfer ist es am wichtigsten, nicht alle Hinweise auf null zu setzen, sondern zunächst drei Fragen zu beantworten: Beeinträchtigt das Problem die Berechtigung für Rich Results? Hat Google die aktuelle Version der Seite gecrawlt? Ist dieses Markup tatsächlich für diese Seite und den geschäftlichen Inhalt geeignet? Ist die Reihenfolge falsch, sind spätere Korrekturen oft nur wirkungslose Nacharbeit.

Zunächst unterscheiden: Testergebnisse, Search-Console-Berichte und die Darstellung in der Suche sind nicht dasselbe

Der Rich Results Test eignet sich zur Prüfung einer einzelnen URL oder eines Codeabschnitts. Er versucht, qualifizierte strukturierte Daten auf der Seite zu extrahieren, und unterteilt Probleme in Fehler, Warnungen und erkennbare Elemente. Besonders geeignet ist er für die Abnahme vor der Veröffentlichung, Stichproben nach Vorlagenüberarbeitungen sowie zur Beurteilung, ob JSON-LD korrekt durch JavaScript ausgegeben wird.

Die Rich-Results-Berichte der Google Search Console sind dagegen Signale auf Website-Ebene und spiegeln eine Gruppe von URLs wider, die Google bereits verarbeitet hat. Die Berichte sind zeitverzögert und können auch historische Probleme von gelöschten Seiten oder alten Vorlagen enthalten. Daher bedeutet ein weiterhin gemeldeter Fehler in der Search Console nicht zwangsläufig, dass der aktuelle Live-Code noch fehlerhaft ist. Umgekehrt bedeutet ein bestandener Rich Results Test nicht, dass die Search Console bereits erneut gecrawlt hat, und erst recht nicht, dass die Suchergebnisse zwingend im Rich-Results-Format angezeigt werden.

In der Praxis lässt sich dies so verstehen: Der Rich Results Test ist eine unmittelbare „Seitenuntersuchung“, die Search Console eine „Website-Krankengeschichte“ mit Zeitdimension. Wenn beide zu widersprüchlichen Ergebnissen kommen, prüfen Sie zuerst im URL-Prüftool den Crawling-Zeitpunkt, den Indexierungsstatus und die von Google abgerufene Seite. Entscheiden Sie dann, ob eine erneute Indexierung beantragt werden muss.

Die Ursache aus der Art des Problems abzuleiten, ist effektiver als Code Zeile für Zeile zu ändern

Probleme mit strukturierten Daten lassen sich in der Regel in vier Kategorien einteilen. Die erste Kategorie sind Parsing-Fehler, etwa wenn in JSON Anführungszeichen fehlen, ein Komma falsch platziert ist, ein Skript durch die Vorlage maskiert wird oder derselbe Codeabschnitt zweimal zusammengesetzt wird. Solche Probleme werden in Testtools oft direkt als nicht analysierbar angezeigt. Prüfen Sie vorrangig den Seitenquellcode und das endgültig gerenderte DOM, statt nur die Konfiguration im CMS-Editor zu betrachten.

Die zweite Kategorie sind fehlende Pflichtattribute. Beispielsweise fehlen im Produkt-Markup Preise, im Bewertungs-Markup erforderliche Felder oder auf Artikelseiten erkennbare Informationen zum Hauptbild. Hier wird häufig ein Fehler gemacht: Um Hinweise zu beseitigen, werden auf jeder Seite feste Werte eingetragen. Für Google ist die Übereinstimmung zwischen sichtbarem Seiteninhalt und Markup wichtiger. Auf einer B2B-Anfrageseite ohne Preis sollte kein offer erfunden werden, nur um Product Rich Results zu nutzen; Seiten ohne echte Bewertungsquelle sollten ebenso kein aggregateRating enthalten.

Die dritte Kategorie ist eine unangemessene Verwendung von Typen. Fertigungsunternehmen kennzeichnen häufig alle Detailseiten als Product, doch manche Seiten sind ihrem Wesen nach Lösungsbeschreibungen, Erläuterungen zu Anlagenkapazitäten oder Branchenseiten und enthalten möglicherweise nicht die erforderlichen Informationen einer handelbaren Produktseite. Ebenso ist FAQPage nur dann sinnvoll, wenn die Fragen und Antworten tatsächlich angezeigt werden, für Nutzer lesbar sind und nicht wiederholt angehäuft werden. Das Ziel von Markup ist die Beschreibung einer Seite, nicht das Hinzufügen eines „Schalters für Sucheffekte“.

Die vierte Kategorie ist am schwersten zu erkennen: Der Code ist korrekt, aber Google hat nicht die Version erfasst, die Sie sehen. Häufige Ursachen sind asynchrones Frontend-Rendering, Sprachwechsel, regionale Weiterleitungen, überlagernde Cookie-Pop-ups, nicht aktualisierte CDN-Caches oder Server, die je nach User-Agent unterschiedliche Inhalte ausliefern. In diesem Fall kann die „abgerufene Webseite“ im Rich Results Test von dem abweichen, was lokal im Browser angezeigt wird. Besonders bei Websites mit SPA-Architektur kann Google nur eine leere Hülle erhalten, wenn strukturierte Daten von clientseitigen Schnittstellenantworten abhängen und die Schnittstelle langsam ist, Skripte Fehler aufweisen oder das Rendering ein Zeitlimit überschreitet.

Ein verlässlicherer Prüfpfad

Es wird empfohlen, nicht sofort nach einem Bericht in der Search Console massenhaft Änderungen vorzunehmen. Wählen Sie zunächst eine betroffene URL aus und gehen Sie in folgender Reihenfolge vor:

• Bestätigen Sie, dass die URL einen normalen Status 200 zurückgibt und nicht durch robots.txt, noindex, Anmeldebeschränkungen oder regionale Richtlinien blockiert wird;
• Testen Sie im Rich Results Test die Live-URL statt nur lokal kopierten Code und dokumentieren Sie die erkannten Typen, Felder und konkreten Fehler;
• Öffnen Sie den Seitenquellcode und die Entwicklertools des Browsers, um zu prüfen, ob JSON-LD im ursprünglichen HTML vorhanden ist oder erst durch nachfolgende Skripte eingefügt wird;
• Prüfen Sie mit der URL-Prüfung der Search Console den letzten Crawling-Zeitpunkt, die kanonische Seite, die Indexierungsfreigabe und den Seitenabruf;
• Gehen Sie zum sichtbaren Seiteninhalt zurück und gleichen Sie Name, Bilder, Preis, Bestand, Veröffentlichungsdatum, Autor und weitere Felder einzeln darauf ab, ob sie echt und konsistent sind;
• Testen Sie nach der Korrektur zuerst repräsentative URLs erneut und starten Sie anschließend in der Search Console die Validierung für das jeweilige Problem, damit das Ergebnis einer einzelnen Seite nicht fälschlich als Wiederherstellung der gesamten Website bewertet wird.

Hier gibt es ein praktisches Detail: Bei vorlagenbasierten Problemen sollten Seiten in verschiedenen Sprachen, auf unterschiedlichen Endgeräten und mit unterschiedlichen Inhaltszuständen stichprobenartig geprüft werden. Dass eine englische Produktseite besteht, bedeutet nicht, dass auch die deutsche Seite, Seiten ohne Bild oder nicht mehr verfügbare Seiten sicher sind. Mehrsprachige unabhängige Websites melden häufig fortlaufend Fehler nur in einer Sprache, weil Übersetzungsfelder leer sind oder die hreflang-Weiterleitungslogik das Rendering beeinflusst. Wenn canonical auf eine andere Sprachversion verweist, kann auch die Zuordnung des Berichts zu strukturierten Daten von den Erwartungen abweichen.

Ob Warnungen behoben werden müssen, hängt vom geschäftlichen Zweck der Seite ab

Nicht alle Warnungen müssen sofort in die Entwicklungsplanung aufgenommen werden. Bei industriellen B2B-Websites ohne Bewertungssystem sollten fehlende empfohlene Felder zu Bewertungen in der Regel nicht durch erfundene Daten ergänzt werden. Bei grenzüberschreitenden Online-Shops, die langfristig organischen Traffic aufbauen möchten, sollten dynamische Felder wie Preis, Versandkosten und Bestand hingegen in den Veröffentlichungsprozess einbezogen werden, da sie sich mit dem Produktstatus leicht verfälschen können. Zur Priorisierung können drei Dimensionen betrachtet werden: Ist diese URL bereits indexiert? Übernimmt die Seite eine zentrale Aufgabe für Traffic oder Conversion? Können die Felder stabil durch reale Geschäftssysteme bereitgestellt werden?

Hier müssen Website-Erstellung und Marketingservices zusammenwirken. Strukturierte Daten sind keine reine Frontend-Aufgabe: Wer Produktdaten pflegt, ob Werbe-Landingpages häufig ersetzt werden, ob übersetzte Inhalte synchronisiert werden und ob das Content-Team standardisierte Felder ausfüllen kann, entscheidet darüber, ob das Markup langfristig nutzbar bleibt. In der Praxis von Yiyingbao bei der Erstellung von Websites für Außenhandelsunternehmen, mehrsprachige Unternehmenswebsites und grenzüberschreitende Online-Shops ist es geeigneter, Schema-Felder in Vorlagen und Regeln zur Inhaltsveröffentlichung zu integrieren, statt erst nach großflächigen Problemen in der Search Console Seite für Seite nachzubessern.

Dieselbe Denkweise gilt auch für andere Big-Data-Geschäftsbereiche: Wenn Datenfelder keine einheitliche Definition haben, werden sowohl Backend-Berichte als auch Frontend-Darstellungen verfälscht. Zum Verständnis solcher Zusammenhänge in der Datenverwaltung kann auf die Diskussion in Studie zur Optimierung der Finanzanalyse von Straßeninstandhaltungsunternehmen aus der Perspektive von Big Data verwiesen werden, die sich mit Datenanalyse und Managementoptimierung befasst. Auf Website-Projekte übertragen bedeutet dies: Zuerst Datenquellen und Verantwortliche festlegen und dann entscheiden, welche Felder in das strukturierte Markup aufgenommen werden.

„Gültig“ nicht fälschlich als „zwingend Rich Results erhalten“ verstehen

Das Bestehen der Prüfung durch rich results test - google search console zeigt nur, dass die Seite die grundlegenden Voraussetzungen erfüllt, erkannt und berücksichtigt zu werden. Die endgültige Darstellung in den Suchergebnissen wird weiterhin von Google anhand der Suchanfrage, des Geräts, der Seitenqualität, der Inhaltsrelevanz und anderer Systemsignale bestimmt. Technische Teams sollten strukturierte Daten als Protokoll zur präzisen Übermittlung von Seiteninformationen betrachten, nicht als Zusage für Ranking oder Klickrate.

Wirklich sinnvoll ist der Aufbau eines nachvollziehbaren Prozesses: Tests vor der Veröffentlichung von Vorlagen, Stichproben nach Überarbeitungen nach Seitentyp, regelmäßige Beobachtung von Trends in der Search Console sowie die Dokumentation von Crawling-Zeitpunkt und Seitenversion bei Problemen. Wenn das nächste Mal ein roter Fehler erscheint, beginnt das Team dann nicht mit „Versuchen wir, den Code zu ändern“, sondern kann schnell beurteilen, ob es sich um ein Markup-, Crawling- oder noch nicht aktualisiertes Indexierungsproblem handelt.