Données structurées pour les réponses d'IA : quoi baliser et comment
Les données structurées ne débloquent pas à elles seules les réponses d'IA, mais elles lèvent le doute sur les faits. Balisez l'éditeur comme une Organization avec des liens sameAs, chaque article avec author, datePublished et dateModified, les produits avec offers, le prix et la devise, et les sections de questions avec FAQPage. Utilisez du JSON-LD et gardez-le identique à ce que montre la page.
Un robot qui lit du HTML doit deviner qui a publié une page, quand elle a changé et combien coûte un produit. Le JSON-LD énonce ces faits explicitement, dans le vocabulaire schema.org. Google indique qu'aucun schéma particulier n'est nécessaire pour ses fonctions d'IA, et les autres éditeurs d'IA ne publient pas comment ils exploitent le balisage : l'objectif honnête est donc la clarté, pas une astuce de classement.
Sur cette page
Pourquoi les données structurées aident les réponses d'IA ?
Les réponses d'IA doivent souvent énoncer des faits : qui fabrique un produit, combien il coûte, si un article est à jour. Quand ces faits ne figurent que dans le texte courant, ils peuvent être mal lus ou mélangés à ceux d'autres pages. Le balisage donne un énoncé unique et cohérent de chaque fait, que n'importe quel analyseur peut lire.
Utilisez du JSON-LD quand vous le pouvez ; Google le recommande comme le format le plus simple à mettre en place et à maintenir. Et respectez la règle de base de Google : ne balisez pas d'informations qui ne sont pas visibles pour les utilisateurs sur la page, même si elles sont exactes.
Comment baliser mon organisation ?
Une Organization avec name, url, logo et sameAs indique à un robot qui se trouve derrière le site. schema.org définit sameAs comme l'URL d'une page de référence qui indique sans ambiguïté l'identité de l'élément, comme vos profils officiels ailleurs. Google suggère de la placer sur la page d'accueil ou sur une page « à propos » ; il n'est pas nécessaire de la mettre sur chaque page.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#org",
"name": "Example Co",
"url": "https://example.com/",
"logo": "https://example.com/logo.png",
"sameAs": [
"https://www.linkedin.com/company/example-co",
"https://github.com/example-co"
]
}
Donnez à l'organisation un @id stable pour que d'autres balisages de votre site, comme le publisher d'un article, puissent y faire référence. Ne listez dans sameAs que des profils que vous contrôlez. Des liens vers des pages concernant une autre entreprise au nom proche font le contraire de ce que vous voulez : ils brouillent l'identité que le balisage est censé clarifier.
Google liste aussi des propriétés facultatives comme description, legalName, contactPoint et address. Ajoutez celles qui sont vraies et stables ; laissez de côté tout ce que vous devriez mettre à jour à la main.
Que doit contenir le balisage Article ou BlogPosting ?
Pour les articles, les propriétés qui comptent le plus pour la confiance et la fraîcheur sont headline, author avec un name et une url qui identifie l'auteur, datePublished et dateModified. Google demande des dates au format ISO 8601 et recommande d'inclure un fuseau horaire.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "How to choose a clinic scheduling app",
"author": {"@type": "Person", "name": "Jane Doe", "url": "https://example.com/team/jane"},
"publisher": {"@id": "https://example.com/#org"},
"datePublished": "2026-10-01T09:00:00+00:00",
"dateModified": "2026-11-12T09:00:00+00:00",
"image": "https://example.com/img/scheduling.jpg"
}
Gardez dateModified honnête et cohérente. Utilisez la même date sur la page visible et dans le lastmod de votre sitemap, et ne la mettez à jour que lorsque le contenu change réellement.
Le balisage FAQPage vaut-il encore la peine ?
Soyons clairs sur ce qu'il ne fait plus. Google a cessé d'afficher les résultats enrichis FAQ dans Search et a supprimé la documentation de cette fonction. Le balisage FAQPage ne vous donnera donc pas de résultats FAQ enrichis dans Google.
Il reste un type schema.org valide qui associe chaque question à sa réponse sous une forme lisible par machine, ce qui est utile pour tout système qui analyse la page. Si votre page comporte déjà une section FAQ visible, la baliser coûte peu. N'ajoutez pas au balisage des questions qui ne figurent pas sur la page.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "Does the app work offline?",
"acceptedAnswer": {"@type": "Answer", "text": "Yes. Changes sync when the device is back online."}
}]
}
Comment baliser le prix d'un produit ou d'une application ?
On demande souvent aux assistants d'IA ce que coûte un produit, et un prix enfoui dans un tableau tarifaire se lit facilement de travers. Ajoutez offers avec price et priceCurrency à votre balisage Product ou SoftwareApplication. Google indique que price est obligatoire pour une offre et recommande priceCurrency ; une application gratuite doit indiquer un prix de 0.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Example Planner Pro",
"offers": {
"@type": "Offer",
"price": 19.00,
"priceCurrency": "USD",
"availability": "https://schema.org/InStock"
}
}
Comment vérifier que mon balisage est bien lu ?
- Chaque bloc JSON-LD doit être du JSON valide. Une seule virgule en trop et les analyseurs ignorent tout le bloc.
- Placez le JSON-LD dans le HTML initial. Un balisage injecté par JavaScript peut échapper aux robots qui n'exécutent pas de scripts.
- Comparez le balisage avec la page visible : noms, prix et dates doivent correspondre exactement.
- Vérifiez que la page qui porte le balisage n'est pas bloquée pour les robots d'IA par le robots.txt ou un pare-feu ; un balisage sur une page inaccessible n'aide personne.
- Reliez les éléments connexes par des références
@idplutôt que de les répéter, afin que l'éditeur dans le balisage de votre article et votre balisage Organization soient clairement la même entité. - Générez les dates et les prix à partir des mêmes données que celles qui alimentent la page visible, pour qu'ils ne puissent pas diverger après une mise à jour.
AISeeWhy analyse le JSON-LD de votre page et signale les blocs invalides, l'éditeur ou le sameAs manquants, les données d'article incomplètes, le balisage d'application ou de produit sans prix, et les intertitres de questions sans balisage FAQ correspondant, avec un extrait prêt à l'emploi pour chaque correctif.
Questions fréquentes
Ai-je besoin de données structurées pour apparaître dans les AI Overviews de Google ?
Non. Google indique qu'aucune donnée structurée schema.org particulière n'est nécessaire pour les AI Overviews ou le mode IA. Le balisage aide quand même à lever toute ambiguïté sur des faits comme les dates et les prix.
JSON-LD, Microdata ou RDFa ?
Tous sont valides, mais Google recommande le JSON-LD quand votre configuration le permet, car il est plus facile à ajouter et à maintenir séparément du HTML visible.
Chaque page doit-elle avoir un balisage Organization ?
Google suggère de le placer sur la page d'accueil ou sur une seule page qui décrit l'organisation. Les autres pages peuvent y faire référence par son @id.
Les données structurées remplacent-elles un bon contenu ?
Non. Le balisage énonce des faits sur la page ; il ne rend pas fort un mauvais texte de réponse. Les réponses d'IA citent toujours le texte visible : la page doit donc bien répondre à la question par elle-même.
Puis-je baliser du contenu caché aux visiteurs ?
Non. Les consignes de Google disent de ne pas baliser d'informations qui ne sont pas visibles pour les utilisateurs, même si elles sont exactes.
Sources
- Google Search Central : introduction aux données structurées
- Google Search Central : données structurées Organization
- Google Search Central : données structurées Article
- Google Search Central : données structurées d'extrait de produit
- Google Search Central : données structurées FAQ (avis de dépréciation)