Schema.org et FAQPage : le b.a.-ba pour l'IA générative
Quels types de balisage JSON-LD déployer, comment relier les entités entre elles, et pourquoi FAQPage reste utile même sans rich result dans Google.
Par Yoann Uzan — publié le , mis à jour le .
En bref
- Les données structurées ne déclenchent pas une citation, mais elles suppriment l'ambiguïté : elles disent à la machine qui parle, de quoi, et depuis quand.
- Quatre types couvrent l'essentiel d'un site professionnel : Organization, Person, Article et FAQPage, complétés par BreadcrumbList sur les pages profondes.
- FAQPage conserve un intérêt pour les moteurs génératifs même depuis la restriction de ses rich results dans les résultats Google classiques.
Le rôle réel des données structurées
Les données structurées Schema.org sont une description machine de la page, en JSON-LD. Elles n'améliorent pas la qualité du texte, mais elles permettent à un moteur d'identifier sans ambiguïté l'organisation, l'auteur, la date et le type de contenu — trois informations qu'un modèle vérifie avant de citer.
Un moteur génératif prend un risque quand il cite : celui d'attribuer une information à la mauvaise source. Tout ce qui réduit ce risque augmente mécaniquement la probabilité de citation. Le balisage est l'outil le plus direct pour cela.
Règle absolue : le balisage doit décrire ce qui est réellement visible sur la page. Un JSON-LD qui affirme une note moyenne absente du contenu, ou une FAQ qui n'existe pas dans le HTML, dégrade la confiance et expose à des sanctions côté moteurs classiques.
Les types à déployer en priorité
Sur un site professionnel, quatre types couvrent l'essentiel : Organization pour l'entité éditrice, Person pour chaque auteur, Article pour les contenus éditoriaux et FAQPage pour les blocs de questions. BreadcrumbList s'ajoute sur les pages profondes pour exprimer la hiérarchie.
| Type | Où le placer | Ce qu'il apporte |
|---|---|---|
| Organization | Toutes les pages | Identité de l'éditeur, contact, profils officiels |
| Person | Pages auteur et articles | Attribution de l'expertise à un humain identifiable |
| Article | Articles de blog | Titre, dates de publication et de mise à jour, auteur |
| FAQPage | Pages et sections FAQ | Paires question / réponse directement extractibles |
| BreadcrumbList | Pages profondes | Position de la page dans l'arborescence |
| Product / Course / LocalBusiness | Selon le métier | Attributs métier comparables |
Relier les entités avec @id
Un balisage isolé décrit une page ; un graphe relié décrit une marque. En attribuant des @id stables à l'Organization, au WebSite et aux Person, puis en les référençant depuis chaque Article, on construit un graphe cohérent que les moteurs peuvent parcourir sans deviner.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Titre de l'article",
"datePublished": "2026-07-24",
"dateModified": "2026-08-24",
"author": { "@type": "Person", "name": "Prénom Nom", "url": "https://exemple.com/a-propos" },
"publisher": { "@type": "Organization", "name": "Nom de la marque", "url": "https://exemple.com" }
}Le même identifiant doit être réutilisé partout : une Organization déclarée avec trois noms légèrement différents produit trois entités distinctes aux yeux d'un moteur, et dilue l'autorité au lieu de la concentrer.
FAQPage : encore utile en 2026 ?
Oui. Google a fortement restreint l'affichage des rich results FAQ dans ses résultats classiques, mais le balisage FAQPage reste une source propre de paires question / réponse pour les moteurs génératifs, qui y trouvent des réponses courtes déjà isolées de la mise en page.
La disparition d'un affichage enrichi ne signifie pas la disparition de l'usage des données. Un bloc FAQPage bien rédigé fournit exactement ce que cherche un modèle : une question formulée comme un utilisateur la pose, et une réponse autonome de quelques phrases.
Deux règles : les questions doivent être celles que posent réellement vos clients, et les réponses doivent être intégralement présentes dans le HTML visible, pas uniquement dans le JSON-LD.
Valider et maintenir
Un balisage se valide avec le test des résultats enrichis de Google et le validateur schema.org, puis se surveille dans le temps : chaque refonte de template casse silencieusement une partie du JSON-LD si aucun contrôle automatique n'est en place.
- Valider chaque type de page, pas seulement la page d'accueil.
- Vérifier la cohérence entre dateModified et la date affichée à l'écran.
- Contrôler le balisage après chaque mise en production de template.
- Supprimer les types obsolètes plutôt que de les laisser en erreur.
Questions fréquentes
Le JSON-LD suffit-il, ou faut-il du microdata ?
Le JSON-LD suffit et reste le format recommandé : il est séparé du HTML, plus simple à maintenir et compris par tous les moteurs.
Peut-on cumuler plusieurs types sur une même page ?
Oui, c'est même souhaitable : un article peut porter Article, BreadcrumbList et FAQPage simultanément, à condition que chaque type décrive un contenu réellement présent.