Google Search Central a annoncé le 21 août un changement dans la façon dont Googlebot extrait le JSON-LD, le format le plus utilisé pour les données structurées : le parseur n'applique plus qu'une seule passe de déséchappement HTML, pour s'aligner sur le standard JSON (RFC 8259, section 7, comme l'a rappelé Gary Illyes). Les entités doublement échappées, du type & ou ✔, ne sont plus « déroulées » automatiquement. Ce n'est pas une mise à jour de classement : c'est une règle d'extraction.
- Avant, Googlebot corrigeait de lui-même un balisage mal échappé et lisait quand même la bonne valeur ; désormais, l'entité reste littéralement dans la donnée (« Fish & Chips » au lieu de « Fish & Chips »), ce qui peut invalider un prix, une note, une FAQ ou un nom de produit
- Trois origines classiques : un champ CMS qui contient déjà une entité et qu'un gabarit ré-échappe au rendu, un moteur de templates qui échappe toutes les variables par défaut y compris dans un script, un plugin qui génère le schéma depuis le même champ que le contenu visible avec les règles HTML de ce dernier
- La correction est un contrôle, pas une refonte : lire le JSON-LD brut (pas la page rendue) sur un échantillon de gabarits, remplacer les entités HTML par des échappements JSON ou Unicode (\u0026), et surveiller les avertissements dans Search Console
Pourquoi le double échappement existe, et pourquoi Google arrête de le pardonner
Un bloc script de type application/ld+json n'est pas du HTML : son contenu est du JSON, et le standard JSON a ses propres règles d'échappement (barre oblique inverse, séquences \uXXXX). Beaucoup d'implémentations passent pourtant les chaînes par la même fonction d'échappement HTML que le reste de la page, par réflexe de sécurité ou parce que le moteur de templates le fait pour toutes les variables. Le résultat est un JSON valide syntaxiquement mais dont les valeurs contiennent des entités HTML. Google compensait en déséchappant deux fois. Il ne le fait plus, et il le dit : la charge d'être conforme passe côté site.
Ce qui casse, concrètement, ce sont les champs avec des caractères spéciaux : noms de produits ou d'établissements avec une esperluette, prix avec symbole monétaire encodé, descriptions avec guillemets typographiques ou apostrophes, réponses de FAQ avec du HTML, listes d'ingrédients. Un champ Product.name qui contient « & » ne fait pas planter le parseur ; il fait simplement remonter une mauvaise valeur, ce qui peut rendre le résultat enrichi non éligible ou l'afficher avec le texte erroné. La page visible n'est pas touchée.
Le calendrier n'est pas neutre. Google a retiré en 2025 plusieurs types de résultats enrichis peu utilisés (cours, salaire estimé, ClaimReview, annonces spéciales) pour simplifier la page de résultats, et durcit maintenant la lecture de ceux qui restent. Dans le même temps, les données structurées servent de plus en plus aux réponses générées, où une valeur fausse est reprise telle quelle. Un balisage exact devient un enjeu de fiabilité, pas seulement d'affichage.
Mon avis : c'est le type de changement que 90 % des sites ne verront jamais parce que leur plugin fait les choses correctement, et qui coûtera des semaines de résultats enrichis aux 10 % qui ont un gabarit maison ou une migration mal finie. Le seul moyen de savoir dans quel groupe on est, c'est d'ouvrir le JSON-LD brut.
Ce que ça change pour vous
Si vos données structurées sortent d'un plugin SEO à jour (Yoast, Rank Math, Schema Pro) ou d'une plateforme e-commerce standard, le risque est faible mais pas nul : un champ saisi avec une entité par un rédacteur peut être ré-échappé au rendu. Si vous avez un gabarit maison, un CMS headless ou une migration récente, c'est un contrôle prioritaire cette semaine.
Pour vérifier en masse, un crawl qui extrait le JSON-LD de chaque page et cherche les motifs &, &#, " dans les valeurs suffit : une extraction XPath ou par expression régulière sur le contenu des blocs ld+json fait le travail sur des milliers d'URL en quelques minutes.
- Sur un échantillon d'un gabarit par type (produit, article, FAQ, fiche locale), affiche le code source, copie le contenu du bloc ld+json et cherche « & », « &# » et « " » : chaque occurrence dans une valeur est une cible
- Corrige à la source : décode une fois avant d'écrire dans le script, ou marque la variable comme brute dans le moteur de templates, puis échappe en JSON (\u0026, \") et jamais en HTML
- Après correction, passe les pages au test des résultats enrichis et suis les rapports de données structurées de Search Console pendant deux semaines pour repérer les gabarits oubliés
Sources
- Search Engine Roundtable - Google Changes JSON-LD Extraction For Googlebot (21 août 2026, citation de Gary Illyes)
- Search Engine Watch - Google changes how it parses double-escaped JSON-LD entities
- Launchcodex - les trois origines du double échappement et la méthode de correction
- RFC 8259, section 7 - échappement des chaînes en JSON
Source : Seroundtable.com
Cet article a été rédigé avec l’assistance d’un modèle de langage (LLM).
