Comment JSON-LD aide l'IA à comprendre votre site web

Jun 3, 2026 · 9 min read

Comment JSON-LD aide l'IA à comprendre votre site web

JSON-LD est un format basé sur la balise <script> permettant d’intégrer le vocabulaire Schema.org sous forme de métadonnées structurées et lisibles par les machines dans votre HTML. Il permet aux moteurs de recherche et aux systèmes d’IA d’identifier des entités — articles, organisations, produits, fils d’Ariane, personnes — sans avoir à les déduire du texte en prose. Pour Google Search, un JSON-LD correct rend les pages éligibles à des fonctionnalités de recherche spécifiques et contribue à alimenter le Knowledge Graph. Pour les crawlers IA tels que GPTBot, ClaudeBot et PerplexityBot, il existe une contrainte fondamentale que les développeurs frontend manquent systématiquement : ces crawlers n’exécutent pas JavaScript, ce qui signifie que le JSON-LD doit être présent dans la réponse du serveur pour leur être accessible.

Cet article couvre ce que JSON-LD fait réellement, les cas où il est utile et ceux où il ne l’est pas, trois exemples fonctionnels que vous pouvez adapter, le problème de rendu qui rend le balisage injecté côté client invisible pour les crawlers IA, et comment valider ce que vous mettez en production.

Points clés

JSON-LD est le format de données structurées recommandé par Google ; il utilise le vocabulaire Schema.org pour décrire des entités et leurs relations sous une forme lisible par les machines.
Les crawlers IA, notamment GPTBot, ClaudeBot et PerplexityBot, n’exécutent pas JavaScript — le JSON-LD injecté via useEffect, Google Tag Manager ou tout autre chemin côté client leur est invisible.
AI Overviews et AI Mode ne nécessitent pas de balisage spécifique à l’IA ; les critères d’éligibilité standard de Google Search s’appliquent, et les données structurées facilitent l’interprétation sans garantir l’inclusion.
Google a cessé d’afficher les résultats enrichis FAQ en mai 2026, avec la suppression du support dans Search Console et le Rich Results Test en juin 2026 ; FAQPage reste un type Schema.org valide, mais n’est plus une tactique de croissance pour les résultats enrichis.
Pour une validation pérenne, validator.schema.org est la valeur sûre par défaut — il vérifie l’intégralité du vocabulaire Schema.org, tandis que le Google Rich Results Test ne couvre que les fonctionnalités prises en charge par Google.

Ce qu’est JSON-LD et pourquoi il existe

JSON-LD (JavaScript Object Notation for Linked Data) est une syntaxe standardisée par le W3C pour exprimer des données liées en JSON. Sur le web, il est presque toujours utilisé pour intégrer le vocabulaire Schema.org dans une balise <script type="application/ld+json"> dans le document. Les données décrivent les entités de la page — son sujet, son auteur, l’organisation qui l’a publiée, ses relations avec d’autres pages — sous une forme qu’un analyseur syntaxique peut consommer sans lire le texte en prose.

La raison d’être de JSON-LD est le coût interprétatif. Sans données structurées, un crawler doit déduire que « Apple » sur une page désigne l’entreprise et non le fruit ; que la signature « Jane Chen » est l’auteure et non un sujet traité ; qu’un prix dans le balisage appartient au produit de la page et non à un article connexe dans une barre latérale. Schema.org attribue à ces faits des types et des propriétés explicites. JSON-LD les regroupe dans un bloc découplé du DOM visible, ce qui explique pourquoi Google le recommande plutôt que Microdata et RDFa — vous pouvez le générer et le mettre à jour sans toucher à la mise en page.

Quelques précisions s’imposent : JSON-LD n’est pas un facteur de classement confirmé dans les systèmes de classement documentés de Google. Il ne garantit pas les résultats enrichis — l’éligibilité est nécessaire mais pas suffisante. Il ne garantit pas l’inclusion dans AI Overviews ou AI Mode. Et les systèmes d’IA n’ont pas besoin de JSON-LD ; ils peuvent lire le texte en prose. Ce que JSON-LD apporte, c’est une réduction du travail d’inférence, ce qui rend une interprétation correcte plus probable et diminue le risque de mauvaise classification des contenus ambigus.

Comment JSON-LD s’intègre dans AI Overviews et AI Mode

AI Overviews et AI Mode fonctionnent au-dessus de l’index de recherche existant de Google. Les directives publiées par Google indiquent qu’il n’existe pas de balisage spécifique à l’IA — les pages deviennent éligibles aux fonctionnalités IA via les mêmes signaux de contenu et de données structurées qui régissent la recherche ordinaire. Si votre page est correctement indexée, structurée et correspond à l’intention de l’utilisateur, les données structurées que vous déployez pour Search sont les mêmes que celles utilisées par ces fonctionnalités.

Pour être honnête : les données structurées aident les systèmes d’IA à interpréter correctement votre contenu. Elles n’achètent pas une inclusion dans les réponses générées. Considérez-les comme un moyen de supprimer l’ambiguïté, non comme un levier de croissance.

Le problème de rendu pour les crawlers IA

Il s’agit du point technique à plus fort impact pour les développeurs frontend, et il est absent de la plupart des guides sur JSON-LD : les crawlers IA doivent généralement être traités comme des crawlers sans rendu, et les données structurées doivent donc être présentes dans la réponse HTML initiale.

GPTBot d’OpenAI récupère le HTML et n’exécute pas JavaScript côté client.
ClaudeBot d’Anthropic fonctionne comme un crawler HTTP standard sans exécution de JavaScript.
PerplexityBot lit également le HTML brut.

Googlebot fait exception : il effectue généralement le rendu JavaScript lors d’un passage différé, de sorte que le JSON-LD injecté côté client sera finalement traité pour Search. Les crawlers IA ne rattrapent pas ce délai. Si votre JSON-LD n’existe qu’après l’hydratation, il est invisible pour les systèmes que la plupart des utilisateurs interrogent désormais.

Un mode d’échec courant en production, observable dans de vraies applications frontend : un développeur ajoute du JSON-LD dans un hook useEffect, ou le pousse via Google Tag Manager. Le bloc apparaît dans le DOM rendu, le Rich Results Test (qui effectue le rendu) l’affiche comme valide, et l’équipe suppose que le travail est terminé. Pendant ce temps, chaque crawler sans rendu reçoit une réponse HTML dépourvue de toute donnée structurée.

La solution consiste à placer le bloc <script type="application/ld+json"> dans la réponse initiale du serveur.

Rendu serveur de JSON-LD par framework

Framework	Où placer le JSON-LD
Next.js App Router	`<script type="application/ld+json">` inline dans un Server Component, ou le champ `other` de la Metadata API
Next.js Pages Router	`<script>` inline dans `<Head>` depuis `next/head`, rendu dans les chemins `getServerSideProps`/`getStaticProps`
Nuxt 3	`useHead` avec une entrée `script`, appelé dans un contexte serveur
Astro	`<script type="application/ld+json">` inline directement dans le template `.astro` (statique par défaut, aucune exécution JavaScript requise)
SvelteKit	Bloc `<svelte:head>` contenant le script, rendu côté serveur

Le principe est identique quel que soit le stack : le bloc JSON-LD doit exister dans les octets renvoyés par le serveur, et non dans les octets ajoutés par le navigateur après le premier affichage.

Trois exemples fonctionnels de JSON-LD

Les exemples ci-dessous utilisent le vocabulaire Schema.org tel que défini dans la version 30.0, publiée le 19 mars 2026.

BlogPosting (un sous-type d’Article)

Dans la hiérarchie Schema.org, BlogPosting est un sous-type d’Article, qui est lui-même un sous-type de CreativeWork. Déclarer "@type": "BlogPosting" hérite implicitement de toutes les propriétés d’Article — inutile de déclarer les deux.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://openreplay.com/blog/json-ld-ai-search#article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://openreplay.com/blog/json-ld-ai-search"
  },
  "headline": "How JSON-LD Helps AI Understand Your Website",
  "description": "A frontend-focused guide to JSON-LD, Schema.org, and the server-rendering requirement for AI crawlers.",
  "image": "https://openreplay.com/images/blog/json-ld-ai-search.png",
  "datePublished": "2026-05-20T09:00:00-04:00",
  "dateModified": "2026-05-20T09:00:00-04:00",
  "author": {
    "@type": "Organization",
    "name": "OpenReplay Team",
    "url": "https://openreplay.com"
  },
  "publisher": {
    "@id": "https://openreplay.com/#organization"
  }
}
</script>

Utilisez ce balisage sur les pages d’articles longs. mainEntityOfPage relie l’article à son URL canonique ; dateModified est important car Google l’utilise lorsque la fraîcheur du contenu constitue un signal de requête.

Organization

Le type Organization décrit l’entité éditrice. Utilisez sameAs pour pointer vers des profils externes canoniques — c’est ainsi que les systèmes distinguent votre marque d’autres entités portant des noms similaires.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://openreplay.com/#organization",
  "name": "OpenReplay",
  "url": "https://openreplay.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://openreplay.com/images/logo.png",
    "width": 512,
    "height": 512
  },
  "sameAs": [
    "https://github.com/openreplay",
    "https://www.linkedin.com/company/openreplay",
    "https://x.com/OpenReplayHQ"
  ]
}
</script>

Déployez ce bloc une seule fois, sur l’ensemble du site — généralement dans l’en-tête du document de chaque page. Réutilisez le @id depuis d’autres blocs de schéma (comme le fait BlogPosting.publisher ci-dessus) afin qu’une définition canonique unique d’Organization soit référencée partout plutôt que dupliquée.

BreadcrumbList

BreadcrumbList décrit la position de la page dans la hiérarchie du site. Google prend en charge les résultats enrichis de fil d’Ariane, et ces mêmes données aident les systèmes d’IA à comprendre la structure du site.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://openreplay.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://openreplay.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "How JSON-LD Helps AI Understand Your Website"
    }
  ]
}
</script>

Le dernier élément omet item car il correspond à la page courante. position est indexé à partir de 1.

Maintenir la cohérence entre les données structurées et le contenu visible

Les directives de Google sur les données structurées sont explicites : le contenu du JSON-LD doit correspondre à ce qui est affiché sur la page. Baliser des avis qui n’existent pas sur la page, des prix qui n’y apparaissent pas, ou des noms d’auteurs qui contredisent les signatures visibles constitue un risque d’action manuelle. Les données structurées sont censées décrire la page, non l’enrichir avec des affirmations qui ne sont pas étayées dans le DOM.

Cela compte également pour les systèmes d’IA. Si votre texte visible dit une chose et votre JSON-LD en dit une autre, vous avez créé exactement le type d’ambiguïté que les données structurées sont censées résoudre.

Valider avant de mettre en production

Deux outils couvrent le flux de travail :

Outil	Vérifie	Idéal pour
Google Rich Results Test	L’éligibilité aux types de résultats enrichis pris en charge par Google	Vérification avant déploiement pour Article, Product, Breadcrumb, etc.
Schema Markup Validator	La conformité au vocabulaire Schema.org complet	Validation générale ; tout type que Google n’expose pas comme résultat enrichi

Le Rich Results Test effectue le rendu de la page (il voit donc le JSON-LD injecté côté client que les crawlers IA ne verront pas). Pour confirmer ce que les crawlers sans rendu reçoivent, exécutez curl -A "GPTBot" https://your-page sur votre URL et recherchez application/ld+json dans la réponse. Si le bloc n’est pas dans ce HTML brut, les crawlers IA ne le verront pas.

La section Améliorations de Google Search Console signale les erreurs d’analyse syntaxique et l’éligibilité pour les types de données structurées que Google suit. Utilisez-la pour la surveillance continue, et non comme substitut à la validation avant déploiement.

Note sur FAQPage

FAQPage reste un type Schema.org valide et Google continue de l’utiliser pour la compréhension du contenu. Cependant, Google indique dans sa documentation FAQPage que les fonctionnalités de recherche liées aux FAQ sont supprimées : les résultats enrichis FAQ ont cessé d’apparaître dans Search en mai 2026 ; le reporting dans Search Console et le support du Rich Results Test sont supprimés en juin 2026 ; le support de l’API Search Console suit en août 2026. Si vous choisissez un schéma à implémenter dès maintenant pour obtenir une visibilité accrue dans les résultats enrichis, FAQPage n’est pas la bonne réponse. Implémentez-le si vous disposez d’une véritable page FAQ et souhaitez en conserver la sémantique — non comme une tactique pour gagner de l’espace dans les SERP.

C’est également pour cette raison que validator.schema.org est la valeur sûre par défaut pour les travaux de validation à long terme : il ne dépend pas des fonctionnalités que Google choisit d’exposer comme résultats enrichis.

Par où commencer

Si vous partez de zéro, la séquence à plus forte valeur ajoutée est la suivante : un bloc Organization unique déployé sur l’ensemble du site, BreadcrumbList sur chaque page autre que la page d’accueil, et Article/BlogPosting sur les contenus éditoriaux. Effectuez le rendu serveur de l’ensemble. Validez avec les deux outils. Vérifiez ensuite la réponse HTML brute avec un user agent sans rendu pour confirmer que les crawlers IA reçoivent bien ce que vous avez écrit.

Les données structurées ne feront pas bouger les classements à elles seules et ne garantiront pas votre inclusion dans AI Overviews. Ce qu’elles font — de manière fiable, lorsqu’elles sont correctement déployées — c’est éliminer les approximations interprétatives qui amènent les moteurs de recherche et les systèmes d’IA à se méprendre sur votre contenu. Pour les équipes frontend, le travail qui compte le plus n’est pas de choisir quels types de schéma ajouter, mais de déterminer à quel stade du pipeline de rendu ils se trouvent. Placez le JSON-LD dans la réponse du serveur, et le reste est une question de contenu.

FAQ

Utilisez JSON-LD. Google le recommande explicitement plutôt que Microdata et RDFa, car il réside dans un bloc script unique découplé du DOM visible, ce qui signifie que vous pouvez générer et mettre à jour les données structurées sans toucher au balisage de mise en page. Les trois formats peuvent exprimer le vocabulaire Schema.org et sont analysés par Google, mais JSON-LD est plus facile à maintenir, plus facile à rendre côté serveur, et c'est le format utilisé par Google dans tous ses exemples de documentation sur les données structurées.

Oui. Google prend en charge plusieurs balises script distinctes sur une même page, ce qui est le modèle standard pour combiner des types tels qu'Organization, BreadcrumbList et BlogPosting. L'alternative consiste en un script unique contenant un tableau de graphe sous la clé @graph, où chaque entité possède son propre @id. Les deux approches sont valides ; le modèle @graph est plus propre lorsque les entités se référencent mutuellement via @id, car il conserve une définition canonique unique par entité.

Uniquement si le JSON-LD est présent dans la réponse initiale du serveur. Les SPA qui injectent des données structurées après l'hydratation sont invisibles pour les crawlers sans rendu tels que GPTBot, ClaudeBot et PerplexityBot. La solution consiste à utiliser le rendu côté serveur ou la génération statique pour les pages nécessitant des données structurées — via Next.js, Nuxt, Astro ou SvelteKit en mode SSR ou SSG — afin que la balise script existe dans les octets HTML avant toute exécution de JavaScript.

Mettez à jour dateModified uniquement lorsque le contenu substantiel de l'article change — corrections, nouvelles sections, faits mis à jour, exemples actualisés. Ne le modifiez pas à chaque déploiement ni pour des modifications cosmétiques telles que des corrections de fautes de frappe ou des ajustements de style. Google utilise dateModified comme signal de fraîcheur pour les requêtes sensibles au temps, et l'augmenter sans réel changement de contenu contredit la règle selon laquelle les données structurées doivent correspondre au contenu visible, ce qui constitue un risque d'action manuelle.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.