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

Les moteurs 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. 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 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 de la page ; 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 schema 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 ; en GEO, elles prennent une importance nouvelle.

Le bloc se déclare toujours de la même façon, avec un script type json placé 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": { "@type": "ImageObject", "url": "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 vocabulaire utilisé, le second déclare la nature de la page. Tout le reste dépend de la catégorie choisie, chacune ayant ses propriétés obligatoires et recommandées.

Pourquoi ce balisage compte pour les moteurs 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 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 des moteurs de recherche, mais il occupe plus de place et capte davantage de clics. En France, ces affichages enrichis sont désormais la norme sur les requêtes commerciales, et un type 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 modèle de langage 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 Organization 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 de Product ou FAQPage sont reprises telles quelles, prix, disponibilité, avis, réponse à une question, sans passer par une interprétation du contenu de la page.
• La fraîcheur. Les propriétés datePublished et dateModified indiquent l'âge de l'information, un critère que les moteurs 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 d'IA 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 et une meilleure reprise des informations déclarées. C'est un faisceau d'indices solide, pas une garantie contractuelle.

Que déployer en priorité

Le référentiel schema.org compte des centaines d'entrées, et il est inutile de toutes les couvrir. Cinq suffisent pour l'essentiel des besoins d'un site de marque.

Sur Product, une condition s'ajoute : le nom déclaré doit être rigoureusement identique à celui de votre flux marchand, sans quoi les moteurs génératifs 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 une page sans questions visibles, ou des avis que personne ne peut lire, expose à une sanction manuelle et retire l'éligibilité aux résultats enrichis. 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 propriétés obligatoires manquantes, qui rendent le bloc inéligible sans que rien ne soit signalé. Et les blocs 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 code doit être présent dans le HTML initial.

Tester et contrôler son balisage

Deux outils gratuits suffisent. L'outil de test des résultats enrichis de Google, le Rich Results Test, indique si la page est éligible aux affichages enrichis 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 code est-il correct ».

Passez ensuite au suivi 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 type et par URL, et c'est le seul endroit où vous verrez un problème apparu après coup sur des centaines de pages. Côté GEO, le contrôle utile est différent : il consiste à vérifier que les informations balisées sont bien celles que les moteurs 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 tarif obsolète, ces blocs sont la première piste à remonter.

Un exemple complet : le type Organization

La brique d'identité mérite un exemple entier, car c'est celle qui sert le plus au GEO. Elle relie votre marque à ses profils officiels, ce qui aide les moteurs à 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, 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, ajoutez Article aux contenus éditoriaux, puis FAQPage et Product là où c'est justifié. Validez sur cinq pages représentatives, 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 la recherche classique que les moteurs génératifs.

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