Depuis le 21 août 2026, auditer vos données structurées JSON-LD consiste à traquer, avec le Rich Results Test de Google et un validateur JSON strict, les entités HTML échappées deux fois que Googlebot ne corrige plus tout seul. C’est ce qu’a annoncé Google Search Central sur LinkedIn ce jour-là : le parseur qui extrait le JSON-LD de vos pages n’applique plus qu’une seule passe de déséchappement HTML, contre plusieurs auparavant. Ce changement rejoint d’autres chantiers de fond du SEO technique sur WordPress, sauf qu’ici, l’erreur ne se voit nulle part ailleurs que dans un outil de test.
Table des matières
Ce qui change concrètement dans le parseur de Google
Le JSON-LD est le format que la plupart des plugins SEO (Yoast, RankMath) et des thèmes WordPress utilisent pour injecter les données structurées dans un bloc <script type="application/ld+json">. Pour reconstituer ce JSON, Googlebot devait jusqu’ici défaire plusieurs couches d’échappement HTML successives, une tolérance qui masquait des erreurs de génération en amont. Avec la seule passe désormais appliquée, une entité échappée une fois, comme & pour un simple &, reste résolue normalement. Une entité échappée deux fois, comme &amp; ou &#10004;, s’arrête à la première passe : elle reste littérale dans la valeur JSON, ce qui peut invalider tout le bloc et faire perdre l’éligibilité aux rich results concernés.
Gary Illyes, de Google, a renvoyé vers un texte précis pour justifier le changement : la RFC 8259, section 7, qui définit l’échappement JSON standard. Elle n’impose d’échapper que trois choses : le guillemet, l’antislash, et les caractères de contrôle U+0000 à U+001F. Un « & » nu n’a jamais eu besoin d’échappement en JSON. Sa recommandation, reprise par plusieurs couvertures spécialisées dont Search Engine Roundtable, tient en une ligne : en cas de doute sur un caractère spécial, utiliser l’échappement Unicode hexadécimal (\u0026 pour &) plutôt que de laisser un CMS ré-échapper du HTML déjà échappé.
Pourquoi le double échappement s’installe sans que vous l’ayez voulu
Personne n’écrit du JSON-LD à la main en double-échappant volontairement un caractère. Le problème vient presque toujours d’un empilement discret. Un thème ou un CMS échappe déjà le HTML au moment de générer une valeur de champ, par exemple le nom d’une entreprise saisi dans les réglages. Un plugin SEO ou un module d’import applique ensuite un second échappement sur cette même valeur avant de la sérialiser en JSON-LD, sans savoir qu’elle l’a déjà subi une fois. Le résultat ne se voit pas à l’écran : la page affiche le nom de l’entreprise correctement, seul le bloc JSON-LD caché dans le <head> porte la double couche. Dans la pratique, personne dans l’équipe ne se souvient qui a activé quel plugin en premier : la double couche a rarement un seul responsable.
Prenez une boutique en ligne qui vend sous le nom « Meubles & Jardin » : si la fiche produit WooCommerce échappe déjà le « & » côté template et que le plugin SEO le ré-échappe à son tour dans le JSON-LD, la valeur finit doublement encodée. Même logique pour un cabinet de conseil qui importe ses avis clients via un export CSV contenant un caractère de coche « ✔ » ou une apostrophe typographique : chaque étape de la chaîne (export, import, plugin d’avis, plugin SEO) est un point où un échappement peut se rajouter sur un échappement déjà fait.
Comment auditer vos données structurées
Deux outils suffisent pour un premier passage, et aucun des deux ne nécessite d’attendre.
Le Rich Results Test, en direct
Le Rich Results Test de Google analyse une URL au moment où vous le lancez, avec le parseur à jour. C’est aujourd’hui le seul endroit où l’erreur remonte clairement : Search Console agrège ses rapports « Résultats enrichis » avec un délai de plusieurs jours, le temps que Googlebot re-crawle vos pages. Passez vos gabarits de page (fiche produit, article, page catégorie) un par un plutôt que votre page d’accueil seule : le JSON-LD généré diffère souvent d’un type de contenu à l’autre.
Un validateur JSON strict, pour repérer le double échappement à l’œil
Copiez le contenu brut de votre bloc <script type="application/ld+json"> (clic droit, « Afficher le code source », pas l’inspecteur qui reformate parfois l’affichage) dans un validateur JSON strict. Cherchez à l’œil les séquences qui commencent par & suivies d’autres caractères : &amp;, &quot;, &# suivi de chiffres. Chacune est un candidat au double échappement. Une seule couche, qui se résout en un caractère normal, est sans danger avec le parseur actuel.
Ce qui est réellement en jeu (et ce qui ne l’est pas)
Ce changement ne casse pas tout le JSON-LD d’un site. Il ne touche que les valeurs qui contiennent un caractère nécessitant un échappement, comme un « & » dans un nom de marque, un guillemet dans une citation, ou un symbole comme « ✔ » dans une liste de garanties. Une fiche produit sans caractère spécial dans ses champs n’est pas concernée. C’est un risque réel mais ciblé, pas un incident généralisé, et il mérite d’entrer dans la même routine que le reste de vos vérifications techniques, au même titre que celles listées dans notre audit SEO des vérifications qui comptent vraiment.
La correction qui tient : reprendre la main sur l’échappement
Une fois une valeur doublement échappée repérée, la corriger dans l’éditeur de contenu ne suffit pas : elle sera ré-échappée à la prochaine sauvegarde tant que la chaîne qui la génère (thème, plugin, import) n’est pas corrigée à la source. Si vous gérez le thème ou un module maison, la recommandation de Google reste la plus simple à appliquer : encoder les caractères sensibles en Unicode hexadécimal plutôt qu’en entité HTML avant de les insérer dans le JSON-LD. Si le problème vient d’un plugin tiers, un ticket de support avec l’exemple exact, valeur avant et après, suffit en général à obtenir un correctif : l’éditeur du plugin n’est presque jamais seul responsable de la double couche.
Une fois la correction déployée, revenez sur le Rich Results Test pour confirmer que la valeur se résout proprement, puis notez la date quelque part : Search Console mettra plusieurs jours à refléter le correctif dans ses rapports, et un contrôle trop rapproché ne montrera rien de nouveau. Sur un site avec plusieurs gabarits (fiche produit, article, page catégorie), vérifiez chacun séparément : corriger le générateur commun ne suffit pas toujours si un gabarit applique un échappement supplémentaire propre à son type de contenu.
D’autres formats de données lisibles par les systèmes de Google évoluent en ce moment, comme le format OKF destiné aux agents IA : la vigilance sur la structure de vos données ne se limite plus au seul JSON-LD.
Retenez une chose : passez vos gabarits de page dans le Rich Results Test cette semaine, pas à la prochaine refonte. L’erreur ne s’affiche nulle part ailleurs, et elle ne coûte cher que si elle traîne assez longtemps pour faire disparaître un rich result que vos concurrents, eux, ont gardé intact.
Crédits photo : Innovalabs, jamesmarkosborne, Boskampi / Pixabay.
