Données structurées et IA : le guide JSON-LD pour le GEO

Les assistants génératifs lisent vos pages autrement qu'un humain. Avant même de parcourir votre texte, un modèle appelle parfois l'intégralité du balisage structuré d'une page pour savoir à quoi il a affaire : un produit, un article, une entreprise, une question. C'est la fonction du JSON-LD, et c'est ce qui en fait l'un des rares leviers techniques du GEO à effet mesurable sur la visibilité. Ce guide explique quoi baliser, comment écrire le code, et où s'arrête l'utilité réelle des données structurées.

JSON-LD, données structurées, schema.org : le vocabulaire

Les données structurées sont une description de votre contenu dans un format que les machines comprennent sans ambiguïté. Là où un humain déduit d'une page qu'il s'agit d'une fiche produit à 49 euros disponible en stock, un moteur a besoin qu'on le lui dise en propriétés explicites : Product, name, offers, price, availability.

Le vocabulaire utilisé s'appelle schema.org, et il s'invoque dans chaque bloc par la ligne json context schema.org. C'est un référentiel partagé de catégories et de propriétés, lancé en 2011 par Google, Microsoft, Yahoo et Yandex, qui décrit aujourd'hui plusieurs centaines de types d'entités. Trois syntaxes permettent de l'écrire dans une page web : JSON, microdata, RDFa. Les deux dernières s'insèrent dans les balises HTML du contenu visible, mêlées au markup et au CSS ; la première se place à part, dans un bloc de script. La documentation Google sur les données structurées recommande explicitement le format JSON-LD, et pour une raison pratique : le balisage vit dans un bloc indépendant, donc lisible, modifiable et injectable par un CMS sans toucher au gabarit. En SEO, les données structurées sont depuis longtemps un chantier standard ; face aux IA génératives, elles prennent une importance nouvelle pour la visibilité de la marque.

Le bloc se déclare toujours de la même façon, avec une balise script placée dans le head ou en fin de body :

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Titre exact de votre article",
  "datePublished": "2026-09-08",
  "dateModified": "2026-09-08",
  "author": { "@type": "Person", "name": "Prénom Nom", "url": "https://votresite.com/equipe/prenom-nom" },
  "publisher": { "@type": "Organization", "name": "Votre entreprise" },
  "image": "https://votresite.com/cover.webp"
}
</script>

Les deux premières lignes ne changent jamais. Le couple @context schema.org et @type ouvre chaque schema JSON : le premier indique le référentiel utilisé, le second déclare la nature du document. Tout le reste dépend des schémas choisis, chacun ayant ses propriétés obligatoires et recommandées.

Pourquoi ce balisage compte pour les assistants IA

L'intérêt des données structurées SEO est connu de longue date : elles conditionnent l'affichage des résultats enrichis dans les SERP de Google search, ces rich snippets qui montrent une note en étoiles, un prix, une durée de recette ou un fil d'ariane. Un rich snippet ne fait pas monter la page dans le classement de la recherche, mais il occupe plus de place et capte davantage de clics. En France, cet affichage enrichi est désormais la norme sur les requêtes commerciales, et un bloc LocalBusiness bien renseigné alimente en prime les fiches Google Maps.

En GEO, le mécanisme est différent et sans doute plus décisif. Un LLM doit décider en quelques instants si votre page répond à la question posée. Le balisage lui donne cette réponse sous forme de faits déjà qualifiés, sans avoir à interpréter votre mise en forme. Trois effets ressortent des cas que nous suivons.

• La désambiguïsation. Une page qui déclare son identité avec un nom, un logo et un lien sameAs devient une entité identifiée, pas une chaîne de caractères parmi d'autres. C'est ce qui permet à un moteur de relier votre marque à ses mentions ailleurs sur le web.
• L'extraction directe. Les propriétés d'une fiche Product ou d'une FAQ sont reprises telles quelles, prix, disponibilité, avis, réponse à une question, sans interprétation du contenu.
• La fraîcheur. Les champs datePublished et dateModified indiquent l'âge de l'information, un critère que les modèles génératifs utilisent pour arbitrer entre deux sources concurrentes.

Un point mérite d'être posé clairement, car il circule beaucoup d'approximations sur le sujet : aucun éditeur de LLM n'a publié de documentation confirmant qu'il pondère le JSON-LD dans la sélection de ses sources. Ce que nous observons, ce sont des appels à ces blocs dans les journaux serveur des sites suivis et une meilleure reprise des informations déclarées. C'est un faisceau d'indices solide, pas une garantie contractuelle.

Quels types déployer en priorité

Le référentiel schema.org compte des centaines d'entrées, et il est inutile de couvrir tous ces schémas. Cinq types suffisent pour l'essentiel des besoins des sites de marque.

Sur une fiche produit, une condition s'ajoute : le nom déclaré doit être rigoureusement identique à celui de votre flux marchand, sans quoi les assistants ne rapprochent pas les deux sources.

Voici à quoi ressemble une paire question-réponse correctement balisée dans une page FAQ :

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Le JSON-LD améliore-t-il le classement ?",
    "acceptedAnswer": { "@type": "Answer", "text": "Non, il conditionne l'affichage enrichi et la compréhension de la page." }
  }]
}

La règle qui compte plus que le code

Le balisage doit refléter le contenu visible de la page, rien de plus. Déclarer une FAQPage sur un contenu sans questions visibles, ou des avis que personne ne peut lire, expose à une sanction manuelle et retire l'éligibilité aux rich results. La documentation de Search Central est explicite sur ce point, et l'expérience montre que ces pénalités sont durables.

Trois autres erreurs reviennent souvent. Les incohérences de dates, quand la date affichée, la propriété dateModified et l'en-tête HTTP Last-Modified racontent trois histoires différentes. Les champs obligatoires manquants, qui rendent le bloc inéligible sans que rien ne soit signalé. Et les blocs de script injectés par JavaScript côté client : Google finit par les rendre, mais les crawlers des modèles génératifs ne rendent pas le JS de façon fiable, donc vos déclarations leur restent invisibles. Le balisage doit être présent dans le HTML initial.

Tester et contrôler son balisage

Deux outils web gratuits suffisent. L'outil de test des résultats enrichis de Google, le Rich Results Test, indique si la page est éligible à l'affichage enrichi et liste les propriétés manquantes. C'est le premier réflexe après chaque modification. Le Schema Markup Validator, hébergé par schema.org, valide la conformité au vocabulaire indépendamment de ce que Google accepte. Les deux sont complémentaires : le premier répond « Google en fera-t-il quelque chose », le second « ce bloc est-il correct ».

Passez ensuite au suivi SEO dans la durée. Google Search Console remonte les erreurs de données structurées détectées sur l'ensemble du site, avec le détail par catégorie et par adresse, et c'est le seul endroit où vous verrez un problème apparu après coup sur des centaines de pages. Côté IA, le contrôle utile est différent : il consiste à vérifier que les informations balisées sont bien celles que les IA reprennent quand ils parlent de vous. C'est exactement ce que Meteoria mesure au quotidien sur ChatGPT, Perplexity, Gemini et Copilot, en montrant les sources citées et les formulations employées. Si un modèle décrit votre offre avec un prix obsolète, ce balisage est la première piste à remonter.

Un exemple complet : le balisage d'identité

Cette brique mérite un exemple entier, car c'est celle qui sert le plus face aux IA. Elle relie votre marque à ses profils officiels, ce qui aide les modèles à rattacher vos mentions dispersées à une seule entité :

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Votre entreprise",
  "url": "https://votresite.com",
  "logo": { "@type": "ImageObject", "url": "https://votresite.com/logo.png" },
  "sameAs": ["https://www.linkedin.com/company/votre-entreprise"]
}

Une règle simple sur la propriété sameAs : ne listez que des profils actifs et à jour. Un lien vers un compte abandonné depuis trois ans dessert la crédibilité de l'entité plutôt qu'il ne la renforce.

Une brique parmi d'autres dans une stratégie GEO

Les données structurées sont une condition nécessaire de votre visibilité, jamais suffisante. Elles fonctionnent quand le reste du terrain technique est propre : contenu lisible sans JavaScript, temps de réponse maîtrisé, en-têtes de fraîcheur exacts, robots.txt qui n'enferme pas le site. Notre article sur les crawlers IA détaille quels agents autoriser, et celui sur le fichier llms.txt remet ce chantier à sa juste place dans la liste des priorités. Pour cadrer l'ensemble, la méthode d'audit GEO reprend ces points dans un ordre d'exécution.

Concrètement, si vous partez de zéro : déployez Organization et BreadcrumbList sur tout le site web, ajoutez Article aux contenus éditoriaux, puis les types FAQPage et Product là où c'est justifié. Validez sur cinq pages représentatives, corrigez les erreurs, surveillez Search Console pendant un mois, et mesurez ensuite l'effet sur vos citations. Une demi-journée de travail technique, et un socle de données structurées qui sert autant le SEO et la recherche classique que les moteurs génératifs.

Questions fréquentes sur le JSON-LD et le GEO