Google JSON-LD: dubbele escapes werken niet meer

Op dinsdag staan de sterretjes nog onder je productpagina in Google. Op woensdag niet meer. Je hebt niets gedeployed, je plugin is niet bijgewerkt, en Search Console meldt geen enkele fout. Dat is het vervelendste soort kapot.

Google veranderde deze week hoe zijn crawler JSON-LD uit je pagina haalt. "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", schreef Google op LinkedIn. In gewoon Nederlands: de parser doet nog één ronde HTML-unescaping en niet meer twee. Dubbel ge-escapete tekens worden dus niet langer stilletjes rechtgetrokken.

Eén ronde unescaping, en je dubbele ampersand is stuk

Google noemt de voorbeelden zelf: dingen als & of ✔ worden niet meer uitgerold. Stond er in je JSON-LD een merknaam als Jansen & Zn, of een vinkje als HTML-entiteit in een productbeschrijving, dan las Google dat tot vorige week als een & en een vinkje. Nu leest hij precies de tekens die er staan. Het advies van Google is standaard JSON-escapes te gebruiken, of Unicode-escapes zoals \u0026.

JSON-LD is het blokje dat prijzen, voorraad, reviewsterren, recepten en FAQ's aan Google doorgeeft en dat je rich results oplevert. Breekt dat blok, dan verlies je die weergave. Je pagina blijft gewoon ranken. Hij ziet er alleen kaler uit dan die van de concurrent eronder, en dat kost je kliks zonder dat je positie verandert.

Waarom repareerde Google dit jarenlang voor ons?

De eerste reflex in SEO-land is klagen over een stille wijziging. Die reflex klopt hier niet. Google beweegt naar de standaard toe, niet ervandaan. Gary Illyes van Google wees expliciet aan waar die standaard staat: RFC 8259, sectie 7. Dat document is van 2017.

De oorzaak zit bij ons. Wij bouwen JSON-LD in templates die HTML-escaping loslaten op velden die al geëscaped waren, en dat viel jarenlang niet op omdat de parser het voor ons opruimde. Wij ook, met onze eigen sites. Een parser die je fouten repareert leert je niets, en als die reparatie wegvalt komt de rekening in één keer.

RFC 8259 sectie 7 is de hele regel

In JSON schrijf je speciale tekens met een backslash, niet met HTML-entiteiten. Een dubbele aanhaling is \", een backslash is \\, en alles wat je niet letterlijk kwijt kunt schrijf je als \u met vier hexcijfers erachter. Een ampersand is gewoon een ampersand, of \u0026 als je hem wilt ontwijken. & hoort er niet, want dat is HTML-notatie die in een JSON-veld is blijven plakken.

Pak één productpagina voordat je de volgende batch publiceert

Kies de productpagina die het meeste oplevert, bekijk de broncode en zoek in het ld+json-blok op amp; en op &#. Vind je die, dan heb je het probleem sitebreed, want een template maakt die fout nooit op één pagina. Gooi diezelfde URL daarna door Google's Rich Results Test en kijk of het item er nog geldig uitkomt. Vijf minuten per site, en je weet of dit jouw week verpest of niet.

De schade zie je pas weken later in Search Console

De rich results-rapporten in Search Console lopen achter op de crawl, dus een stijging in ongeldige items komt niet morgen binnen. Wij kijken de komende weken naar precies dat rapport op de sites met veel productschema. Wie nu zelf controleert, ziet het voordat het rapport het ziet.

Het gewone werk blijft verder hetzelfde. Zorg dat je metadata elkaar niet tegenspreekt en dat Google je pagina's vaak genoeg langsloopt. Zoek je daarnaast autoriteit voor de pagina's die het moeten doen, dan staat de catalogus klaar.