Kort fortalt
Google ændrede den 21. august 2026 sin JSON-LD-udtrækning, så Googlebot nu kun kører ét gennemløb af HTML-unescaping. Dobbelt-escapede entiteter som & og ✔ bliver ikke længere rullet helt ud, og værdien ender som synlig tekst i stedet for tegnet. Gary Illyes henviste samtidig til RFC 8259, afsnit 7: JSON har sine egne escapes, og \u0026 er den rigtige form. Rich Results Test består stadig siden, fordi den kontrollerer struktur og ikke tegnindhold — så fejlen udløser ingen advarsel noget sted. Ramte felter er typisk produktnavne, overskrifter og brødkrumme-labels med ampersand eller danske tegn, og skaden kommer fra to lag skabelon, ikke fra en tastefejl.
Dine strukturerede data er ikke gået i stykker — Googles læser af dem er blevet strengere, og den fejl, den nu efterlader, kan ingen af de gængse tjek se. Fra 21. august 2026 unescaper Googlebot kun ét lag HTML i JSON-LD. Var din værdi escapet to gange, får Google nu Møller & Sønner, hvor den før fik Møller & Sønner. Markuppen er stadig gyldig; det er indholdet i den, der er forkert.
Hvad Google konkret ændrede
Den 21. august 2026 meldte Google ud, at de har bragt deres JSON-LD-parser i overensstemmelse med JSON-standarderne og nu kun anvender ét enkelt gennemløb af HTML-unescaping ved udtrækningen. Gary Illyes henviste samtidig til RFC 8259, afsnit 7 — stedet hvor JSON definerer sine egne escapes. Meldingen er refereret hos Search Engine Roundtable og Search Engine Watch.
Regnestykket er kort. En værdi, der står som &, bliver stadig til &: ét lag, ét gennemløb. En værdi, der står som &, blev tidligere rullet helt ud til &. Nu stopper Googlebot efter første lag og lander på & — fem tegn tekst, hvor der skulle stå ét.
Det underliggende problem er ældre end ændringen. Indholdet i et <script type="application/ld+json">-element er efter HTML-specifikationen rå tekst: HTML-parseren afkoder ikke entiteter derinde. HTML-escaping har altså aldrig hørt hjemme i JSON-LD. Google kompenserede for det alligevel. Fra 21. august kompenserer den præcis én gang.
Sådan opstår dobbelt-escaping
Næsten aldrig som en tastefejl. Det sker, når to lag i kæden hver især gør det rigtige uden at vide, at det andet lag også gjorde det: CMS'et gemmer feltet HTML-escapet, fordi den samme værdi også skal kunne stå i brødteksten, og skabelonen escaper så en gang til på vej ud i ld+json-blokken. Ingen af de to lag er forkerte alene.
Danske sider har rigeligt at falde over: ampersand i firmanavne, gradtegn i produktspecifikationer, flueben i featurelister, og æ, ø og å fra ældre eksportfiltre, der stadig skriver æ i stedet for tegnet. Det er præcis de felter, der ryger i en produktoverskrift eller en brødkrumme.
Derfor siger validatoren stadig god for det
Rich Results Test og rapporterne i Search Console kontrollerer struktur: er de påkrævede felter til stede, har de den rigtige type, peger referencerne rigtigt. En streng med teksten Møller & Sønner er en fuldstændig gyldig streng. Der er ikke noget at flage.
Det er kernen i hele sagen, og det er også grunden til, at den her fejltype kan stå i månedsvis. Hele QA-praksissen omkring schema markup hviler på bestået eller ikke bestået. Men et validt skema er ikke det samme som et rigtigt skema. Den eneste brugbare aflæsning er de parsede værdier, som Rich Results Test viser længere nede på siden — og dem er der stort set ingen, der ruller ned til, når feltet øverst er grønt.
Timingen hjalp ikke. Ændringen landede i samme uge, som Googles spam-opdatering fra august 2026 var færdig med at rulle ud (18.-21. august). Alt, hvad der rykkede sig i den uge, havde en oplagt forklaring, og den hed ikke escaping.
Tjek det i denne rækkefølge
- Hent den renderede HTML for de 20-30 sider, der betyder mest kommercielt, og søg inde i
ld+json-blokkene efter&amp;,&#og&quot;. Et hit er en dobbelt-escapet værdi. En crawl-eksport med rå HTML dur lige så godt som en scriptet gennemgang. - Kør de sider gennem Rich Results Test og læs værdierne, ikke statussen. Står entiteten stadig som tekst i det parsede output, er det bekræftet.
- Find laget. Følg værdien fra databasefeltet gennem serialiseringen til skabelonen. Escaper begge, er det næsten altid skabelonen, der skal holde op — den værdi skal ud i et JSON-dokument, ikke i HTML.
- Lad JSON-serialiseringen om escapingen. Den håndterer selv anførselstegn, backslash og styretegn. Skal et tegn escapes eksplicit, er
\u0026-formen den, RFC 8259 beskriver — ikke en HTML-entitet. - Prioritér efter, hvad der bliver vist. Produktnavne og priser, artikeloverskrifter, brødkrumme-labels og forfatternavne står i resultatet. Et forkert tegn i en intern reference koster ingenting; et forkert tegn i et produktnavn står i søgeresultatet.
På et almindeligt site er det en formiddags arbejde, og resultatet er binært: enten er der entiteter i de parsede værdier, eller også er der ikke. Det er sjældent, at et teknisk tjek er så billigt at afvise.
Fejlen ligger nu på den anden side af kablet
Tre gange på en måned har Google ændret noget hos sig selv, uden at en eneste byte på dine sider har flyttet sig: crawlerne begyndte at sende PUT og DELETE (bekræftet 7. august), resultatlinkene fik et redirect ind foran sig (26. august), og parseren holdt op med at rydde op efter dine skabeloner (21. august).
Overvågningen på de fleste sites peger indad: oppetid, fejllog, Core Web Vitals, indekseringsstatus. Ingen af delene ser noget af det her. Det eneste, der gør, er vanen med at læse, hvad Google faktisk har trukket ud af siden — i stedet for at nøjes med, at den bestod.