JSON-LD : Google annonce ne plus corriger les entités HTML doublement échappées

L’essentiel

• Google n’applique plus qu’une seule passe de déséchappement HTML aux blocs JSON-LD qu’il extrait.
• Les entités échappées deux fois, comme & ou ✔, ne sont plus ramenées au caractère d’origine.
• Google recommande les échappements JSON standards ou Unicode hexadécimaux, comme \u0026 pour l’esperluette.
• Gary Illyes renvoie à la section 7 de la RFC 8259, qui fixe les règles d’échappement des chaînes JSON.

Google aligne son extracteur JSON-LD sur la norme

L’annonce a été publiée sur la page LinkedIn de Google Search Central. Google y indique avoir modifié l’extraction du JSON-LD « pour mettre [son] analyseur au niveau de JSON et d’autres normes » (traduction). Il n’applique désormais qu’une seule passe de déséchappement HTML. Search Engine Roundtable a relayé l’information le 21 août 2026.

Jusqu’ici, l’extracteur réparait en silence les valeurs encodées plusieurs fois. Une esperluette devenue & puis & finissait par être relue comme une simple esperluette. Ce n’est plus le cas : selon Google, les entités doublement échappées « ne seront plus déroulées » (traduction). Ses deux exemples sont & et ✔, le second correspondant au symbole coche encodé deux fois. La consigne aux développeurs tient en une ligne : passer aux échappements JSON standards ou aux échappements Unicode hexadécimaux, du type \u0026.

Google parle d’une modification déjà faite, sans donner de date d’entrée en vigueur. Son message ne cite aucun type de résultat enrichi. Search Engine Roundtable se contente de rappeler que Google s’appuie sur le JSON-LD pour comprendre les prix, les notes d’avis ou les ingrédients d’une recette, puis les afficher en résultats enrichis. Un effet sur ces affichages n’est donc pas confirmé. Il reste plausible dès qu’un nom ou une URL est mal relu.

RFC 8259 : la référence citée par Gary Illyes

Gary Illyes, analyste chez Google, a repartagé l’annonce en rappelant que l’échappement correct en JSON est « très, très bien défini » (traduction) dans la RFC 8259, lien vers la section 7 à l’appui. Sous son message, John Mueller a répondu par une plaisanterie, sans rien ajouter sur le fond.

Pour rappel, la section 7 de la RFC 8259 n’oblige à échapper, dans une chaîne, que le guillemet, la barre oblique inverse et les caractères de contrôle (U+0000 à U+001F). Tout autre caractère peut figurer tel quel ou être écrit sous la forme \uXXXX. Les entités HTML n’existent pas dans cette norme. Pour un analyseur JSON strict, & n’est qu’une suite de cinq caractères.

Exemple avant/après : ce que la règle change sur une fiche fictive

Le tableau applique la règle annoncée à une entreprise fictive. Les deux dernières colonnes sont déduites du message de Google : ce ne sont pas des tests publiés par Google.

Valeur dans le code source	Lu par Google avant	Lu par Google désormais
« name »: « Dupont & Fils »	Dupont & Fils	Dupont & Fils (forme standard)
« name »: « Dupont \u0026 Fils »	Dupont & Fils	Dupont & Fils (échappement Unicode)
« name »: « Dupont & Fils »	Dupont & Fils	Dupont & Fils (une passe suffit)
« name »: « Dupont & Fils »	Dupont & Fils	Dupont & Fils
« description »: « Livraison offerte ✔ »	Livraison offerte, suivi du symbole coche	Livraison offerte ✔

Deux remarques. Une valeur échappée une seule fois (troisième ligne) devrait encore être relue correctement, puisqu’une passe reste appliquée. Ce n’est pas du JSON standard pour autant, et Google ne s’engage pas à garder cette tolérance. Surtout, le JSON reste syntaxiquement valide dans les cinq cas : un contrôle de syntaxe ne signalera rien, c’est la valeur extraite qui sera fausse. Les champs d’URL sont les plus exposés. Un paramètre écrit ?a=1&b=2 dans un champ url ou sameAs donne, après une seule passe, ?a=1&b=2, qui n’est plus l’adresse voulue.

WordPress : où chercher le double échappement

Sur WordPress, le JSON-LD vient le plus souvent de l’extension SEO (Yoast SEO, Rank Math, SEOPress) ou du thème. L’annonce de Google ne vise aucune extension, et aucune des sources consultées ne signale de problème chez l’une d’elles. Le risque tient plutôt aux ajouts maison. WordPress produit déjà des entités dans les titres : wptexturize remplace l’apostrophe par ’ et l’esperluette par &. Si un gabarit ou un extrait de code repasse ensuite la valeur dans htmlspecialchars(), qui réencode par défaut les entités existantes, avant json_encode(), le caractère se retrouve encodé deux fois. Le contrôle se fait en quatre étapes :

1. Ouvrir le code source des principaux gabarits (accueil, article, fiche produit, page contact) et chercher, dans les blocs application/ld+json, les motifs & et &#.
2. Refaire la recherche sur la version rendue avec l’inspection d’URL de la Search Console (« Tester l’URL en ligne », puis « Afficher la page testée »), pour couvrir le JSON-LD injecté en JavaScript.
3. Sur un gros site, lancer un crawl avec une recherche personnalisée sur ces mêmes motifs.
4. Contrôler en priorité les noms de produits, les auteurs, les adresses et les champs d’URL, où esperluettes et apostrophes reviennent souvent.

Ce que j’en retiens

Google n’invente pas de règle. Il arrête de réparer sans prévenir un JSON-LD mal produit. Les sites touchés seront ceux dont le thème ou un extrait de code encode deux fois, et rien ne les alertera puisque le JSON reste valide. Je lancerais la recherche de & dans les blocs JSON-LD dès maintenant, sur des extensions à jour : quelques gabarits suffisent à faire le tour d’un site WordPress classique.

Si le motif apparaît, la correction se fait à la source : décoder la valeur avec html_entity_decode(), puis la passer à wp_json_encode(), au lieu d’empiler un échappement HTML de plus. Restent ensuite à suivre les rapports d’éléments enrichis de la Search Console et l’affichage des noms de produits ou d’entreprise dans les résultats.