Googlebot und JSON-LD: ein einziger Unescape-Durchlauf

#Was Google tatsächlich geändert hat

Die Aussage ist kurz und lohnt das vollständige Zitat, weil alles Weitere aus einem Satz folgt:

To bring our parser up to JSON and other standards, we changed our JSON-LD extraction and are now only applying a single pass of HTML unescaping

Gary Illyes ergänzte den Hinweis, wo Korrektheit definiert ist: RFC 8259, die JSON-Spezifikation. Das ist keine SEO-Empfehlung, sondern der Verweis auf einen Standard, dem jeder JSON-Parser folgt.

Die praktische Folge steht ebenso knapp da: Doppelt escapte Entities wie & oder ✔ werden nicht mehr aufgelöst. Früher machte der Parser einen zusätzlichen Durchlauf und zog das gerade. Jetzt macht er einen Durchlauf und behält Text, der kein gültiges JSON ist.

Nennen wir gleich, was in dieser Information fehlt. Es gibt kein Rollout-Datum. Es gibt keinen Link auf aktualisierte Google-Dokumentation. Quelle ist ein LinkedIn-Beitrag, berichtet von Search Engine Roundtable am 21. August 2026. Behandeln Sie es als von Google beschriebenen Stand und nicht als Spezifikation, die Sie einem Kunden vorlegen können.

#Was doppeltes Escaping ist und woher es kommt

Nehmen Sie einen einfachen Fall: der Firmenname „Müller & Sohn“ im Feld name eines JSON-LD-Blocks.

Ein Und-Zeichen allein sprengt den Block nicht, JSON verlangt dafür kein Escaping. Ernst wird es beim Anführungszeichen. Schreibt ein Template " dort, wo \" hingehört, bleibt nach einem Durchlauf " übrig statt eines Anführungszeichens. Der String schließt nicht und der Block ist kein JSON mehr.

Woher kommt das in WordPress? Fast immer aus doppelter Verarbeitung desselben Werts. Inhalt läuft beim Speichern durch esc_html(), bei der Ausgabe durch einen Theme-Filter und landet zuletzt in einem JSON-LD-Feld, das ohnehin selbst korrekt escapt hätte. Jeder Schritt für sich ist richtig. Zusammengesetzt ergeben sie eine Schreibweise, die jahrelang nur funktionierte, weil Google sie für uns geradezog.

#Wie Sie Ihren Korpus in fünf Minuten prüfen

Die wichtigste Regel: Sie prüfen das gebaute HTML, nicht die Template-Quelle. In der Quelle sieht alles gut aus, weil das Escaping erst bei der Ausgabe dazukommt. Bei einem statischen Build scannen Sie das Ausgabeverzeichnis. Bei klassischem WordPress ziehen Sie eine Stichprobe an URLs mit wget oder curl und scannen, was der Server geantwortet hat.

Die Prüfung selbst sind ein gutes Dutzend Zeilen. Holen Sie jeden <script type="application/ld+json">-Block heraus, versuchen Sie ihn zu parsen und suchen Sie getrennt das Muster der doppelten Entity:

const RE = /<script[^>]*type=["']application\/ld\+json["'][^>]*>([\s\S]*?)<\/script>/gi;
let m;
while ((m = RE.exec(html))) {
  const body = m[1];
  if (/&amp;(quot|amp|lt|gt|#\d+);/.test(body)) report("doppelte Entity", file);
  try { JSON.parse(body); } catch (e) { report("parst nicht: " + e.message, file); }
}

Zwei getrennte Tests, weil sie Unterschiedliches fangen. JSON.parse scheitert an einem kaputten String, akzeptiert aber & in einem Wert, der weiterhin gültiges JSON ist und nur Müll enthält. Der Entity-Test fängt genau diesen zweiten Fall: Der Block parst, und im Rich Result steht & statt eines Zeichens.

Ein dritter Test lohnt sich: einzelne HTML-Entities in Werten. Die sind kein Fehler, werden nach der Änderung aber genau einmal aufgelöst, das Ergebnis kann also von dem abweichen, was Sie kannten. Besser, Sie wissen davon.

#Unsere Messung: 68 055 Blöcke, null Fehler

Wir haben diesen Scan am 30. August 2026 über den eigenen Korpus laufen lassen, gegen einen frisch gebauten Produktionsstand.

Null in allen drei Kategorien. Das schreiben wir nicht als Lob, sondern als Information darüber, was dieses Ergebnis bedeutet und was nicht. Unser Stack erzeugt strukturierte Daten aus dem Frontmatter über Astro-Komponenten und fügt sie mit dem Muster set:html={JSON.stringify(...)} ein. JSON.stringify liefert per Definition gültiges JSON, und set:html ergänzt kein eigenes HTML-Escaping. Anders gesagt: Wir haben die Null nicht, weil wir vorsichtig waren, sondern weil dieses Muster doppeltes Escaping gar nicht erzeugen kann.

Das ist wichtiger als die Zahl. Wenn Ihr Stack JSON-LD im Template aus Strings zusammensetzt oder ein Plugin ein Inhaltsfeld in vorbereitetes JSON einklebt, ist das Risiko real und Ihr Ergebnis wird anders aussehen. Messen Sie Ihres, übernehmen Sie nicht unseres.

#Wo es in WordPress am häufigsten bricht

Aus unseren Kundenaudits kommen drei wiederkehrende Quellen.

Erstens ein SEO-Plugin, das description aus einem Feld füllt, das bereits durch wp_kses oder esc_attr gelaufen ist. Es scheitert meist am Apostroph und am Anführungszeichen, und in deutschen Texten fallen zusätzlich die typografischen Anführungszeichen ins Gewicht, die viele Redaktionssysteme automatisch setzen.

Zweitens ein handgeschriebener JSON-LD-Block in header.php oder in den Theme-Optionen, in dem Werte per echo ohne wp_json_encode eingesetzt werden. Das ist die übliche Variante in vor Jahren gebauten Individual-Themes und die am schwersten zu findende, weil sie in keiner Plugin-Oberfläche auftaucht.

Drittens ein Page Builder, der Inhalte bereits mit HTML-Entities in der Datenbank ablegt. Dann bekommt auch ein korrekt geschriebener JSON-LD-Generator Text mit & herein und kodiert ihn pflichtbewusst ein zweites Mal.

Der gemeinsame Nenner ist immer derselbe: ein Wert wird zweimal escapt, einmal für HTML und einmal für JSON, von zwei Schichten, die nichts voneinander wissen.

#Wie Sie es korrekt kodieren

Die Regel ist eindeutig, weil es dafür einen Standard gibt. Escapen Sie im JSON-Wert nach JSON-Art, nicht nach HTML-Art.

In PHP heißt das wp_json_encode() über die gesamte Struktur, niemals von Hand zusammengesetzte Strings. In JavaScript JSON.stringify(). Im Astro-Template das Muster, das wir selbst nutzen:

<script type="application/ld+json" set:html={JSON.stringify(schema)} />

Brauchen Sie wirklich ein Zeichen, das den Script-Block vorzeitig schließen könnte, nehmen Sie eine universelle Escape-Sequenz. & und < sind in jedem JSON-Parser sicher und verlangen vom Leser kein HTML-Wissen.

Was Sie nicht tun sollten: keine HTML-Entity in einen JSON-Wert schreiben in der Hoffnung, dass jemand sie auflöst. Jahrelang war dieser jemand Google. Ab jetzt löst Google genau einmal auf, und jeder andere Konsument Ihrer strukturierten Daten, von Bing bis zum KI-Assistenten, war dazu nie verpflichtet.

#Ein einmaliges Audit genügt nicht, machen Sie ein Gate daraus

Das ist der Teil, der meist übersprungen wird. Strukturierte Daten sind kein Text, den man einmal schreibt. Template, Plugin oder Integration erzeugen sie, und jedes Update kann das Escaping zurückbringen. Ein heute gelaufenes Audit spricht über den heutigen Build und über nichts sonst.

Wir haben den Scan in ein Gate nach dem Build verwandelt. Es liest das Ausgabeverzeichnis, zählt Blöcke, versucht jeden zu parsen und scheitert nur bei einem echten Problem, also bei einem Block, der nicht parst, oder bei einer doppelten Entity. Fehlt das Ausgabeverzeichnis, endet es mit null, damit kein falsches Rot in einer Umgebung entsteht, in der noch niemand gebaut hat.

Drei Details entscheiden, ob so ein Gate etwas taugt. Erstens muss es das Artefakt lesen, nicht die Quelle, denn die Quelle beweist nichts über Escaping. Zweitens muss es Blöcke zählen und die Zahl ausgeben, damit auffällt, wenn sie von achtundsechzigtausend auf zweihundert fällt, weil eine Integration nichts mehr erzeugt. Drittens muss es Fehler von Hinweis trennen: einzelne HTML-Entities werden gemeldet, brechen den Build aber nicht, denn das ist keine Störung, sondern etwas, das man wissen sollte.

#Was tun, wenn der Scan etwas findet

Ein Scan liefert eine Dateiliste, keine Diagnose. Klären Sie vor jeder Korrektur, welche Schicht die Schreibweise erzeugt, sonst kommt der Fehler beim nächsten Update zurück.

Nehmen Sie eine URL aus der Liste und sehen Sie sich die rohe Serverantwort an, etwa mit curl -s URL | grep -A5 "application/ld+json". Prüfen Sie, ob der beschädigte Wert aus dem Beitragstitel, der SEO-Beschreibung oder einem eigenen Feld stammt. Das zeigt die Schicht schneller als Code-Lesen.

Danach entscheiden Sie nach Quelle:

1. Kommt der Wert aus einem SEO-Plugin, prüfen Sie, ob zwei Plugins denselben Schema-Typ erzeugen. Ein doppelter Generator ist häufiger die Ursache seltsamer Werte als ein Fehler in einem der beiden.
2. Steht der Block im Theme, schreiben Sie ihn auf wp_json_encode() über das gesamte Array um. Manuelles String-Zusammensetzen ist hier der einzige echte Fehler und lässt sich nicht halb beheben.
3. Stecken die Entities schon in der Datenbank, weil ein Page Builder sie dort abgelegt hat, reparieren Sie es nicht im Generator. Dekodieren Sie den Wert einmal vor der Übergabe an den JSON-Encoder, etwa mit html_entity_decode() samt Quote-Flag und explizitem UTF-8.

Der klassische Fehler sieht so aus:

echo '{"name":"' . esc_html( $title ) . '"}';

Richtig sieht so aus:

echo wp_json_encode( array( 'name' => $title ) );

Der Unterschied liegt nicht in der Zeichenzahl, sondern darin, wer für das Escaping zuständig ist. In der ersten Fassung eine HTML-Funktion in einem Kontext, der kein HTML ist. In der zweiten ein JSON-Encoder im JSON-Kontext.

Nach der Korrektur scannen Sie einen neuen Build, nicht das alte Artefakt. Das klingt banal, und die Hälfte aller Meldungen „behoben und trotzdem kaputt“ ist ein Scan über ein veraltetes Ausgabeverzeichnis.

#Was Sie real verlieren, wenn Sie es ignorieren

Verlorenes Schema tut nicht sofort weh, und genau das ist das Schlimmste daran. Es gibt keinen Positionssturz über Nacht, es gibt ein allmähliches Verschwinden dessen, was das Ergebnis hervorhob: Bewertungssterne, Produktdaten, eine FAQ-Liste, Breadcrumbs. Den Effekt sehen Sie in der Klickrate, nicht in der Position, und die Klickrate fällt langsam und lässt sich leicht anderem zuschreiben.

Der zweite Abnehmer dieser Daten ist neuer und weniger nachsichtig. Antwortmaschinen lesen strukturierte Daten, weil das der billigste Weg ist festzustellen, worum es auf einer Seite geht, ohne den ganzen Text zu interpretieren. Bei uns ist Agenten-Traffic inzwischen messbar und nicht am Rand: in der Größenordnung von hundert Besuchen am Tag, zwei Drittel davon über unseren eigenen MCP-Endpunkt. Diese Systeme haben keinen Grund, fremdes Escaping zu reparieren. Google tat es jahrelang aus Höflichkeit gegenüber dem vorgefundenen Web. Ein neuer Konsument Ihrer Daten hatte diese Gewohnheit nie.

Die dritte Schicht ist die Search Console, und hier gehört gesagt, was Sie dort nicht erfahren. Die Berichte zu Rich Results zeigen einen Rückgang gültiger Elemente, sie sagen aber nicht „dieser Block parste wegen einer doppelten Entity nicht“. Sie sehen, dass Elemente fehlen, und müssen selbst herausfinden warum. Deshalb lohnt der Scan auf Ihrer Seite: Er liefert die Ursache statt nur das Symptom.

#Was wir nicht wissen und was trotzdem zu tun ist

Wir kennen kein Rollout-Datum. Wir wissen nicht, ob die Änderung alle Schema-Typen gleich trifft und ob die Search Console eine verlorene Entity überhaupt meldet oder das Rich Result einfach ausbleibt. Es gibt keine aktualisierte Dokumentation, auf die man einen Kunden verweisen könnte. Das sind echte Lücken, und es ist besser, sie zu benennen, als einem LinkedIn-Beitrag den Rang einer Spezifikation zu geben.

Trotz dieser Lücken ist die operative Entscheidung einfach und hängt von keiner der fehlenden Informationen ab. Gültiges JSON war auch damals gültig, als Google Fehler für Sie behob. Scannen Sie Ihr gebautes HTML, reparieren Sie, was nicht parst, ersetzen Sie HTML-Entities in Werten durch JSON-Escapes und verankern Sie den Test im Prozess, damit er nicht zurückkommt. Kommt am Ende eine Null heraus wie bei uns, ist auch das ein Ergebnis: Sie wissen, dass Ihr Generator diesen Fehler nicht erzeugen kann, und müssen bei jedem Plugin-Update nicht mehr darüber nachdenken.

Das größte Risiko liegt nicht in der Änderung selbst, sondern darin, dass sie leise ist. Es kommt kein Alarm. Das Rich Result bleibt einfach aus, und drei Monate später zeigt ein Report einen Sichtbarkeitsrückgang ohne offensichtliche Ursache. Fünf Minuten Scan heute sind billiger als diese Untersuchung.