Wenn du strukturierte Daten auf deiner Website nutzt, klingt diese Änderung erst einmal klein, fast schon wie eine technische Randnotiz. Ein Parser verhält sich jetzt etwas strenger, ein paar Zeichen werden anders behandelt, fertig. In der Praxis kann genau so etwas aber darüber entscheiden, ob Google deine Produktpreise, Bewertungssterne, FAQ-Angaben oder Rezeptdaten sauber versteht – oder ob ein Teil deiner Auszeichnung still und leise ins Leere läuft.
Der Kern ist: Google liest JSON-LD für strukturierte Daten jetzt näher am eigentlichen JSON-Standard. Früher wurden bestimmte doppelt maskierte HTML-Zeichen offenbar großzügiger behandelt oder automatisch „gerettet“. Diese Fehlertoleranz wird nun reduziert. Google führt beim Auslesen von JSON-LD nur noch einen einzigen Durchlauf beim HTML-Unescaping aus. Alles, was danach noch falsch oder übertrieben maskiert ist, bleibt eben so stehen. Und genau da kann es unangenehm werden, wenn dein System HTML-Entities mehrfach verpackt.
Aus meiner Erfahrung ist das eine dieser Änderungen, die vor allem dort auffallen, wo strukturierte Daten nicht direkt von Entwicklern gepflegt werden, sondern irgendwo durch Templates, Plugins, Shop-Systeme, CMS-Felder oder Übersetzungslogik laufen. Da sitzt dann niemand da und schreibt bewusst falsches JSON. Es passiert eher nebenbei. Ein Ampersand im Produktnamen, ein Häkchen in einer FAQ-Antwort, Sonderzeichen aus einem Editor – und plötzlich kommt aus einer eigentlich simplen Information eine doppelt escapte Zeichenfolge heraus.
Was sich bei JSON-LD technisch geändert hat
Google verwendet JSON-LD, also Skripte mit type="application/ld+json", um strukturierte Daten auf Webseiten auszulesen. Darüber teilst du Suchmaschinen zusätzliche Informationen mit, die nicht nur sichtbarer Text sind, sondern maschinenlesbare Bedeutungen tragen. Ein Preis ist dann nicht einfach „19,99 €“ irgendwo im Fließtext, sondern ein definierter Wert in einem Produkt-Schema. Eine Bewertung ist nicht nur ein Satz wie „unsere Kunden lieben das Produkt“, sondern eine strukturierte Angabe mit Sternebewertung, Anzahl der Reviews und zugehörigem Produkt.
Solche Daten können Google helfen, sogenannte Rich Results zu erzeugen. Also Suchergebnisse mit zusätzlichen Elementen: Sterne, Preise, Verfügbarkeit, Rezeptzeiten, Zutaten, FAQ-Auszüge oder andere sichtbare Erweiterungen. Natürlich garantiert strukturierte Auszeichnung allein nie, dass diese Darstellung auch erscheint. Aber ohne sauber lesbare strukturierte Daten wird es deutlich schwieriger.
Die Änderung betrifft nun nicht JSON-LD als Konzept, sondern die Art, wie Google bestimmte Zeichen in diesen JSON-LD-Blöcken verarbeitet. Bisher war Googles Verarbeitung offenbar toleranter gegenüber doppelt maskierten HTML-Entities. Praktisch bedeutet das: Wenn ein Zeichen wie ein kaufmännisches Und oder ein Häkchen in einer übermäßig verschachtelten Form im JSON-LD stand, konnte Google das unter Umständen trotzdem noch richtig interpretieren.
Jetzt richtet sich Google stärker nach dem, was im JSON-Standard sauber definiert ist. Besonders relevant ist dabei der Umgang mit Zeichenketten und Escape-Sequenzen. JSON hat eigene Regeln. HTML hat ebenfalls eigene Regeln. Und wenn beides ineinanderläuft, wird es schnell unübersichtlich. Gerade in JSON-LD, das als Script im HTML-Dokument steht, treffen diese Welten zwangsläufig aufeinander.
Die wichtige Aussage ist: Google macht beim HTML-Unescaping nur noch einen Durchlauf. Es wird also nicht mehrfach hintereinander versucht, aus verschachtelten Entities doch noch das ursprünglich gemeinte Zeichen herauszuholen. Doppelt escapte Konstruktionen werden nicht mehr weiter „aufgerollt“.
Ein einfaches Beispiel: Wenn du eigentlich ein & im Text meinst, kann dieses Zeichen je nach Kontext unterschiedlich dargestellt werden. In HTML begegnet dir häufig &, um ein sichtbares kaufmännisches Und zu repräsentieren. In JSON wiederum gelten andere Escape-Regeln, etwa mit Unicode-Sequenzen wie \u0026. Problematisch wird es, wenn Systeme daraus noch einmal eine HTML-Entity machen, also eine Art Escape auf dem Escape erzeugen. Dann entsteht etwas, das für Menschen manchmal noch halbwegs nachvollziehbar ist, für einen standardkonformen Parser aber nicht mehr das, was du beabsichtigt hast.
Warum doppelt maskierte Zeichen plötzlich riskant werden
Das Wort „doppelt maskiert“ klingt abstrakt, aber das Problem ist ziemlich bodenständig. Stell dir vor, du hast einen Produktnamen wie „Kaffee & Tee Set“. In deinem Shop-Backend steht das korrekt. Dann läuft dieser Name durch ein Template. Das Template schützt HTML-Sonderzeichen und macht aus dem & vielleicht &. Danach wird derselbe Wert noch einmal durch eine Funktion geschickt, die erneut escaped. Und schon kann aus einer sauberen Eingabe eine schwer verdauliche Zeichenkette werden.
Ähnlich kann es bei Zeichen wie Häkchen, Sonderzeichen, Symbolen oder numerischen HTML-Entities passieren. Wenn ein System zum Beispiel ein Häkchen als numerische Entity ausgibt und diese Entity anschließend erneut escaped wird, steht im JSON-LD nicht mehr das klar gemeinte Zeichen, sondern eine Zeichenfolge, die nur durch mehrfaches Entpacken wieder sinnvoll wäre.
Früher konnte Google manches davon offenbar ausgleichen. Das war bequem, aber ehrlich gesagt auch ein bisschen gefährlich. Denn wenn ein externer Parser deine Fehler still korrigiert, merkst du nicht, dass dein eigener Code unsauber ist. Das geht so lange gut, bis die Fehlertoleranz verschwindet. Genau so eine Situation haben wir hier.
Du solltest dich nicht darauf verlassen, dass Google fehlerhafte strukturierte Daten repariert. Das ist vermutlich die wichtigste Lehre aus dieser Änderung. Strukturierte Daten sind keine lockere Textempfehlung, sondern Code. Und Code sollte in dem Format vorliegen, das der jeweilige Standard erwartet.
Manchmal sehe ich in Projekten, dass JSON-LD zwar im Rich-Results-Test halbwegs ordentlich aussieht, aber im Quellcode selbst schon merkwürdige Spuren trägt. Da stehen dann Entities, die aus CMS-Feldern kommen, HTML-Fragmente in Beschreibungen, kopierte Sonderzeichen aus Word-Dokumenten oder übersetzte Inhalte mit seltsamen Encodings. Solange alles grün angezeigt wird, fasst niemand es an. Verständlich. Aber genau solche Randfälle können bei einer strikteren Verarbeitung auffallen.
Besonders betroffen sind aus meiner Sicht Seiten, bei denen strukturierte Daten automatisiert erzeugt werden. Also Shops mit vielen Produktvarianten, Rezeptportale, Bewertungsplattformen, Jobbörsen, Verzeichnisse oder Websites mit großen Mengen dynamischer Inhalte. Dort entstehen JSON-LD-Blöcke selten händisch. Sie werden aus Datenbanken, Editorfeldern, API-Antworten oder Plugin-Ausgaben zusammengesetzt. Und jede zusätzliche Verarbeitungsstufe ist eine mögliche Stelle, an der Escape-Logik doppelt angewendet wird.
Das Gemeine daran: Du siehst den Fehler nicht unbedingt im sichtbaren Frontend. Die Produktseite kann ganz normal aussehen. Der Produktname wird korrekt angezeigt, die Beschreibung ebenfalls. Nur im JSON-LD-Block steht ein Wert, der für Google nicht mehr sauber interpretierbar ist. Und weil strukturierte Daten im Alltag oft nicht regelmäßig kontrolliert werden, bleibt so etwas schnell eine Weile unentdeckt.
Der Unterschied zwischen HTML-Escaping und JSON-Escaping
Hier lohnt sich ein kurzer, etwas technischer Einschub. Nicht zu akademisch, aber wichtig. HTML-Escaping und JSON-Escaping verfolgen ähnliche Ziele, funktionieren aber nicht identisch.
HTML-Escaping schützt Zeichen, die im HTML-Kontext eine besondere Bedeutung haben. Ein < könnte beispielsweise als Start eines HTML-Tags verstanden werden, ein & als Beginn einer Entity. Deshalb werden solche Zeichen in HTML oft als Entities geschrieben.
JSON-Escaping dagegen schützt Zeichen innerhalb von JSON-Zeichenketten. Dort musst du zum Beispiel Anführungszeichen innerhalb eines Strings korrekt escapen, damit sie nicht das Ende der Zeichenkette markieren. Auch Backslashes, Steuerzeichen und bestimmte Unicode-Darstellungen spielen eine Rolle. Der JSON-Standard definiert ziemlich genau, was gültig ist und was nicht.
JSON-LD sitzt nun innerhalb eines HTML-Dokuments, aber der Inhalt des Script-Tags ist JSON. Das führt manchmal zu Missverständnissen. Nur weil der JSON-LD-Block im HTML steht, heißt das nicht, dass du darin beliebig HTML-Entities stapeln solltest. Der Inhalt muss am Ende gültiges JSON sein. Und genau darauf achtet Google jetzt offenbar konsequenter.
Wenn du ein kaufmännisches Und sicher darstellen willst, ist eine Unicode-Escape-Sequenz wie \u0026 ein sauberer Weg. Auch normales korrektes JSON-Encoding kann ausreichen, je nach konkretem Zeichen und Kontext. Entscheidend ist nicht, dass du möglichst viel maskierst, sondern dass du richtig maskierst.
Das ist übrigens ein Klassiker in Webprojekten: Aus Sicherheitsgründen wird viel escaped, was grundsätzlich gut ist. Aber Escaping muss kontextabhängig sein. Ein Wert, der in HTML ausgegeben wird, braucht andere Behandlung als ein Wert, der in JavaScript, JSON, einer URL oder einem Attribut landet. Wer überall dieselbe Funktion verwendet, produziert irgendwann sonderbare Ergebnisse. Man merkt es nur oft spät.
Welche Bereiche deiner Website du jetzt prüfen solltest
Wenn du strukturierte Daten nutzt, würde ich nicht in Panik verfallen. Diese Änderung bedeutet nicht automatisch, dass plötzlich alle Rich Results verschwinden. Aber sie ist ein guter Anlass, einmal sauber durch die wichtigsten Templates zu gehen. Besonders dort, wo dynamische Inhalte im JSON-LD landen.
Prüfe zuerst die Seitentypen, bei denen strukturierte Daten wirtschaftlich wirklich etwas bringen. Bei einem Online-Shop sind das Produktseiten. Bei einem Rezeptportal sind es Rezeptseiten. Bei einem lokalen Unternehmen können es LocalBusiness-Daten sein. Bei redaktionellen Websites vielleicht Article- oder FAQ-Strukturen, sofern sie genutzt werden. Du musst nicht jede einzelne Unterseite händisch kontrollieren, aber du solltest pro Template mehrere reale Beispiele anschauen – gerade solche mit Sonderzeichen.
Aus meiner Erfahrung findet man Probleme nicht auf der saubersten Beispielseite mit dem Produkt „Testprodukt 123“. Man findet sie bei Produkten mit Markennamen, Sonderzeichen, Schrägstrichen, Klammern, Anführungszeichen, Währungszeichen oder Symbolen. Also bei echten Daten. Nimm Seiten, die ein & im Namen haben. Nimm Beschreibungen mit Anführungszeichen. Nimm FAQ-Antworten, in denen Häkchen, Gedankenstriche oder fremdsprachige Zeichen vorkommen. Genau dort wird es spannend.
Der zweite Blick sollte deinen Plugins oder Modulen gelten. Viele Websites erzeugen JSON-LD nicht selbst, sondern verlassen sich auf SEO-Plugins, Shop-Erweiterungen oder Theme-Funktionen. Das ist nicht per se schlecht. Gute Plugins machen hier solide Arbeit. Aber wenn dein Setup Werte mehrfach anfasst – etwa erst im Shop-System, dann im SEO-Plugin, dann im Theme – kann trotzdem doppelte Maskierung entstehen. Manchmal liegt der Fehler nicht im Plugin allein, sondern in der Kombination.
Der dritte Bereich sind eigene Anpassungen. Wenn ein Entwickler irgendwann „kurz“ ein Feld ins Schema ergänzt hat, vielleicht mit einer selbst geschriebenen Escape-Funktion, lohnt sich ein genauer Blick. Gerade solche kleinen Sonderlösungen bleiben jahrelang liegen. Niemand traut sich ran, weil sie funktionieren. Bis ein Parser strenger wird.
Wie du typische Fehler erkennst
Ein sichtbares Warnzeichen sind Zeichenfolgen, die im JSON-LD merkwürdig „zu technisch“ aussehen. Wenn du im Quellcode nicht nur ein normales Sonderzeichen oder eine saubere JSON-Escape-Sequenz siehst, sondern verschachtelte HTML-Entities, solltest du genauer hinschauen.
Problematisch können zum Beispiel Werte sein, die so aussehen, als seien sie bereits escaped gewesen und anschließend erneut escaped worden. Ein einfaches & wird dann nicht mehr sauber als Zeichen behandelt, sondern als Textfragment einer Entity. Bei numerischen Entities ist es ähnlich. Wenn du statt eines Zeichens eine Zeichenfolge siehst, die erst nach mehrfacher Umwandlung Sinn ergibt, ist das verdächtig.
Ich würde dabei nicht nur auf Validierungstools schauen, sondern auch den rohen HTML-Quelltext öffnen. Tools sind hilfreich, keine Frage. Aber im Quelltext siehst du oft besser, was tatsächlich ausgeliefert wird. Wichtig ist: Nicht der DOM-Zustand nach irgendwelchem JavaScript ist immer entscheidend, sondern das, was Googlebot beim Crawlen und Rendern am Ende auswerten kann. Je simpler die JSON-LD-Ausgabe serverseitig korrekt ist, desto weniger Ärger hast du.
Wenn du bei der Prüfung feststellst, dass deine strukturierten Daten ungültiges JSON enthalten, ist das natürlich ein klarer Fehler. Schwieriger sind Fälle, in denen das JSON formal noch gültig ist, der Inhalt aber semantisch falsch oder unsauber maskiert wirkt. Genau dort kann Googles Änderung relevant werden. Der Parser akzeptiert vielleicht die Struktur, interpretiert den Wert aber nicht so, wie du ihn gemeint hast.
Was du an deinem Code ändern solltest
Die saubere Lösung lautet: Erzeuge JSON-LD als korrektes JSON und verwende dafür die passenden JSON-Escape-Regeln. Klingt banal, ist aber die halbe Miete. Wenn du in PHP, JavaScript, Python, Ruby oder einer anderen Sprache arbeitest, solltest du nach Möglichkeit die offiziellen JSON-Encoding-Funktionen verwenden, statt Strings von Hand zusammenzubauen.
Von Hand gebautes JSON ist eine Fehlerquelle, die ich in Projekten immer wieder sehe. Es sieht zunächst harmlos aus: ein paar geschweifte Klammern, ein paar Anführungszeichen, Variablen dazwischen. Aber sobald ein Wert ein Anführungszeichen, einen Zeilenumbruch oder ein Sonderzeichen enthält, bricht dir das Konstrukt weg oder wird falsch escaped. Saubere JSON-Encoder lösen genau dieses Problem.
Wenn du zum Beispiel Produktdaten in ein Schema schreibst, sollten Name, Beschreibung, Marke, SKU, Preis und Verfügbarkeit aus strukturierten Datenquellen kommen und dann einmal korrekt als JSON serialisiert werden. Nicht erst HTML-escapen, dann in JSON kleben, dann noch einmal durch eine Template-Escape-Funktion jagen. Das ist der Weg ins Chaos.
Escaping gehört immer zum Ausgabekontext. Für HTML brauchst du HTML-Escaping. Für JSON brauchst du JSON-Escaping. Für JSON innerhalb eines Script-Tags musst du auf gültiges JSON achten und gegebenenfalls bestimmte Zeichen zusätzlich sicher darstellen. Aber du solltest nicht pauschal HTML-Entities in JSON-Daten stapeln.
Wenn du Unicode-Escape-Sequenzen verwendest, etwa \u0026 für ein kaufmännisches Und, ist das im JSON-Kontext eine standardisierte und verständliche Darstellung. Wichtig ist, dass daraus nicht durch weitere Verarbeitung wieder eine HTML-Entity-Kette wird. Ein einzelner sauberer Escape ist gut. Mehrfaches Escaping ist in diesem Fall nicht „sicherer“, sondern eher riskanter.
Bei CMS-Systemen lohnt sich auch ein Blick auf Editorfelder. Manche WYSIWYG-Editoren speichern Inhalte bereits mit HTML-Entities. Wenn du diese Werte dann ungeprüft in JSON-LD übernimmst, schleppst du HTML-Kontext in JSON-Kontext. Besser ist es, den eigentlichen Textwert zu verwenden, HTML zu entfernen oder sauber zu normalisieren und erst danach JSON-konform zu serialisieren.
Ein pragmatischer Prüfablauf
Ich würde das Ganze recht praktisch angehen. Zuerst suchst du dir die wichtigsten Templates heraus. Dann öffnest du mehrere reale URLs pro Template und kopierst den JSON-LD-Block heraus. Danach prüfst du, ob der Block gültiges JSON ist und ob auffällige Entities enthalten sind. Anschließend testest du die Seite mit einem Tool für strukturierte Daten.
Der entscheidende Schritt ist aber die Ursachenanalyse. Wenn du doppelt escapte Werte findest, entferne nicht einfach nur die Symptome im fertigen Output. Such die Stelle, an der der Wert zum zweiten Mal behandelt wird. Oft liegt das Problem in einer Template-Ebene, die automatisch escaped, obwohl der JSON-Encoder das bereits erledigt hat. Oder ein Plugin bekommt schon vor-escapte Daten geliefert und escaped sie erneut.
In größeren Projekten würde ich zusätzlich automatisierte Tests einbauen. Nicht übertrieben kompliziert. Schon ein Test, der JSON-LD aus Beispielseiten extrahiert und gegen einen JSON-Parser laufen lässt, kann viel verhindern. Dazu ein paar Testwerte mit Ampersand, Anführungszeichen, Unicode-Zeichen und numerischen Entities. Das klingt trocken, spart aber später Diskussionen, wenn Rich Results plötzlich schwanken.
Warum diese Änderung auch ein Signal ist
Für mich ist diese Anpassung mehr als nur eine Parser-Änderung. Sie zeigt ein Muster: Google erwartet zunehmend, dass technische SEO-Grundlagen sauber umgesetzt werden. Nicht perfekt im Sinne von akademisch schön, aber standardkonform. Die Zeiten, in denen Suchmaschinen jeden krummen Markup-Fehler großzügig geradebiegen, werden nicht unbedingt zurückkommen.
Das ist eigentlich fair. Ein Standard wie JSON ist klar dokumentiert. Wenn Tools, Plugins und Entwickler sich daran halten, wird die Verarbeitung stabiler. Wenn aber jede Plattform ihre eigenen Fehler automatisch korrigiert, entsteht ein grauer Bereich. Heute funktioniert es zufällig, morgen nicht mehr.
Natürlich kann man sagen: Google hätte weiterhin tolerant bleiben können. Und ja, aus Sicht mancher Website-Betreiber wäre das bequemer. Aber aus technischer Sicht verstehe ich den Schritt. Ein Parser, der sich stärker an Standards hält, ist berechenbarer. Er zwingt allerdings alle Beteiligten dazu, ihre Ausgabe ernst zu nehmen.
Für dich heißt das: Strukturierte Daten sollten nicht als SEO-Deko betrachtet werden, die man einmal installiert und dann vergisst. Sie sind Teil deiner technischen Infrastruktur. Wenn du damit Produktinformationen, Bewertungen, FAQs oder Rezepte an Google übermittelst, sollten diese Daten genauso gepflegt werden wie deine Canonicals, hreflang-Tags, Statuscodes oder internen Links.
Am Ende ist die Änderung nicht dramatisch, wenn dein JSON-LD sauber ist. Dann passiert wahrscheinlich gar nichts. Wenn dein System aber bisher davon gelebt hat, dass Google doppelt maskierte Zeichen still repariert, solltest du jetzt handeln. Nicht irgendwann, wenn Rankings oder Darstellungen bereits auffällig werden, sondern vorher.
Mein persönlicher Rat: Schau dir nicht nur die Validierung an, sondern die Datenpipeline. Wo entstehen die Werte? Wo werden sie verändert? Wo werden sie escaped? Und wo landen sie schließlich im JSON-LD? Gerade diese Kette erzählt oft mehr als ein einzelner Test. Wenn du dort Ordnung hineinbringst, ist diese Google-Änderung am Ende keine Bedrohung, sondern ein guter Anlass, deine strukturierten Daten robuster zu machen.
Die Kurzfassung: Google verarbeitet JSON-LD beim HTML-Unescaping strenger und nur noch einmal. Doppelt escapte Entities werden nicht mehr automatisch weiter entpackt. Wenn du strukturierte Daten nutzt, solltest du sicherstellen, dass dein JSON-LD standardkonform ist, sauber escaped wird und keine mehrfach maskierten HTML-Entities enthält. Besonders wichtig ist das bei dynamisch erzeugten Daten aus Shops, CMS-Systemen, Plugins und Templates. Wer hier sauber arbeitet, hat wenig zu befürchten. Wer sich bisher auf Googles Fehlertoleranz verlassen hat, sollte jetzt nachbessern.
