Intégrer les schemas JSON-LD pour être cité par les AI Overviews (guide technique)

Intégrer un schema JSON-LD consiste à ajouter, dans le code de la page, une description structurée du contenu que les moteurs et les agents IA peuvent lire sans avoir à l’interpréter visuellement. Cinq types couvrent l’essentiel d’un site éditorial ou marchand : Article, FAQPage, Product, HowTo et Organization, chacun avec ses propres champs recommandés par Google. Le marquage ne garantit pas une citation dans les AI Overviews, mais il supprime l’ambiguïté que Google et les modèles de langage doivent sinon deviner dans le texte brut. Ce guide donne le code exact à copier pour chaque type, l’endroit où le placer dans la page, et la manière de le tester avant publication.

Intégrer un schema pour AI Overviews : ce que ça change vraiment (et ce que ça ne garantit pas)

Un script JSON-LD ne rend rien à l’écran. Il décrit, dans le vocabulaire de schema.org, les entités de la page (un article, un produit, une organisation) avec des champs nommés et typés, là où le texte visible laisse Google deviner ces mêmes informations à partir de la mise en page. C’est cette différence, lisible par une machine contre devinée par une machine, qui justifie l’intégration, pas une promesse de visibilité automatique.

Il faut d’ailleurs être honnête sur ce dernier point. Une étude a suivi 1 885 pages ayant ajouté un balisage JSON-LD entre août 2025 et mars 2026, comparées à 4 000 pages témoins restées sans schema. Résultat : aucune hausse mesurable des citations dans les AI Overviews, Google AI Mode ou ChatGPT, et même un recul de 4,6 % des citations AI Overview sur les pages ayant ajouté le schema, un écart jugé statistiquement significatif. Ajouter un schema ne fait donc pas mécaniquement citer une page. Ce qui fait citer une page, ce sont des critères de contenu et de structure détaillés dans l’article sur les leviers qui font vraiment citer une page : le schema, lui, est une couche technique qui vient après.

Ce que fait réellement le JSON-LD

Concrètement, un bloc JSON-LD est un <script type="application/ld+json"> placé dans le code source, invisible pour le visiteur. Google recommande ce format plutôt que les microdonnées ou RDFa parce qu’il reste séparé du HTML visible : on ne mélange pas des attributs dans les balises, on écrit un objet JSON autonome. C’est ce bloc qui permet à Google de rattacher sans ambiguïté un auteur, une date, un prix ou une note à la bonne entité, et qui alimente aussi bien les rich results encore actifs que la compréhension générale de la page par les systèmes qui s’appuient sur l’index de Google.

Ce que montre une étude récente sur la citation dans les AI Overviews

Le chiffre de 4,6 % cité plus haut mérite d’être relativisé plutôt qu’ignoré. Il ne dit pas que le schema est inutile : il dit que l’ajouter sans rien changer d’autre à une page ne produit pas de gain de citation. Le JSON-LD reste la bonne pratique pour éliminer les erreurs de parsing, débloquer les rich results qui existent toujours (Product, étoiles de notation, fil d’Ariane) et donner un signal d’entité propre pour l’auteur et l’organisation. C’est un prérequis d’hygiène technique, pas un levier de citation à lui seul.

Schema Article JSON-LD : les champs qui comptent pour un contenu éditorial

Pour le type Article, la documentation de Google ne liste aucun champ strictement obligatoire : elle recommande d’ajouter les propriétés qui s’appliquent au contenu. Dans les faits, cinq champs conditionnent l’éligibilité aux rich results d’article et trois autres, issus du vocabulaire schema.org standard, restent utiles pour tout système qui lit la page, y compris un agent IA.

Les propriétés recommandées par Google (headline, image, dates, auteur, éditeur)

• headline : le titre de l’article, tronqué par Google au-delà d’une certaine longueur, donc à garder concis.
• image : une ou plusieurs images représentatives, idéalement en 16:9, 4:3 et 1:1.
• datePublished et dateModified : au format ISO 8601 avec le fuseau horaire.
• author : un objet Person ou Organization avec au minimum name et url, un auteur par champ author distinct s’il y en a plusieurs.
• publisher : le nom et le logo du site, à ne jamais confondre avec le nom de l’auteur.
• description et articleBody : propriétés schema.org standard, moins regardées par le test de rich results de Google, mais qui donnent à un système de lecture automatique un résumé et le corps du texte sans avoir à le réextraire du HTML.

Exemple de schema article json-ld prêt à copier

Le générateur JSON-LD du site remplit cette structure sans écrire une ligne de code ; voici le résultat pour un article de blog type.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Titre de l'article, environ 110 caractères maximum",
  "image": [
    "https://www.exemple.fr/images/article-16x9.jpg",
    "https://www.exemple.fr/images/article-4x3.jpg",
    "https://www.exemple.fr/images/article-1x1.jpg"
  ],
  "datePublished": "2026-10-07T08:00:00+02:00",
  "dateModified": "2026-10-07T08:00:00+02:00",
  "author": {
    "@type": "Person",
    "name": "Prénom Nom",
    "url": "https://www.exemple.fr/a-propos/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Nom du site",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.exemple.fr/logo.png"
    }
  },
  "description": "Résumé de l'article en une phrase.",
  "articleBody": "Le texte complet ou un extrait représentatif de l'article."
}
</script>

Schema FAQPage : ce qui a changé en 2026 (et pourquoi le garder quand même)

Le schema faqpage associe des questions à leurs réponses dans un format que Google a longtemps affiché en accordéon directement dans les résultats de recherche. Ce comportement a disparu, en deux temps.

Pourquoi le rich result FAQ a disparu de Google Search

En août 2023, Google avait déjà restreint ce rich result aux seuls sites gouvernementaux et de santé reconnus comme autoritaires, à la suite d’abus massifs de la part de sites qui ajoutaient des FAQ génériques dans le seul but de gagner de la place dans les résultats. Le 7 mai 2026, Google a supprimé la fonctionnalité pour l’ensemble des sites restants, y compris cette exception. La documentation officielle du type FAQPage a elle-même été retirée en juin 2026, avec la mention explicite que le rich result n’apparaît plus dans Google Search. Le type FAQPage reste un vocabulaire schema.org parfaitement valide, il ne cause aucune erreur de validation, mais il n’offre plus la visibilité en SERP qui en faisait l’intérêt initial.

Exemple de schema faqpage et les cas où il reste utile

Garder ce schema a du sens quand la page contient une vraie FAQ éditoriale (pas une FAQ ajoutée uniquement pour le marquage) : il structure proprement les questions et réponses pour tout système de lecture automatique, y compris un agent IA qui cherche à extraire une réponse précise d’une page, même sans rich result dédié dans la SERP classique.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Le schema FAQPage sert-il encore a quelque chose en 2026 ?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Il ne produit plus de rich result dans Google Search depuis mai 2026, mais il reste un vocabulaire schema.org valide qui structure les questions et réponses d'une page pour tout système qui la lit."
      }
    }
  ]
}
</script>

Schema Product ecommerce : les champs qui débloquent les rich results

Sur une fiche produit, le schema product ecommerce suit une règle plus stricte que l’Article : le champ name est obligatoire, et il faut en plus au moins l’un des trois champs review, aggregateRating ou offers pour que la page soit éligible aux rich results produit.

Name, offers, aggregateRating : au moins une de ces trois preuves

• name : seul champ strictement requis, le nom du produit.
• offers : prix, devise et disponibilité, sous la forme d’un objet Offer ; c’est aussi la condition pour être éligible à l’affichage d’une baisse de prix.
• aggregateRating : note moyenne et nombre d’avis, à ne renseigner que si de vrais avis existent réellement sur la page, Google considère une note affichée sans preuve comme une pratique trompeuse.
• brand, image, sku : non obligatoires mais recommandés pour enrichir l’affichage.

Exemple de schema product ecommerce prêt à copier

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Nom du produit",
  "image": "https://www.exemple.fr/images/produit.jpg",
  "brand": {
    "@type": "Brand",
    "name": "Nom de la marque"
  },
  "offers": {
    "@type": "Offer",
    "price": "49.90",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "url": "https://www.exemple.fr/produit/"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "128"
  }
}
</script>

Schema HowTo et Organization : statut et bonnes pratiques

Ces deux types répondent à des logiques opposées : l’un a perdu sa visibilité en SERP il y a trois ans, l’autre n’a jamais eu de rich result dédié mais reste la base de toute reconnaissance d’entité par Google.

HowTo, un rich result disparu depuis 2023

Le carrousel d’étapes du type HowTo a été retiré par Google en septembre 2023, sur desktop comme sur mobile, sans exception ni condition d’éligibilité restante : la fonctionnalité n’existe simplement plus. Ajouter ce schema ne produit aucune pénalité, mais ne produit plus aucun effet visible non plus. Il garde un intérêt marginal pour structurer une suite d’étapes (step, avec un name, un text et une image par étape) à destination d’un système qui lirait la page sans passer par le rendu visuel, mais ce n’est plus une priorité d’implémentation.

Organization et sameAs, pour l’entité et le knowledge panel

Le schema Organization n’a lui non plus aucun champ strictement obligatoire, mais c’est celui qui rapporte le plus pour un effort minime. Il relie le site à une entité unique reconnue par Google : name, url, un logo d’au moins 112 x 112 pixels, et surtout sameAs, la liste des profils (réseaux sociaux, pages de référence) qui confirment qu’il s’agit bien de la même organisation ailleurs sur le web. C’est ce signal d’entité, combiné à celui de l’auteur dans le schema Article, qui aide le plus à faire reconnaître qui publie le contenu, un critère que les systèmes d’IA générative pèsent autant que Google dans leur confiance envers une page.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Nom du site",
  "url": "https://www.exemple.fr/",
  "logo": "https://www.exemple.fr/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/exemple",
    "https://www.youtube.com/@exemple"
  ]
}
</script>

Où se place le JSON-LD dans la page et comment Google le lit ?

La position du bloc dans le document n’a pas d’effet fonctionnel : Google ne favorise ni ne pénalise un schema selon qu’il se trouve dans le head ou juste avant la fermeture du body. Ce qui compte, c’est qu’il soit présent dans le DOM final, après exécution du JavaScript s’il est injecté dynamiquement.

Dans le head ou en fin de body : les deux emplacements valides

Par convention, la plupart des extensions SEO WordPress (Yoast, RankMath) injectent le JSON-LD via le hook wp_head, donc dans le head du document. Un thème peut tout aussi bien l’écrire via wp_footer, juste avant la balise fermante du body : Google l’extrait de la même manière dans les deux cas. Le seul vrai impératif est de ne pas dupliquer le même type de schema à deux endroits différents de la page avec des valeurs contradictoires.

Comment Googlebot extrait le schema sans toucher au rendu visible

Googlebot récupère la page, la fait passer par un moteur de rendu proche de Chrome pour obtenir le DOM final, puis exécute une extraction séparée de tous les blocs <script type="application/ld+json"> présents dans ce DOM. Cette extraction ne modifie rien à ce que voit l’internaute : elle alimente une couche de compréhension structurée, utilisée pour les rich results encore actifs et pour attacher la page aux entités de son index, en parallèle du rendu visuel classique.

Tester et valider son schema JSON-LD avant publication

Deux outils gratuits suffisent, et il vaut mieux utiliser les deux plutôt qu’un seul, car ils ne vérifient pas la même chose.

Rich Results Test et validateur Schema.org

• Rich Results Test (search.google.com/test/rich-results) : on colle l’URL ou le code, et l’outil indique si la page est éligible à l’un des rich results encore pris en charge par Google, avec le détail des erreurs et des avertissements sur les champs manquants.
• Validateur Schema.org (validator.schema.org) : il vérifie la conformité pure au vocabulaire schema.org, y compris pour les types que Google n’affiche plus en rich result (FAQPage, HowTo) ou qu’il ne teste pas (Organization en tant que tel), ce que le Rich Results Test ne couvre pas.

Les erreurs qui invalident le schema

• Une erreur de syntaxe JSON : virgule en trop avant une accolade fermante, guillemet non refermé, accolade manquante.
• Un @type imbriqué absent, par exemple un author sans "@type": "Person".
• Une URL relative là où schema.org attend une URL absolue, notamment pour image, url et logo.
• Deux blocs JSON-LD qui décrivent la même entité avec des valeurs différentes sur la même page.
• Un dateModified qui n’est jamais mis à jour alors que le contenu a changé.
• Un aggregateRating affiché sans aucun avis réel visible sur la page : Google qualifie cette pratique de trompeuse et peut la sanctionner par une action manuelle.