Les erreurs JSON-LD qui vous coûtent discrètement des résultats enrichis en 2026

La plupart des sites qui utilisent du JSON-LD aujourd'hui échoueraient à un test de base : coller leurs données structurées dans un validateur et voir ce qui en ressort réellement. Pas « est-ce optimisé ». Juste : est-ce que ça se parse. Est-ce que ça pointe vers une seule entité ou vers trois entités contradictoires. Est-ce un balisage pour un résultat enrichi que Google accorde encore.

Le balisage schema est devenu une case à cocher : on installe un plugin, on copie un template depuis un article de blog, et tout le monde suppose que ça fonctionne parce que rien n'a visiblement changé sur la page. Les échecs de données structurées sont invisibles par nature. Il n'y a pas de mise en page cassée à remarquer. Il y a juste un Knowledge Graph qui ne comprend jamais tout à fait qui vous êtes, des résultats enrichis qui n'apparaissent jamais, et personne pour déboguer puisque rien ne semble anormal.

Ce que le JSON-LD fait réellement en 2026

Deux tâches bien distinctes sont regroupées sous l'appellation « balisage schema », et c'est en les confondant que commence une bonne partie du travail gaspillé.

La première tâche, ce sont les résultats enrichis : les améliorations visuelles dans les SERP — étoiles de notation, fourchettes de prix, dates d'événements, offres d'emploi, fil d'Ariane, vignettes vidéo. Seul un ensemble restreint de @type y est éligible, et Google modifie cet ensemble sans grand préavis.

La seconde tâche, c'est la clarté entitaire : dire à Google qui vous êtes, à quoi vous appartenez, et comment vos pages sont liées entre elles. Organization, WebSite, Person et WebPage remplissent surtout ce rôle. Ils produisent rarement un extrait visible à eux seuls, mais c'est sur eux que s'appuient le Knowledge Panel, la sitelinks search box et la désambiguïsation de marque.

La plupart des erreurs de balisage qui méritent d'être corrigées se répartissent en trois catégories, et aucune n'est subtile une fois qu'on sait où regarder.

Erreur n°1 : du JSON cassé à cause de l'échappement des templates

C'est l'erreur la plus courante et la moins visible. Elle se produit à la jonction entre votre CMS et votre balise <script type="application/ld+json">.

Une citation d'avis contenant un guillemet double égaré. Une description produit collée depuis une fiche technique avec un saut de ligne brut au milieu. N'importe lequel de ces cas, inséré dans un template JSON-LD par simple concaténation de chaînes plutôt que par une sérialisation correcte, produit quelque chose comme ceci :

{
  "@type": "Product",
  "name": "Editor's Choice Desk Lamp",
  "description": "The reviewer called it "the best lamp under $50""
}

Ce guillemet double interne non échappé casse le parseur JSON exactement à cet endroit. Le Rich Results Test de Google le signalera comme invalide — mais ce test est généralement exécuté une seule fois, au lancement, sur une URL choisie à la main. Personne ne le relance sur les 400 pages produit mises en ligne six mois plus tard avec les habitudes de ponctuation d'un nouveau rédacteur.

La correction n'a rien de compliqué : ne construisez jamais la chaîne JSON à la main. Construisez l'objet dans votre langage de templating et sérialisez-le correctement (JSON.stringify en JS, json_encode en PHP, l'équivalent dans ce qui génère vos pages), afin que l'échappement soit géré par du code qui sait ce qu'est du JSON, et non par un rédacteur de template qui l'ignore. Validez ensuite le HTML rendu — la réponse réelle que voit un crawler — et non le code source du template. Un template peut sembler parfait et pourtant produire du JSON cassé pour la moindre chaîne contenant un caractère spécial.

Erreur n°2 : des entités Organization dupliquées sans @id commun

Ce cas apparaît presque à chaque fois qu'un site a connu une refonte, une migration de CMS, ou plus d'un plugin SEO actif en même temps.

Le thème émet un bloc Organization dans le pied de page. Un plugin en émet un autre sur chaque page, avec un logo et une liste sameAs légèrement différents. Un développeur en a ajouté un troisième, à la main, sur la page d'accueil, il y a deux ans, pour un test de balisage schema qui n'a jamais été nettoyé. Aucun ne partage le même @id.

Pour Google, trois objets Organization sans identifiant commun ne se lisent pas comme « une seule entreprise décrite trois fois ». Ils se lisent comme ambigus — potentiellement trois entités différentes, potentiellement des signaux redondants qui s'annulent mutuellement. Cette ambiguïté est exactement ce que le balisage d'entité est censé éviter.

La solution consiste en un unique @id canonique, créé une fois et référencé partout :

{
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Co",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": ["https://www.linkedin.com/company/example"]
}

Chaque autre page référence alors cet @id au lieu de reformuler l'objet — le publisher d'un WebSite, l'author ou le publisher d'un Article, l'isPartOf d'une WebPage. Une seule entité, un seul ensemble de faits, référencé de façon cohérente. C'est de la modélisation de graphe, pas de la décoration, et c'est ce qui fait la différence entre un Google qui fusionne vos signaux et un Google qui hésite sur quelle version de vous croire.

Erreur n°3 : des types de schéma qui ne rapportent plus rien

Google a restreint les résultats enrichis FAQ en août 2023 à un petit ensemble de sites gouvernementaux et de santé, puis a fini par supprimer complètement la fonctionnalité de la recherche — cette exception a elle aussi disparu. Le balisage FAQPage continue pourtant d'être copié-collé dans les bibliothèques de templates et les plugins CMS comme bonne pratique par défaut, et de nombreux sites B2B et e-commerce continuent de le déployer, sans rien en tirer, et s'exposent parfois à un vrai risque : si le texte de FAQ balisé ne correspond pas à ce qui est visible sur la page, c'est une violation des consignes sur les données structurées, pas seulement un balisage inutile. Les résultats enrichis HowTo ont disparu de la même façon — retirés du mobile en 2023, puis du desktop, sans qu'il reste de surface où ce type produise encore un résultat visible.

Ce qu'il faut surveiller n'est pas seulement « ce type est obsolète ». C'est un balisage copié depuis un template il y a trois ans et jamais réexaminé à la lumière de ce que ce type fait réellement aujourd'hui. Le vocabulaire de Schema.org est stable ; la volonté de Google de restituer tel ou tel type sous forme de résultat enrichi ne l'est pas, et elle évolue selon un calendrier dont personne ne vous informe.

Ce qui rapporte encore un résultat enrichi

La liste qui paie de façon fiable en 2026 : Product avec un prix réel, une disponibilité, et un AggregateRating issu de vrais avis sur ce produit précis (la politique de Google sur les extraits d'avis interdit explicitement les avis intéressés — une entreprise qui note son propre produit —, les avis doivent donc être de véritables avis clients, pas fabriqués) ; BreadcrumbList ; VideoObject ; JobPosting ; Event ; Recipe ; et SoftwareApplication avec un applicationCategory valide. À côté de cela, Organization et WebSite, avec une structure @id propre et dédupliquée, continuent d'assurer leur rôle plus discret de clarté entitaire et d'éligibilité à la sitelinks search box, même sans extrait visible qui leur soit propre.

Un audit minimal à réaliser chaque trimestre

• Validez la réponse HTML rendue, pas le fichier de template — les bugs d'échappement n'apparaissent qu'après le rendu.
• Passez votre codebase au grep pour repérer chaque endroit où Organization ou WebSite est émis. S'il y en a plus d'un, consolidez-les derrière un @id commun.
• Vérifiez chaque @type que vous déployez par rapport à la documentation actuelle de Google sur les données structurées, pas à l'article de blog dont vous l'avez copié.
• Vérifiez chaque mois les rapports « Améliorations » de Search Console — un pic d'erreurs « JSON-LD non valide » ou « Champ manquant » est généralement dû à un déploiement, pas à un changement de politique de Google.
• Vérifiez que chaque information balisée (une note d'avis, une réponse de FAQ, un prix) est visible sur la page sous la même forme. Un balisage non appuyé par du contenu visible est une violation des consignes qui n'attend que d'être repérée.

En résumé

Les données structurées sont de l'infrastructure, pas de la décoration — elles tombent en panne comme le fait l'infrastructure : silencieusement, jusqu'à ce qu'un audit ou une action manuelle le révèle. Les sites qui obtiennent des résultats enrichis en 2026 ne sont pas ceux qui ont le plus de balisage schema. Ce sont ceux dont le JSON se parse réellement, dont les entités se résolvent en un seul @id, et dont le balisage correspond à ce qu'une personne voit sur la page.

Si vous voulez que cela soit vérifié correctement — la sortie rendue, pas le code source du template — notre équipe SEO intègre la validation des données structurées à chaque audit technique, aux côtés du travail sur la crawlabilité et les Core Web Vitals qui se trouve généralement juste à côté.