Données structurées JSON-LD :
pourquoi et comment les mettre en place

Qu'est-ce que le JSON-LD et Schema.org, expliqué simplement

Le JSON-LD est un format de code qui permet d'ajouter des données structurées à une page web en s'appuyant sur le vocabulaire Schema.org. Concrètement, c'est un bloc de texte inséré dans le code source de la page, invisible pour le visiteur, qui décrit le contenu de façon standardisée pour les moteurs de recherche et les intelligences artificielles génératives, sans rien changer à l'affichage visuel de la page.

Schema.org est un vocabulaire commun, maintenu conjointement par Google, Microsoft (Bing) et Yahoo, qui définit des centaines de "types" pour décrire à peu près tout ce qui peut apparaître sur un site : un article, une entreprise, un produit, une recette, un événement, une question fréquente. Chaque type possède ses propres propriétés. Un type Article attend par exemple un titre (headline), une date de publication (datePublished) et un auteur (author).

Avant le JSON-LD, la méthode dominante s'appelait le microdata : elle imposait d'ajouter des attributs directement dans les balises HTML visibles du contenu, ce qui rendait le code plus lourd et plus fragile à maintenir. Le JSON-LD, recommandé aujourd'hui par Google comme format privilégié, fonctionne différemment : il se place dans un bloc <script type="application/ld+json"> unique, généralement dans le head de la page, complètement séparé du HTML visible. Cette séparation facilite la génération automatique du balisage, sa maintenance dans le temps, et sa cohabitation avec un site qui affiche une partie de son contenu via JavaScript.

En résumé, les données structurées ne sont pas un outil de mise en forme : elles ne modifient jamais ce qu'un visiteur voit à l'écran. Elles ajoutent une couche de contexte lisible par les machines, une sorte de fiche d'identité de la page, que les moteurs de recherche et les IA génératives exploitent pour mieux interpréter ce que contient réellement cette page.

Pourquoi ça sert au SEO ET au GEO

Les données structurées jouent aujourd'hui un double rôle. Côté SEO classique, elles aident Google à comprendre précisément la nature d'une page et, dans certains cas, à générer un affichage enrichi dans les résultats de recherche. Côté GEO (Generative Engine Optimization), elles fournissent aux IA génératives comme ChatGPT ou Perplexity une structure claire sur laquelle s'appuyer pour identifier l'auteur, la date, le sujet et l'organisation derrière un contenu, ce qui facilite sa compréhension et sa citation dans une réponse générée. Nous détaillons cette logique plus largement dans notre article sur comment être visible sur ChatGPT et les moteurs de réponse IA.

Il faut toutefois être précis sur ce que le balisage schema garantit réellement, et ce qu'il ne garantit plus. Un point mérite d'être clarifié sans ambiguïté : Google a retiré le rich result FAQ depuis le 7 mai 2026, pour tous les sites, sans exception. Concrètement, même un site qui balise correctement une page en FAQPage ne verra plus les questions/réponses déroulantes s'afficher directement dans les résultats Google. Le schema FAQPage conserve une utilité réelle : il structure la sémantique de la page et reste exploité par les IA génératives pour identifier des questions et des réponses claires à reprendre. Mais il ne faut plus jamais promettre un affichage enrichi visible dans Google sur la base de ce seul balisage. Le même constat s'applique au schema HowTo, qui n'a lui non plus plus d'effet de rich result dans les résultats de recherche classiques.

Cette évolution ne rend pas les données structurées inutiles, elle déplace simplement leur valeur. Un balisage propre reste l'un des signaux les plus directs pour aider un moteur, humain ou génératif, à comprendre qui vous êtes, ce que vous publiez et depuis quand. C'est exactement ce que nous mettons en œuvre dans notre accompagnement SEO et GEO : un balisage cohérent sur l'ensemble d'un site, pensé pour la compréhension machine plutôt que pour l'espoir d'un affichage enrichi qui n'est plus garanti sur la majorité des types de schema.

Pour un site d'entreprise, l'enjeu concret est donc double : rester lisible pour Google afin de conserver les affichages enrichis encore actifs (avis produits, fil d'Ariane, logo dans les résultats de marque), et devenir une source identifiable et citable pour les IA génératives qui composent de plus en plus les recherches des utilisateurs, y compris ceux de vos futurs clients.

Les types de schema les plus utiles pour un site d'entreprise

Tous les types Schema.org ne se valent pas pour un site professionnel. Certains apportent une valeur sémantique forte et un affichage enrichi encore actif, d'autres servent uniquement de contexte pour les IA génératives. Voici les six types les plus pertinents pour la majorité des sites d'entreprise, avec la page où les utiliser en priorité.

Le schema BreadcrumbList mérite une attention particulière parce qu'il complète directement le maillage interne du site : il donne à Google une lecture explicite de la hiérarchie entre vos pages, en plus des liens internes déjà présents dans le contenu et la navigation. Un site qui combine un maillage interne cohérent et un balisage BreadcrumbList propre offre une carte redondante mais fiable de sa propre architecture, ce qui facilite le travail d'indexation.

• Commencez toujours par Organization : c'est le socle qui identifie votre entité pour tous les autres schemas du site, et la base de toute stratégie de réputation d'entité en GEO.
• N'ajoutez FAQPage que sur une vraie FAQ visible : le schema doit refléter mot pour mot le contenu affiché à l'écran, jamais un contenu inventé pour le seul bénéfice du balisage.
• Priorisez Article et BreadcrumbList sur un site de contenu : ce sont les deux types qui apportent le plus de contexte structurel pour un blog ou un site éditorial d'entreprise.

Comment vérifier et tester son balisage

Un balisage JSON-LD mal formé, avec une virgule manquante ou une propriété obligatoire absente, peut être tout simplement ignoré par les moteurs qui le lisent, sans qu'aucun message d'erreur ne s'affiche sur le site lui-même. Vérifier son balisage avant et après publication est donc une étape indispensable, pas une option.

Nous avons développé un outil gratuit de test du balisage Schema Markup et Open Graph, qui analyse le JSON-LD et les balises Open Graph d'une URL donnée, signale les erreurs de syntaxe et les propriétés manquantes, et vérifie que le contenu balisé correspond bien à ce qui est visible sur la page. C'est la méthode la plus rapide pour un dirigeant non technique de vérifier, en quelques secondes, si le travail d'un prestataire ou d'un développeur interne a été fait correctement.

Au-delà de notre outil, trois vérifications simples permettent un premier diagnostic sur n'importe quel site : ouvrir le code source de la page et chercher le bloc application/ld+json, copier son contenu dans un validateur JSON pour repérer une éventuelle erreur de syntaxe, puis comparer manuellement chaque information balisée (auteur, date, titre) avec ce qui est réellement affiché sur la page. Un écart entre les deux est toujours un signal à corriger en priorité.

Erreurs fréquentes

La plupart des problèmes de données structurées viennent de deux erreurs récurrentes, l'une technique et l'autre éditoriale. Les corriger en priorité évite l'essentiel des soucis rencontrés sur un site d'entreprise.

• Le schema injecté uniquement en JavaScript, sans rendu côté serveur. Si le balisage n'apparaît que dans le DOM une fois le JavaScript exécuté par le navigateur, certains robots d'indexation, notamment ceux des IA génératives, peuvent ne jamais l'exécuter et donc ne jamais le voir. Un balisage JSON-LD présent directement dans le HTML servi par le serveur, avant toute exécution de script, reste la méthode la plus fiable.
• Des données inventées dans le schema. Indiquer une note ou un avis client auto-déclaré, une disponibilité produit fictive, ou une date de publication modifiée artificiellement dans le balisage constitue une déclaration trompeuse envers les moteurs qui la lisent. Ce type de donnée doit toujours refléter une information réelle et vérifiable, jamais un chiffre choisi pour paraître plus convaincant.
• Un balisage dupliqué ou contradictoire entre plusieurs blocs JSON-LD sur la même page, souvent laissé par un ancien plugin ou une ancienne intégration jamais nettoyée, ce qui peut semer la confusion chez les moteurs qui lisent la page.

Dans les deux cas, la règle reste la même : le JSON-LD doit décrire fidèlement ce qui existe réellement sur la page, ni plus, ni moins. Un balisage propre et honnête reste utile durablement, même quand un rich result particulier n'est plus affiché par Google.