Nicht parsbare strukturierte Daten: Ursachen und Lösung

Was bedeuten nicht parsbare strukturierte Daten und was tun Sie zuerst?

Nicht parsbare strukturierte Daten bedeuten, dass Google auf Ihrer Seite einen Markup Block gefunden hat, ihn aber wegen eines schwerwiegenden Syntaxfehlers nicht lesen kann. Der Fehler ist so grundlegend, dass Google nicht einmal den Typ erkennt. In der englischen Oberfläche heißt der Bericht "Unparsable structured data".

Bleiben Sie ruhig, denn die Ursache ist meist winzig, zum Beispiel ein einzelnes Komma oder ein Anführungszeichen. Außerdem senkt der Fehler Ihr Ranking nicht direkt. Der eigentliche Verlust: Die betroffenen Seiten können sich nicht mehr für Rich Results qualifizieren. Am ersten Tag gehen Sie so vor:

1. Zunächst öffnen Sie den Bericht in der Search Console und klicken Sie auf die Fehlerzeile, um die betroffenen Seiten zu sehen.
2. Dann wählen Sie eine Beispielseite und geben Sie ihre Adresse in den Rich Results Test von Google ein.
3. Danach lesen Sie Fehlermeldung und Zeilenhinweis, um die defekte Stelle zu finden.
4. Außerdem testen Sie zwei bis drei weitere Seiten, denn so erkennen Sie, ob nur eine Seite oder ein ganzes Template betroffen ist.
5. Schließlich veröffentlichen Sie die Korrektur und starten Sie danach die Validierung.

Wir erklären jeden Schritt weiter unten. Falls Ihnen die Grundlagen fehlen, lesen Sie zunächst unseren Beitrag Was ist Schema Markup. Dieser Artikel behandelt ausschließlich die Reparatur defekter Auszeichnungen.

Wie unterscheidet sich dieser Bericht von anderen Berichten?

In Rich Result Berichten zu Produkten, Rezepten oder Veranstaltungen erkennt Google den Typ und nennt fehlende Felder. In diesem Bericht kann Google den Typ gar nicht bestimmen. Laut Googles Hilfeseite listet der Bericht strukturierte Daten auf, die wegen eines schwerwiegenden Syntaxfehlers nicht geparst werden konnten.

Ein weiterer Unterschied: Der Bericht erscheint nur, wenn es ein Problem gibt. Googles Dokumentation zufolge taucht er in Ihrer Property nur auf, wenn Google nicht parsbare Daten gefunden hat. Sehen Sie ihn nie, ist das also ein gutes Zeichen.

Zudem zählt jeder Eintrag als kritischer Fehler. Es gibt weder Warnungen noch gültige Elemente. Google sortiert die Fehler nach Schweregrad, unter anderem nach der Zahl der betroffenen Seiten. Daher beginnen Sie am besten bei der obersten Zeile.

Ein fehlendes Pflichtfeld gehört dagegen nicht hierher. Das verfolgen Sie im passenden Rich Result Bericht. Dieser Artikel bleibt auf der Ebene der Syntax.

Welche Fehlertypen sehen Sie im Bericht?

Googles Hilfeseite führt viele verschiedene Parsing Fehler auf. Wir übersetzen Oberflächentexte nicht wörtlich, sondern nennen die englischen Namen in Anführungszeichen. In Ihrem Panel sehen Sie eine ähnliche Formulierung.

• "Invalid JSON document": Der Block lässt sich nicht als Ganzes lesen.
• "Incorrect value type": Ein Feld enthält einen Wert mit unerwartetem Typ.
• Parsing Fehler wie "Parsing error: Missing ':'": Ein nötiges Satzzeichen fehlt.
• Probleme mit Escape Sequenzen und Unicode: Sonderzeichen sind falsch kodiert.
• "Duplicate unique property": Dasselbe Feld steht zweimal im selben Objekt.

Diese Liste ist nicht vollständig, denn die Hilfeseite nennt weitere Fehlertypen. Die Beschreibung Ihrer Zeile ist der erste Hinweis auf die Fehlerfamilie. Notieren Sie also den Fehlernamen und vergleichen Sie ihn dann mit der Ausgabe des Rich Results Test.

Welche JSON-LD Syntaxfehler lösen das Problem aus?

JSON-LD ist das Format, das Google für Auszeichnungen empfiehlt. Eine Maschine liest es, deshalb verzeiht es keine kleinen Schlampereien, über die ein Mensch hinwegsieht. Wir beschreiben die häufigsten Syntaxfehler ohne Codebeispiel.

• Fehlendes Komma: Vergessen Sie das Trennzeichen zwischen zwei Feldern, bricht der Block mittendrin ab.
• Überflüssiges Komma: Ein Komma nach dem letzten Feld stoppt viele Parser.
• Fehlendes oder zusätzliches Anführungszeichen: Anfang und Ende eines Textwerts passen nicht zusammen.
• Nicht geschlossene Klammer: Ein Objekt oder eine Liste wird geöffnet, aber nie beendet.
• Feldname ohne Anführungszeichen: Auch Feldnamen brauchen Anführungszeichen.

Zum Beispiel bearbeitet ein Team einen Block von Hand, fügt ein Feld hinzu und lässt das Komma davor weg. Dann ist der gesamte Block unlesbar. Ein einziges Zeichen macht Ihre komplette Auszeichnung wertlos.

Solche Fehler erkennen Sie mit bloßem Auge kaum. Dafür brauchen Sie einen Parser, und das passende Werkzeug beschreiben wir in einem späteren Abschnitt.

Warum lösen Escape Zeichen und Anführungszeichen den Fehler aus?

Textwerte im Markup Block stehen in doppelten Anführungszeichen. Enthält Ihr Titel oder Ihre Beschreibung selbst ein doppeltes Anführungszeichen, müssen Sie es mit einem Sondersymbol maskieren. Fehlt dieses Symbol, glaubt der Parser, der Text sei zu Ende, und findet den Rest sinnlos.

Das Problem tritt am häufigsten in dynamischen Templates auf. Ein Produktname oder Beitragstitel fließt automatisch in den Block. Enthält ein Titel ein Anführungszeichen, einen Backslash oder einen Zeilenumbruch, bricht nur diese eine Seite. Deshalb taucht der Fehler oft bei wenigen von hunderten Seiten auf.

Achten Sie auf diese Quellen:

• Typografische Anführungszeichen und unsichtbare Sonderzeichen, die aus einem Texteditor stammen.
• Außerdem Zeilenumbrüche in Beschreibungsfeldern.
• Zudem Dateipfade oder Produktcodes mit Backslashes.
• Zeichen mit defekter Kodierung, die der Parser womöglich als Unicode Fehler meldet.

Die Lösung: Maskieren Sie jeden Wert automatisch, bevor er in den Block gelangt. Meist korrigieren Sie das an einer einzigen Stelle im Template.

Kann ein ungültiges Datums- oder Zahlenformat den Fehler verursachen?

Meistens nicht, indirekt aber doch. Ein falsches Datumsformat zerstört das JSON für sich allein nicht. Deshalb erscheinen Datumsprobleme normalerweise als Warnung oder Fehler im jeweiligen Rich Result Bericht. Eine Zeile wie "Incorrect value type" kann dennoch darauf hindeuten, dass ein Feld falsche Daten erhielt.

Diese Fälle erzeugen echte Parsing Fehler:

• Eine Einheit oder ein Währungssymbol im Zahlenfeld, sodass der Wert zu Text ohne Anführungszeichen wird.
• Eine leere Template Variable, die einen Feldnamen ohne Wert zurücklässt.
• Eine Zahl mit Dezimalkomma, die nicht in Anführungszeichen steht.
• Ein Wort wie "unbekannt" an der Stelle eines Datums, ohne Anführungszeichen.

In der Praxis nutzen Sie für Daten das internationale ISO Format, schreiben Zahlen mit Dezimalpunkt und legen Einheiten in ein eigenes Feld. Zudem bauen Sie für jedes mögliche Leerfeld eine Bedingung ein: Gibt es keinen Wert, lassen Sie das Feld ganz weg.

Wie finden Sie einen defekten zweiten Block auf derselben Seite?

Eine Seite kann mehrere Markup Blöcke enthalten. Ihr Theme gibt einen aus, das SEO Plugin einen zweiten und ein Bewertungsplugin einen dritten. Ist nur einer davon defekt, meldet der Bericht trotzdem einen Fehler, obwohl die anderen einwandfrei sind.

Prüfen Sie beim Test also nicht nur den ersten Block. Der Rich Results Test listet die Ergebnisse Element für Element auf. Dort trennen Sie die gesunden Typen vom Block, der sich nicht parsen lässt. Findet das Tool überhaupt keinen Typ, ist der defekte Block womöglich der einzige.

So finden Sie ihn:

1. Zunächst öffnen Sie den Seitenquelltext und zählen Sie die Markup Blöcke.
2. Dann ermitteln Sie, welches Plugin oder welche Template Datei jeden Block erzeugt.
3. Danach deaktivieren Sie die verdächtige Quelle vorübergehend und testen Sie die Seite erneut.
4. Verschwindet der Fehler, haben Sie den Verursacher gefunden.

Bei Pluginkonflikten liefert diese Methode das schnellste Ergebnis.

Wie erzeugt ein Pluginkonflikt nicht parsbare strukturierte Daten?

In Systemen wie WordPress versuchen mehrere Plugins, dieselbe Information auszuzeichnen. Eines markiert die Seite als Artikel, ein anderes als Produkt. Meist ist das Problem eine doppelte Angabe. Manchmal beschädigt oder kürzt ein Plugin jedoch die Ausgabe eines anderen.

Typische Szenarien sehen so aus:

• Ein Cache- oder Minify Plugin verändert Zeilenumbrüche oder Anführungszeichen in der Ausgabe.
• Ein Sicherheitsplugin entfernt Sonderzeichen aus dem Block und zerstört dessen Struktur.
• Außerdem schreiben ein altes Theme und ein neues SEO Plugin dasselbe Feld.
• Zudem ändert ein Übersetzungsplugin beim Übersetzen der Werte die Anführungszeichen.

Hier ein Beispielszenario: Färbt sich der Bericht kurz nach der Installation eines neuen SEO Plugins rot, ist dieses Plugin der erste Verdächtige. Deaktivieren Sie es, leeren Sie den Cache und testen Sie erneut. Stürzt Ihre Seite dagegen ab, haben Sie ein anderes Problem; dafür hilft unser Beitrag zum kritischen WordPress Fehler.

Zur Lösung des Konflikts lassen Sie jeden Typ nur von einer Quelle erzeugen. In der anderen Quelle schalten Sie die Funktion ab.

Warum verursachen Template Fehler nicht parsbare strukturierte Daten auf tausenden Seiten?

Googles Dokumentation nennt einen Fehler im zugrunde liegenden Template als häufigsten Grund dafür, dass ein einzelner Fehler viele Seiten betrifft. Das ist logisch, denn derselbe Code läuft auf jeder Seite. Verschwindet ein Komma aus dem Template, bricht jede Seite, die es nutzt.

Die Zahl der betroffenen Seiten liefert Ihnen daher einen Hinweis. Scheitern nur wenige Seiten, steckt vermutlich ein inhaltsbedingtes Anführungszeichen oder Sonderzeichen dahinter. Scheitern hunderte, prüfen Sie das Template.

Gehen Sie bei der Template Korrektur in dieser Reihenfolge vor:

1. Zunächst bestimmen Sie das gemeinsame Template der betroffenen Seiten, etwa Produkt, Blog oder Kategorie.
2. Dann prüfen Sie die Markup Ausgabe dieses Templates auf einer Beispielseite.
3. Danach kontrollieren Sie, ob die Variablenwerte maskiert werden.
4. Außerdem ergänzen Sie Bedingungen für den Fall, dass ein Wert leer ist.
5. Schließlich testen Sie die Korrektur zuerst auf einer Staging Kopie und danach live.

Eine Template Korrektur rettet oft hunderte Seiten auf einmal. Suchen Sie deshalb zuerst die gemeinsame Ursache.

Wie diagnostizieren Sie eine defekte Seite Schritt für Schritt?

Systematisches Vorgehen ist deutlich schneller als Raten. Googles Anleitung zur Fehlersuche bei fehlenden strukturierten Daten empfiehlt eine ähnliche Reihenfolge: zuerst die Indexierung der Seite bestätigen, dann die Daten validieren und zuletzt sicherstellen, dass nichts den Zugriff blockiert.

1. Zunächst öffnen Sie die Fehlerzeile in der Search Console und wählen Sie eine Beispieladresse.
2. Dann prüfen Sie mit dem URL Inspection Tool, ob die Seite indexiert ist und Google die aktuelle Version sieht.
3. Danach geben Sie dieselbe Adresse in den Rich Results Test ein und lesen Sie die Fehlerzeile.
4. Außerdem kontrollieren Sie im angezeigten Code die Balance von Kommas, Anführungszeichen und Klammern.
5. Zudem schicken Sie den Quelltext bei Bedarf durch einen JSON Validator.
6. Haben Sie die Ursache gefunden, setzen Sie die Korrektur um und wiederholen den Test.

Scheitert schon der Live Test, hilft Ihnen unser Beitrag zur URL Prüfung: Seitenressourcen konnten nicht geladen werden. Außerdem finden Einsteiger in unserer Search Console Anleitung den Überblick.

Wie bestätigen Sie die Korrektur mit dem Rich Results Test?

Der Rich Results Test ist Googles kostenloses Werkzeug zur Validierung von Markup. Die Hilfeseite rät, ihn zur Behebung nicht parsbarer Daten zu nutzen und Korrekturen in kleinen Schritten zu testen. Sie können ihn auf zwei Arten einsetzen: mit einer Live Adresse oder mit eingefügtem Code.

Das Einfügen von Code eignet sich ideal, um eine Korrektur vor der Veröffentlichung zu probieren. So sehen Sie eine riskante Änderung, bevor sie die Live Seite erreicht. Nach der Veröffentlichung testen Sie die Live Adresse immer erneut.

Achten Sie beim Test auf diese Punkte:

• Meldet das Tool einen Parsing Fehler, oder listet es die Typen erfolgreich auf?
• Erscheinen zudem alle erwarteten Typen?
• Und entspricht die getestete Version der, die Ihre Besucher sehen?

Hinweis: Ein bestandener Test heißt nicht, dass ein Rich Result erscheint. Google garantiert das nicht einmal bei korrekt ausgezeichneten Seiten.

Bauen Sie Markup neu auf, liefert unser Schema Generator einen syntaktisch sauberen Ausgangspunkt.

Wie validieren Sie die Korrektur in der Search Console?

Haben Sie die Korrektur veröffentlicht, öffnen Sie die Fehlerzeile und klicken auf die Schaltfläche "Validate Fix". Google prüft dann die betroffenen Seiten erneut. Menü- und Schaltflächennamen können sich ändern, suchen Sie daher in Ihrem Panel nach einer ähnlichen Bezeichnung.

Googles Dokumentation beschreibt diese Validierungsstatus:

• "Started": Die Prüfung hat begonnen.
• "Looking good": Die bisher geprüften Seiten sind behoben.
• "Passed": Alle bekannten Fälle sind gelöst.
• "Failed": Das Problem besteht fort, und Sie müssen die Validierung neu starten.

Bevor Sie starten, stellen Sie sicher, dass Sie alle betroffenen Templates korrigiert haben. Beginnen Sie mit einer halben Lösung, schlägt die Validierung fehl und der Prozess startet neu. Testen Sie also zuerst einige Beispielseiten und drücken Sie dann die Schaltfläche.

Ist eine Seite nicht indexiert, lösen Sie dieses Problem zuerst. Unser Beitrag zu nicht indexierten Seiten zeigt Ihnen, wie.

Wie lange dauert die Validierung und warum kann sie scheitern?

Googles Hilfeseite nennt für die Validierung typischerweise etwa zwei Wochen, in manchen Fällen deutlich länger. Wir können das nicht abkürzen, bleiben Sie also beim Warten gelassen. Crawlhäufigkeit und Zahl der betroffenen Seiten beeinflussen die Dauer.

Die Validierung kann aus diesen Gründen scheitern:

• Sie haben nur einen Teil der Seiten korrigiert, andere Templates bleiben defekt.
• Zudem liefert ein Cache weiterhin die alte Version aus.
• Der defekte Block stammt aus einem anderen Plugin.
• Zudem sind die Seiten für Googlebot gesperrt oder auf noindex gesetzt.

Scheitert die Validierung, öffnen Sie die neuen Beispieladressen in der Fehlerzeile erneut. Meist ist Ihnen eine zweite Quelle entgangen.

Ein Ergebnis "Passed" bedeutet allerdings nicht, dass der Fehler nie wiederkehrt. Wie Sie das verhindern, erklärt ein späterer Abschnitt.

Warum ändern sich die Zahlen im Bericht nicht sofort?

Berichte laufen nicht in Echtzeit. Die Zahlen aktualisieren sich, sobald Google Seiten erneut crawlt und bewertet. Zudem weist Googles Dokumentation darauf hin, dass verwandte Berichte nur eine Stichprobe Ihrer Seiten zeigen. Eine korrigierte Seite verschwindet daher nicht am nächsten Tag aus dem Bericht.

Die wichtigsten Gründe für die Verzögerung:

• Googlebot hat die Seite noch nicht erneut gecrawlt.
• Denn das Entdecken neuer Daten braucht Zeit.
• Außerdem deckt der Bericht nur indexierte Seiten ab.
• Die Elementzahl schwankt, wenn sich die Stichprobengröße ändert.

Zur Beschleunigung können Sie für wichtige Seiten über das URL Inspection Tool eine Indexierung beantragen. Bedenken Sie jedoch, dass ein Tageskontingent gilt. Details nennt unser Beitrag zum Kontingent in der Search Console.

Welche Ursache prüfen Sie bei welchem Symptom zuerst?

Die folgende Tabelle fasst die Muster zusammen, die wir in der Praxis am häufigsten sehen. Verstehen Sie sie als Startpunkt, denn jede Seite ist anders.

Beginnen Sie mit der ersten Zeile, denn ein Template Problem betrifft die meisten Seiten und bringt den schnellsten Erfolg.

Wie beugen Sie dem Fehler von Anfang an vor?

Vorbeugen kostet weniger als Reparieren. Bei Seiten, die ständig neue Inhalte veröffentlichen, machen einige Gewohnheiten einen großen Unterschied.

• Also nutzen Sie einen verlässlichen Generator oder ein Plugin, statt Markup von Hand zu schreiben.
• Maskieren Sie dynamische Werte, bevor sie in den Block gelangen, und überspringen Sie leere Werte.
• Testen Sie nach jeder Template Änderung vor dem Release eine Beispielseite mit dem Rich Results Test.
• Außerdem lassen Sie jeden Markup Typ nur von einer Quelle erzeugen.
• Dann prüfen Sie den Bericht nach jedem Plugin- und Theme Update.

Lassen Sie außerdem die Benachrichtigungen per E-Mail der Search Console eingeschaltet. So erfahren Sie schnell von einer neuen Fehlerzeile.

Stellen Sie bei Seiten, die auf Rich Results zielen, sicher, dass der Inhalt zum Markup passt. Google verlangt, dass Sie keine Inhalte auszeichnen, die Besucher nicht sehen.

Schaden nicht parsbare strukturierte Daten Ihrem Ranking?

Erwarten Sie keinen direkten Ranking Einbruch, doch der indirekte Verlust ist real. Eine Seite mit defektem Block kann sich nicht für die zugehörige Rich Result Funktion qualifizieren. Dadurch können Klickrate, Sichtbarkeit und Wettbewerbsvorteil schrumpfen.

Trotzdem garantiert Markup nie, dass Google ein Rich Result zeigt. Betrachten Sie es also als Weg, Ihre Seite korrekt zu beschreiben, nicht als Ranking Trick. Ist Ihr Traffic eingebrochen, grenzen Sie die Ursache zuerst mit unserer Anleitung zum Traffic Einbruch in der Search Console ein.

Hat eine Seite zum Beispiel Traffic verloren, vergleichen Sie zuerst ihr Suchbild, bevor Sie dem Markup die Schuld geben. Meist liegt die wahre Ursache woanders.

Ein Syntaxfehler fragt nicht nach dem Markup Typ. Ob FAQ, Artikel, Produkt oder Organisation: Ein defekter Block bleibt unlesbar. Weil sich die Unterstützung mancher Typen mit der Zeit ändert, vereinfachen Sie alte Auszeichnungen wie FAQPage Schema. Nutzen Sie Bewertungsmarkup, lesen Sie auch unsere Hinweise zu den AggregateRating Richtlinien. Dass ein Typ an Unterstützung verliert, ist kein Grund, ihn defekt zu lassen.

Wie priorisieren Sie den Bericht, wenn nicht parsbare strukturierte Daten auftauchen?

Öffnen Sie den Bericht und prüfen Sie zunächst die Reihenfolge der Fehlerzeilen. Google sortiert nach Schweregrad, daher steht der Fehler mit den meisten betroffenen Seiten oben. Ein Klick auf eine Zeile zeigt die betroffenen Seiten, die Fehlerdetails und Links zu Debugging Werkzeugen.

Wir empfehlen diese Priorisierung:

1. Zunächst beginnen Sie mit der Zeile, die die meisten Seiten betrifft, denn dahinter steckt womöglich ein gemeinsames Template.
2. Dann wählen Sie aus jeder Zeile zwei bis drei Beispielseiten aus verschiedenen Kategorien.
3. Danach testen Sie die Beispiele und notieren Sie die Fehlerfamilie.
4. Schließlich fassen Sie Zeilen mit gleicher Ursache zu einer einzigen Korrekturaufgabe zusammen.

Um den Bericht einer Kollegin oder einem Entwickler zu zeigen, nutzen Sie den Freigabelink. Laut Googles Dokumentation gewährt er nur Lesezugriff auf das aktuelle Problem. Mit der Download Schaltfläche exportieren Sie außerdem die Seitenliste.

Führen Sie nicht parsbare strukturierte Daten in einer eigenen Aufgabenliste, getrennt von anderen technischen Problemen. Dann sehen Sie leichter, was erledigt ist.

Wie stören Cache und Minify Einstellungen das Markup?

In manchen Setups läuft die Seitenausgabe durch einen Cache, einen Minifier oder eine Sicherheitsschicht, bevor sie den Besucher erreicht. Diese Schichten sind normalerweise harmlos. Falsch konfiguriert, verändern sie jedoch Leerzeichen, Zeilenumbrüche oder Anführungszeichen im Block.

Das typische Zeichen: Die Seite wirkt im Adminbereich gesund, ist live aber defekt. Deshalb ist der Test einer Live Adresse verlässlicher als nur eingefügter Code.

Vermuten Sie diese Ursache, gehen Sie so vor:

• Zunächst leeren Sie den Cache und testen die Seite erneut.
• Dann schalten Sie die Minimierung vorübergehend ab.
• Danach prüfen Sie die Regeln Ihrer Firewall oder Ihres Inhaltsfilters.
• Zudem probieren Sie es zuerst an einer Seite, dann rollen Sie es auf die ganze Website aus.

Verschwindet der Fehler, kennen Sie die verantwortliche Schicht. Nehmen Sie den Block dann in deren Ausnahmeliste auf.

Wie verläuft eine Korrektur in einem Beispielszenario?

Das Folgende ist ein erfundenes Beispielszenario zur Veranschaulichung, kein echter Kunde. Ein kleiner Onlineshop nutzt auf seinen Produktseiten Produkt Markup. Eines Tages zeigt die Search Console eine Zeile zu nicht parsbaren strukturierten Daten mit Dutzenden betroffener Seiten.

1. Zuerst öffnet die Shopbetreiberin die Zeile und schickt drei verschiedene Produktseiten durch den Rich Results Test.
2. Das Tool zeigt bei allen dreien einen Parsing Fehler nahe dem Feld für den Produktnamen.
3. Dann fällt ihr auf, dass die Produktnamen ein Zollzeichen enthalten, das mit dem doppelten Anführungszeichen identisch ist.
4. Das Template schreibt den Produktnamen ohne Maskierung in den Block.
5. Danach ändert ein Entwickler das Template so, dass es den Wert maskiert.
6. Schließlich testet sie die Live Seiten erneut und startet die Validierung.

In diesem Szenario trat das Problem nur bei bestimmten Produkten auf, weil nur deren Namen das Sonderzeichen enthielten. Daher wirkt der Fehler auf den ersten Blick zufällig. Tatsächlich gibt es eine Regel, doch Sie müssen betroffene und unbetroffene Seiten vergleichen, um sie zu finden.

Welche Prüfungen führen Sie nach der Korrektur durch?

Nach der Veröffentlichung genügt ein grünes Ergebnis im Testtool nicht. Einige zusätzliche Prüfungen verhindern, dass der Fehler zurückkehrt.

1. Zunächst testen Sie die Live Adressen erneut mit dem Rich Results Test.
2. Dann bestätigen Sie im URL Inspection Tool, dass die Seite indexiert ist.
3. Danach testen Sie mindestens eine weitere Seite aus jedem anderen Template.
4. Außerdem leeren Sie den Cache und prüfen Sie das Ergebnis noch einmal.
5. Zudem starten Sie die Validierung in der Search Console und beobachten Sie den Status.
6. Schließlich sehen Sie nach einigen Wochen in den zugehörigen Rich Result Berichten nach Veränderungen.

Schreiben Sie die Reparatur außerdem in ein Änderungsprotokoll. Notieren Sie, was defekt war, wie Sie es gelöst haben und welches Template betroffen war. Diese Notiz spart Ihnen beim nächsten Plugin Update Zeit.

Ist eine Seite, die noch im Bericht steht, wirklich defekt?

Nicht immer. Eine Adresse im Bericht zeigt den Zustand beim letzten Crawl von Google. Haben Sie die Seite repariert, Google sie aber noch nicht erneut gecrawlt, bleibt die Adresse in der Liste.

Machen Sie deshalb zuerst den Live Test. Liefert das Tool ein sauberes Ergebnis, ist die Seite jetzt gesund, und Sie müssen nur die Validierung starten und warten. Meldet das Tool einen Fehler, hat Ihre Korrektur die Live Seite noch nicht erreicht, oder eine andere Quelle ist defekt.

Außerdem deckt der Bericht nur indexierte Seiten und eine Stichprobe ab. Eine Seite, die Sie nicht in der Liste sehen, kann trotzdem defekt sein. Denken Sie daran, damit Ihre Template Korrektur wirklich jede Seite erreicht.

Welche Kontrollpunkte gehören in Ihren Release Prozess?

Sehen Sie einen Fehler in der Search Console, ist das Problem bereits live. Besser fangen Sie es vor dem Release ab. Dafür brauchen Sie keine aufwendige Infrastruktur. Eine kurze Checkliste genügt oft.

• Wählen Sie vor einer Template- oder Plugin Änderung je Template Typ eine Beispielseite.
• Danach testen Sie diese Beispiele nach der Änderung mit dem Rich Results Test.
• Legen Sie eine Testseite an, deren Titel ein Anführungszeichen, einen Schrägstrich oder ein Emoji enthält, und testen Sie auch diese.
• Außerdem testen Sie ebenso einen Datensatz mit leerem Feld, um Fehler durch leere Werte zu erwischen.
• Schließlich öffnen Sie einige Tage nach dem Update die Search Console und suchen Sie nach neuen Fehlerzeilen.

Diese Gewohnheit lohnt sich besonders bei aktiven E-Commerce und Content Seiten. Template Fehler breiten sich still auf hunderte Seiten aus, während die Checkliste nur wenige Minuten dauert.

Wann sollten Sie professionelle Hilfe holen?

Sitzt der Fehler auf einer einzelnen Seite, beheben Sie ihn meist selbst. Fallen jedoch hunderte Seiten aus, überlagern sich Themes und Plugins oder scheitert die Validierung immer wieder, spart ein geübter Blick Zeit.

Wir, Talha Aslan und Team, führen solche technischen Prüfungen im Rahmen unserer SEO Beratung durch. Zunächst untersuchen wir die Template Ausgabe, dann trennen wir die Quellen Schritt für Schritt. Ein Ergebnis versprechen wir nicht, doch wir zeigen Ihnen genau, wo das Problem sitzt.

Möchten Sie selbst prüfen, ist unser SEO Check für einen ersten Durchgang praktisch. Und wollen Sie wiederkehrende Prüfungen automatisieren, hilft Ihnen unsere Lösung KI Reporting Automatisierung.

Zu einem verwandten Thema zeigt unser Schwesterbeitrag Ähnliche Fragen Box in Google, wie Sie Inhalte als Fragen aufbauen. Als offizielle Quellen lesen Sie Googles Hilfeseite zum Unparsable structured data report, die Anleitung zum Debugging fehlender strukturierter Daten und die allgemeinen Richtlinien für strukturierte Daten.