Googlebot og JSON-LD: ett unescape-gjennomløp

#Hva Google faktisk endret

Uttalelsen er kort og verdt å sitere i sin helhet, siden alt annet følger av én setning:

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 la til et peker på hvor korrekthet er definert: RFC 8259, JSON-spesifikasjonen. Det er ingen SEO-anbefaling, men en henvisning til en standard hver eneste JSON-parser følger.

Den praktiske følgen står like kort: dobbelt escapede entiteter som & eller ✔ rulles ikke lenger ut. Før gjorde parseren et ekstra gjennomløp og rettet det opp. Nå gjør den ett gjennomløp og sitter igjen med tekst som ikke er gyldig JSON.

La oss med en gang nevne hva som mangler i informasjonen. Det finnes ingen utrullingsdato. Det finnes ingen lenke til oppdatert Google-dokumentasjon. Kilden er et LinkedIn-innlegg, omtalt av Search Engine Roundtable 21. august 2026. Behandle det som en tilstand Google har beskrevet, ikke som en spesifikasjon du kan legge fram for en kunde.

#Hva dobbelt escaping er, og hvor det kommer fra

Ta et enkelt tilfelle: firmanavnet «Hansen & Sønn» i feltet name i en JSON-LD-blokk.

Et og-tegn alene sprenger ikke blokken, JSON krever ikke escaping av det. Alvoret starter ved anførselstegnet. Skriver malen " der \" hører hjemme, sitter du etter ett gjennomløp igjen med " og ikke et anførselstegn. Strengen lukkes aldri og blokken er ikke lenger JSON.

Hvor kommer det fra i WordPress? Nesten alltid fra dobbel behandling av samme verdi. Innhold går gjennom esc_html() ved lagring, gjennom et temafilter ved utskrift, og havner til slutt i et JSON-LD-felt som uansett ville escapet riktig selv. Hvert steg er riktig alene. Satt sammen gir de en skrivemåte som fungerte i årevis bare fordi Google rettet den opp for oss.

#Slik sjekker du ditt eget korpus på fem minutter

Den viktigste regelen: du sjekker bygget HTML, ikke malkilden. I kilden ser alt fint ut, fordi escapingen legges til ved utskrift. Har du et statisk bygg, skanner du utdatakatalogen. På klassisk WordPress henter du et utvalg adresser med wget eller curl og skanner det serveren faktisk svarte.

Selve sjekken er et drøyt dusin linjer. Hent ut hver <script type="application/ld+json">-blokk, forsøk å parse den, og let separat etter mønsteret for dobbel entitet:

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("dobbel entitet", file);
  try { JSON.parse(body); } catch (e) { report("parser ikke: " + e.message, file); }
}

To separate tester, fordi de fanger ulike ting. JSON.parse feiler på en ødelagt streng, men godtar gjerne & inne i en verdi som fortsatt er gyldig JSON og bare inneholder søppel. Entitetstesten fanger nettopp det andre tilfellet: blokken parser, og i det rike resultatet står & der et tegn skulle stått.

En tredje test er verdt å legge til: enkle HTML-entiteter i verdier. De er ingen feil, men etter endringen rulles de ut nøyaktig én gang, så resultatet kan avvike fra det du så før. Bedre å vite at de er der.

#Vår måling: 68 055 blokker, null feil

Vi kjørte denne skanningen over vårt eget korpus 30. august 2026, mot et nybygget produksjonsresultat.

Null i alle tre kategorier. Vi skriver ikke det som skryt, men som informasjon om hva resultatet betyr og ikke betyr. Stacken vår lager strukturerte data fra frontmatter gjennom Astro-komponenter og setter dem inn med mønsteret set:html={JSON.stringify(...)}. JSON.stringify gir per definisjon gyldig JSON, og set:html legger ikke til egen HTML-escaping. Sagt annerledes: vi fikk ikke null fordi vi var forsiktige, men fordi akkurat det mønsteret ikke har noen måte å lage dobbel escaping på.

Det er viktigere enn tallet i seg selv. Bygger stacken din JSON-LD ved å skjøte strenger i malen, eller gjennom en plugin som limer et innholdsfelt inn i ferdig JSON, er risikoen reell og resultatet ditt blir et annet. Mål ditt eget, ikke kopier vårt.

#Hvor det ryker oftest i WordPress

Fra revisjonene vi gjør hos kunder går tre kilder igjen.

Den første er en SEO-plugin som fyller description fra et felt som allerede har vært gjennom wp_kses eller esc_attr. Den ryker som regel på apostrof og anførselstegn, og i norske tekster kommer i tillegg de typografiske anførselstegnene som mange redaksjonssystemer setter automatisk.

Den andre er en håndskrevet JSON-LD-blokk limt inn i header.php eller i temainnstillingene, der verdier settes inn med echo uten wp_json_encode. Det er den vanlige varianten i skreddersydde temaer bygget for noen år siden, og den vanskeligste å finne, fordi den ikke dukker opp i noe plugin-grensesnitt.

Den tredje er en sidebygger som lagrer innhold med HTML-entiteter allerede i databasen. Da får selv en korrekt skrevet JSON-LD-generator inn tekst med & og koder den pliktoppfyllende en gang til.

Fellesnevneren er alltid den samme: en verdi escapes to ganger, én gang for HTML og én gang for JSON, av to lag som ikke vet om hverandre.

#Slik koder du det riktig

Regelen er entydig, fordi det finnes en standard for den. Inne i en JSON-verdi escaper du på JSON-vis, ikke på HTML-vis.

I PHP betyr det wp_json_encode() over hele strukturen, aldri strenger skjøtet for hånd. I JavaScript JSON.stringify(). I en Astro-mal mønsteret vi bruker selv:

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

Trenger du virkelig et tegn som kan lukke skriptblokken for tidlig, bruk en universell escape. & og < er trygge i enhver JSON-parser og krever ingen HTML-kunnskap hos den som leser.

Det du ikke skal gjøre: aldri legg en HTML-entitet inn i en JSON-verdi i håp om at noen ruller den ut. I årevis var den noen Google. Fra nå ruller Google ut nøyaktig én gang, og enhver annen konsument av dataene dine, fra Bing til en KI-assistent, har aldri hatt noen plikt til det.

#En engangsrevisjon holder ikke, lag en port av den

Dette er delen som oftest hoppes over. Strukturerte data er ikke tekst du skriver én gang. Mal, plugin eller integrasjon lager dem, og enhver oppdatering kan føre escapingen tilbake. En revisjon kjørt i dag sier noe om dagens bygg og ingenting mer.

Hos oss ble skanningen til en port som kjører etter bygget. Den leser utdatakatalogen, teller blokker, forsøker å parse hver enkelt og feiler bare ved et reelt problem, altså en blokk som ikke parser eller en dobbel entitet. Mangler utdatakatalogen, avslutter den med null, slik at det ikke oppstår falskt rødt i et miljø der ingen har bygget ennå.

Tre detaljer avgjør om en slik port er verdt noe. For det første må den lese artefaktet og ikke kilden, siden kilden ikke beviser noe om escaping. For det andre må den telle blokker og skrive ut tallet, slik at noen legger merke til at det faller fra sekstiåtte tusen til to hundre fordi en integrasjon sluttet å lage dem. For det tredje må den skille feil fra opplysning: enkle HTML-entiteter rapporteres, men velter ikke bygget, for det er ingen driftsstans, bare noe du bør vite om.

#Hva du gjør når skanningen finner noe

En skanning gir en filliste, ikke en diagnose. Før du retter noe, finn ut hvilket lag som lager skrivemåten, ellers kommer feilen tilbake ved neste oppdatering.

Ta én adresse fra listen og se på det rå serversvaret, for eksempel med curl -s ADRESSE | grep -A5 "application/ld+json". Sjekk om den ødelagte verdien kommer fra innleggstittelen, SEO-beskrivelsen eller et egendefinert felt. Det peker på laget raskere enn å lese kode.

Deretter avgjør du etter kilde:

1. Kommer verdien fra en SEO-plugin, sjekk om to plugins lager samme schema-type. En dobbel generator er en vanligere årsak til rare verdier enn en feil i én av dem alene.
2. Ligger blokken i temaet, skriv den om til wp_json_encode() over hele arrayet. Manuell strengskjøting er den eneste ekte feilen her, og den lar seg ikke fikse halvveis.
3. Sitter entitetene allerede i databasen fordi en sidebygger la dem der, ikke reparer det i generatoren. Dekod verdien én gang før den sendes til JSON-koderen, for eksempel med html_entity_decode() med quote-flagg og eksplisitt UTF-8.

Den klassiske feilen ser slik ut:

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

Riktig ser slik ut:

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

Forskjellen ligger ikke i antall tegn, men i hvem som eier escapingen. I den første varianten gjør en HTML-funksjon jobben i en sammenheng som ikke er HTML. I den andre gjør en JSON-koder den i en JSON-sammenheng.

Etter rettingen skanner du et nytt bygg, ikke det gamle artefaktet. Det høres opplagt ut, og halvparten av alle meldinger om «fikset, men fortsatt ødelagt» er en skanning av en foreldet utdatakatalog.

#Hva du faktisk taper på å ignorere det

Tapt schema gjør ikke vondt med en gang, og det er det verste med det. Det kommer ikke noe posisjonsfall over natten, det kommer en gradvis forsvinning av det som løftet resultatet: stjerner fra vurderinger, produktdata, en FAQ-liste, brødsmuler. Effekten ser du i klikkraten, ikke i posisjonen, og klikkraten faller sakte og lar seg lett tilskrive noe annet.

Den andre mottakeren av disse dataene er nyere og mindre tilgivende. Svarmotorer leser strukturerte data fordi det er den billigste måten å fastslå hva en side handler om uten å tolke hele teksten. Hos oss er agenttrafikk nå målbar og ikke marginal: i størrelsesorden hundre besøk i døgnet, to tredeler av dem gjennom vårt eget MCP-endepunkt. Disse systemene har ingen grunn til å reparere andres escaping. Google gjorde det i årevis av høflighet mot nettet slik det forelå. En ny konsument av dataene dine har aldri hatt den vanen.

Det tredje laget er Search Console, og her hører det med å si hva du ikke får vite. Rapportene om rike resultater viser en nedgang i gyldige elementer, men de sier ikke «denne blokken parset ikke på grunn av en dobbel entitet». Du ser at elementer mangler, og må finne ut hvorfor selv. Derfor er skanningen på din side verdt minuttene: den gir årsaken og ikke bare symptomet.

#Det vi ikke vet, og hva som likevel bør gjøres

Vi kjenner ingen utrullingsdato. Vi vet ikke om endringen rammer alle schema-typer likt, eller om Search Console i det hele tatt rapporterer en tapt entitet i stedet for bare å slutte å vise det rike resultatet. Det finnes ingen oppdatert dokumentasjon å henvise en kunde til. Det er reelle hull, og det er bedre å si det enn å gi et LinkedIn-innlegg rang som spesifikasjon.

Tross hullene er den operative beslutningen enkel og avhenger av ingen av de manglende opplysningene. Gyldig JSON var gyldig også den gangen Google rettet feil på dine vegne. Skann det bygde HTML-et ditt, reparer det som ikke parser, bytt HTML-entiteter i verdier mot JSON-escapes, og forankre testen i prosessen så den ikke kommer tilbake. Blir resultatet null, slik det ble hos oss, er også det et resultat: du vet at generatoren din ikke har noen måte å lage denne feilen på, og slipper å tenke på det ved hver plugin-oppdatering.

Den største risikoen i denne historien ligger ikke i endringen selv, men i at den er stille. Det kommer ingen varsling. Det rike resultatet slutter bare å vises, og tre måneder senere viser en rapport en synlighetsnedgang uten åpenbar årsak. Fem minutter med skanning i dag er billigere enn den granskingen.