JSON-LD : ce que change la passe unique de décodage de Googlebot

Le 21 août 2026, Google a signalé sur son compte professionnel une modification de la façon dont Googlebot extrait le JSON-LD des pages, et cette annonce mérite plus d'attention que sa formulation ne le laisse croire. Le robot n'applique désormais qu'une seule passe de décodage des entités HTML avant de confier le contenu de la balise à un analyseur JSON. Les blocs qui reposaient sur un second passage pour redevenir valides ne sont plus rattrapés : ils échouent à l'analyse et disparaissent purement et simplement des données prises en compte. Aucune alerte n'accompagne ce silence, aucun message d'erreur n'apparaît dans l'interface du site, et les résultats enrichis s'effacent sans que rien n'explique pourquoi. Nous détaillons ici la nature exacte du changement, les situations qui produisent un double échappement, la méthode pour repérer les blocs concernés et les corrections à appliquer.

Ce que Google a changé exactement

La formulation officielle tient en une phrase, et chacun de ses termes a une conséquence pratique qu'il vaut la peine de déplier avant de toucher au moindre gabarit.

Une seule passe de décodage

Le contenu d'une balise de script se trouve dans un document HTML, ce qui autorise l'emploi d'entités pour y représenter certains caractères. Le navigateur, comme le robot, décode ces entités avant de traiter le contenu. Google appliquait jusqu'ici ce décodage plusieurs fois de suite, ce qui revenait à rattraper les documents dont les entités avaient été encodées deux fois. Le robot s'en tient désormais à une passe unique, conforme à ce que fait n'importe quel navigateur. Un contenu correct n'est absolument pas affecté par ce resserrement. Un contenu qui dépendait du second passage devient invalide, et l'analyseur JSON s'arrête au premier caractère inattendu.

Le comportement précédent et sa raison d'être

Cette tolérance ne relevait pas du caprice. Le balisage structuré s'est répandu bien plus vite que la rigueur des outils qui le produisent, et une part importante des blocs publiés sur le web comportait des entités superflues. Rattraper ces documents évitait de perdre des données valides pour un détail de sérialisation. Le raisonnement se défend tant que la proportion de documents concernés reste importante. Il devient coûteux lorsque cette proportion baisse, puisqu'il impose de maintenir un comportement non conforme dont dépendent quelques sites, et qu'il produit des résultats imprévisibles sur les contenus qui contiennent légitimement une séquence ressemblant à une entité. Le retrait de cette tolérance était donc attendu.

La norme invoquée

Gary Illyes a renvoyé publiquement à la section 7 de la RFC 8259, celle qui définit les chaînes de caractères en JSON et la liste exacte des séquences d'échappement admises. Cette référence n'est pas décorative : elle indique que Google ne considère plus la question comme un arbitrage de tolérance mais comme une affaire de conformité. Le format JSON dispose de ses propres échappements, la barre oblique inversée suivie d'une lettre pour les caractères de contrôle usuels, et la notation \u suivie de quatre chiffres hexadécimaux pour tout le reste. Les entités HTML n'appartiennent pas à cette liste et n'ont jamais eu à figurer dans une valeur JSON.

Les entités concernées

Google cite deux exemples parlants. L'esperluette écrite & était auparavant ramenée à une esperluette simple après deux passages, alors qu'une seule passe la laisse sous la forme &, qui reste une chaîne de caractères sans signification particulière. Une coche écrite sous forme d'entité numérique double subit le même sort. Le problème ne vient pas de la présence d'une entité mais du fait qu'elle en cache une seconde. Dans les deux cas, le résultat n'est pas une erreur bruyante mais une valeur légèrement fausse, ou un bloc entier rejeté lorsque le caractère parasite tombe au mauvais endroit de la structure.

Ce que le changement ne touche pas

Un bloc dont les caractères spéciaux sont écrits directement, dans un document servi en UTF-8, ne change pas de comportement. Un bloc utilisant les échappements JSON standards non plus. Les autres formats de balisage, microdonnées ou RDFa, ne sont pas concernés par cette annonce puisqu'ils vivent dans le balisage visible et non dans une chaîne. La distinction entre les deux familles de formats et les raisons du choix de l'un ou de l'autre sont détaillées dans notre article sur les différences entre le JSON et le JSON-LD. Enfin, la validité au regard du vocabulaire employé est un sujet distinct, examiné après l'analyse syntaxique.

Un changement sans préavis

Aucune période de transition n'a été annoncée, et la communication a pris la forme d'une publication sur un réseau social plutôt que d'une entrée dans le journal des modifications de la documentation. Ce mode d'annonce est fréquent pour les ajustements considérés comme des corrections de conformité, et il laisse peu de marge aux sites concernés. La conséquence pratique est simple : le contrôle doit être fait maintenant plutôt que planifié, car les blocs invalides ne produisent aucun signal actif et peuvent passer plusieurs semaines inaperçus. Le coût de la vérification est faible, celui d'une découverte tardive ne l'est pas.

D'où vient le double échappement

Personne n'écrit sciemment une entité dans une entité. Le double échappement est presque toujours le produit d'une chaîne de traitements dont chaque maillon fait son travail correctement.

Le mécanisme en deux couches

Un bloc de balisage structuré traverse au moins deux contextes : celui du document HTML qui le contient et celui du format JSON qui le décrit. Chaque contexte a ses propres règles d'échappement, et le rôle du développeur consiste à appliquer la bonne règle au bon endroit, une seule fois. Le défaut apparaît lorsqu'une valeur est protégée pour le contexte HTML alors qu'elle sera insérée dans une chaîne JSON, puis protégée une seconde fois par la fonction qui sérialise cette chaîne. Le résultat est syntaxiquement légal en HTML, illisible en JSON, et parfaitement invisible à l'œil.

La concaténation de chaînes dans un gabarit

La cause la plus fréquente reste la construction du bloc par assemblage de morceaux de texte. Le gabarit écrit une accolade, puis une clé, puis une valeur passée dans la fonction d'échappement habituelle du langage, celle qui protège du HTML. Cette fonction transforme les esperluettes et les chevrons en entités, ce qui est exactement ce qu'il ne faut pas faire à l'intérieur d'une chaîne JSON. Le bloc obtenu fonctionnait tant que le robot décodait deux fois. Il cesse de fonctionner aujourd'hui, et la correction consiste à supprimer cet échappement plutôt qu'à en ajouter un autre.

Les fonctions appliquées deux fois

Une variante de la même erreur survient lorsqu'un jeu de données est préparé par une fonction, transmis à une autre couche, puis à nouveau préparé par une fonction identique. Chaque couche ignore ce qu'a fait la précédente et applique consciencieusement son traitement. Ce cas se rencontre dès qu'un site comporte plusieurs niveaux de gabarits ou qu'une extension enrichit un contenu déjà préparé par une autre. Le repérer suppose de suivre la valeur d'un bout à l'autre de la chaîne, exercice fastidieux mais qui ne se fait qu'une fois et qui règle en général plusieurs symptômes différents.

Les données déjà encodées en base

Un titre saisi il y a huit ans dans un système qui stockait les entités plutôt que les caractères ressort de la base sous forme d'entité. Il traverse ensuite la chaîne de production comme n'importe quelle autre valeur et se retrouve échappé une seconde fois. Ce cas est particulièrement pénible parce que la donnée source est elle-même abîmée et que la correction du gabarit ne suffit pas. Il relève de la même famille de problèmes que ceux que nous décrivons dans notre article sur le mojibake et le double encodage UTF-8, et il se traite de la même manière, par une reprise ciblée des enregistrements concernés.

Les extensions de référencement

Les extensions qui produisent le balisage structuré exposent presque toutes des filtres permettant de modifier les valeurs avant l'écriture. Un filtre ajouté par un développeur pour corriger un titre applique fréquemment une fonction d'échappement par prudence, ce qui introduit exactement le défaut décrit ici. La prudence est légitime et le contexte est mal identifié. Le rôle de ces extensions dans la production du balisage, ainsi que la manière de les surveiller, sont abordés dans notre article sur l'intérêt d'intégrer du JSON-LD dans le code source. Un filtre bien écrit modifie la valeur brute et laisse la sérialisation à l'extension.

Les collages depuis un traitement de texte

Lorsqu'un bloc est saisi à la main dans un champ de code de l'administration, le passage par un éditeur visuel ou par un presse-papiers riche transforme parfois les caractères spéciaux en entités. Le bloc affiché à l'écran semble correct puisque l'éditeur les rend fidèlement, et la source enregistrée contient déjà l'encodage. Cette cause est fréquente sur les sites où le balisage est maintenu manuellement page par page. Elle se prévient en imposant la saisie dans un champ de texte brut, jamais dans un éditeur enrichi, et en relisant la source enregistrée plutôt que l'aperçu.

Repérer les blocs concernés sur son site

Le diagnostic ne demande aucun outil particulier, seulement de regarder la bonne chose au bon endroit, ce qui est moins évident qu'il n'y paraît.

Lire la source, pas l'inspecteur

L'inspecteur d'éléments du navigateur affiche l'arbre du document après décodage, ce qui masque précisément le défaut recherché. Une entité doublement encodée y apparaît comme une entité simple, parfaitement anodine. Le contrôle doit donc porter sur la source telle qu'elle est transmise, obtenue par la commande d'affichage du code source de la page ou par une requête en ligne de commande. Cette distinction explique qu'un défaut soit resté invisible pendant des mois malgré des vérifications régulières. C'est le premier réflexe à corriger, et il coûte un raccourci clavier différent.

Le test des résultats enrichis

L'outil de test de Google analyse la page telle que le robot la reçoit et signale les blocs qu'il ne parvient pas à lire. Un bloc absent du rapport alors qu'il figure dans la source constitue le signal le plus net. Cet outil applique la même logique d'extraction que le robot, ce qui en fait la référence pratique. Il faut néanmoins tester une adresse réelle et non un collage de code, car un collage court-circuite précisément l'étape de décodage HTML qui pose problème. Cette nuance change complètement la valeur du test.

Le rapport de la Search Console

La console de recherche recense les éléments non analysables sous une rubrique dédiée, avec le motif du rejet. Un motif mentionnant une séquence d'échappement incorrecte ou un caractère inattendu désigne le défaut décrit ici. Ce rapport a l'avantage de couvrir l'ensemble du site plutôt qu'une page choisie, et l'inconvénient d'un délai de plusieurs jours entre l'exploration et l'affichage. Il sert donc à mesurer l'ampleur du problème et à suivre la disparition des erreurs après correction, pas à valider un correctif dans la minute qui suit sa mise en ligne.

Un crawl ciblé sur les balises de script

Un outil d'exploration configuré pour extraire le contenu des balises de script portant le type approprié produit en une passe la liste complète des blocs du site. Une recherche sur la présence d'une esperluette suivie des lettres formant le nom d'une entité, à l'intérieur de ces extractions, isole immédiatement les pages suspectes. Sur un site de quelques milliers d'adresses, l'opération prend une dizaine de minutes et donne une réponse exhaustive. Elle vaut mieux qu'un échantillonnage, car les défauts se concentrent souvent sur un type de contenu précis que le hasard peut manquer.

Les séquences à chercher en priorité

Trois familles couvrent la quasi totalité des cas. La première regroupe les entités nommées imbriquées, reconnaissables au fait que le nom de l'entité commence lui-même par une esperluette encodée. La deuxième rassemble les entités numériques doublement encodées, dont la forme est plus difficile à lire mais tout aussi caractéristique. La troisième concerne les apostrophes et guillemets typographiques encodés, très répandus dans les titres éditoriaux. Chercher ces trois motifs dans les extractions du crawl suffit à établir un diagnostic complet sans avoir à inspecter les blocs un par un.

Constituer un échantillon représentatif

Lorsque le crawl complet n'est pas possible, l'échantillon doit couvrir chaque type de contenu et chaque source de balisage plutôt qu'un nombre élevé de pages semblables. Cinq fiches produits, cinq articles, la page d'accueil et deux pages de catégorie renseignent davantage que deux cents articles du même gabarit. Cette règle vaut pour tous les diagnostics techniques et elle est régulièrement oubliée au profit du volume. Noter, pour chaque page testée, quelle brique produit son balisage rend la synthèse immédiatement exploitable et évite de refaire le travail lors de la correction.

Corriger, puis empêcher le retour

La correction est simple sur le principe et la difficulté porte sur l'endroit exact où intervenir, ainsi que sur la manière d'éviter que le défaut ne réapparaisse à la prochaine évolution.

Sérialiser plutôt que concaténer

La correction de fond consiste à construire une structure de données dans le langage employé, puis à la confier à la fonction de sérialisation JSON fournie par ce langage. Cette fonction applique les échappements corrects et elle est la seule à connaître la liste exacte des séquences admises. Toute construction par assemblage de texte finit tôt ou tard par produire un document invalide, sur un titre contenant un caractère imprévu ou sur une description venant d'un import. Ce changement demande une heure sur un gabarit et il supprime définitivement une famille entière de défauts.

Les échappements Unicode

Lorsque la sérialisation automatique n'est pas envisageable, par exemple sur un bloc maintenu à la main, la notation hexadécimale reste la solution la plus sûre. Elle représente n'importe quel caractère sans dépendre du contexte HTML et elle traverse sans dommage les chaînes de traitement qui manipulent le texte. Elle rend le bloc moins lisible pour un humain, inconvénient réel mais mineur au regard du service rendu. Google la recommande explicitement pour les caractères qui posent problème, et elle constitue la réponse directe à l'annonce du 21 août.

Le cas des apostrophes typographiques

Les titres éditoriaux français contiennent presque tous une apostrophe courbe, caractère qui n'a aucune raison d'être échappé dans une chaîne JSON servie en UTF-8. Beaucoup de gabarits l'encodent pourtant par précaution, ce qui est inutile dans le meilleur des cas et produit le défaut décrit ici dans le pire. La bonne pratique consiste à déclarer correctement l'encodage du document et à laisser passer ces caractères tels quels. Cette simplification règle à elle seule une part notable des blocs concernés sur un site éditorial en langue française.

Les blocs produits par une extension

Lorsque le balisage est produit par une extension, la correction ne se fait pas dans son code, qui sera écrasé à la prochaine mise à jour. Elle passe par les filtres exposés, en veillant à ne fournir que des valeurs brutes. Si l'extension elle-même produit un double échappement, le signalement à son auteur est la seule voie durable, accompagnée d'un contournement temporaire dans le thème enfant. Documenter ce contournement, avec la version concernée et la date, évite qu'il ne soit conservé bien après la correction officielle et ne devienne à son tour la cause du problème.

Une vérification à chaque mise en ligne

Le contrôle mérite d'entrer dans la liste des vérifications de mise en production, au même titre que le contrôle des redirections. Il consiste à récupérer une adresse de chaque type de contenu, à extraire le contenu des balises de script et à confirmer que l'analyse JSON aboutit. Cette vérification s'automatise en quelques lignes et elle s'exécute en quelques secondes. Elle transforme un incident silencieux en échec visible au moment du déploiement, seul moment où la correction coûte peu. Sans elle, le prochain défaut passera aussi inaperçu que celui-ci.

Suivre la documentation de référence

Les règles de production du balisage évoluent, et les annonces de ce type ne sont pas toujours reprises dans la documentation au moment où elles paraissent. Conserver un signet vers la page de référence et la relire lors de chaque chantier touchant au balisage constitue la seule veille réellement tenable. Les recommandations générales sur le format à employer, les propriétés attendues et la validation avant mise en ligne figurent dans le guide des données structurées de Google, qui reste le point de départ de toute décision sur le sujet.