Schema.org pour le grounding LLM: ce qui est pris au sérieux, ce qui ne l'est pas

---

Schema.org regorge de types. Le vocabulaire complet en compte plus de huit cents. La majorité n’est jamais utilisée par les moteurs. Une minorité est lue activement et influence le grounding. Cette tactique fait le tri en avril 2026, en s’appuyant sur les comportements observables des moteurs génératifs principaux.

Pourquoi Schema.org resté pertinent

Le balisage Schema.org sert deux objectifs distincts. Le premier est la génération d’extraits enrichis dans les SERP classiques (étoiles d’avis, prix, dates, miettes de pain). Le second, plus récent, est de fournir aux moteurs génératifs un contexte d’extraction fiable. Quand un modèle de langage doit citer une page, il a intérêt a savoir qui en est l’auteur, quand elle a été publiée, a quelle organisation elle est rattachee. Schema.org le lui dit.

Pour le GEO, le second objectif est devenu le plus important. Une page bien balisee ne se contente plus d’avoir des étoiles dans Google. Elle alimente le grounding de Perplexity, ChatGPT Search, AI Mode, Claude, et les rend plus surs de la citer.

Les types qui marchent

Quatre types ressortent comme les plus utilisés par les moteurs génératifs, sur la base d’observations menees sur un panel de cinq cents pages françaises en mars 2026.

Article. Le type Article (et ses sous-types NewsArticle, BlogPosting, TechArticle) est le plus solide. Les propriétés lues en pratique sont author, datePublished, dateModified, headline, description, image et publisher. La propriété author renvoyant explicitement vers une entite Person, elle-même reliee par sameAs a un profil LinkedIn ou Wikidata, est un signal fort. Les pages dont l’auteur est une simple chaîne de caracteres ont moins de poids que celles dont l’auteur est une entite construite.

Organization. Le type Organization, place sur la page d’accueil ou dans les en-têtes JSON-LD globaux, sert a identifier la marque éditrice. Les propriétés utilisées sont name, foundingDate, founder, sameAs, address, et numberOfEmployees. Le sameAs vers Wikidata, quand l’organisation y a une fiche, ferme la boucle d’identification. Le moteur génératif peut alors associer toute citation de la marque a une entite verifiee.

Person. Le type Person s’applique aux auteurs et aux figures publiques mentionnées dans le contenu. La présence de Person sur les pages auteurs, avec jobTitle, worksFor, sameAs, alumniOf, est un facteur de crédibilité éditoriale alignée sur le E-E-A-T. Les magazines qui balisent sérieusement leurs auteurs envoient un signal de transparence que les moteurs génératifs interpretent positivement.

FAQPage. Le type FAQPage resté utile, malgre la suppression de son rendu enrichi dans les SERP Google en 2023. Les moteurs génératifs continuent de le lire et de l’utiliser comme source de paires question-réponse extractibles. Sur Perplexity en particulier, les pages bien balisees FAQPage ressortent régulièrement comme sources directes pour des requêtes formulees comme questions.

Les types tolerables mais peu rentables

Certains types sont produits par les CMS et plugins SEO, mais leur effet réel sur le grounding est marginal.

BreadcrumbList. Utile pour le rendu SEO classique (miettes de pain dans la SERP), peu mobilise par les moteurs génératifs. Le maintenir si on l’a, ne pas y consacrer un effort spécifique pour le GEO.

WebSite avec SearchAction. Le potentiel sitelinks search box est génère par Google a partir de cette propriété. Pour les moteurs génératifs, l’effet est nul.

HowTo. Le type HowTo a perdu son rendu enrichi pour la majorité des verticales en 2023. Il continue d’être lu par certains moteurs, mais l’effet est faible. Le maintenir uniquement si la page est réellement structurée en étapes ordonnees, sinon le retirer pour éviter le bruit.

Review et AggregateRating. Ces types sont consommes par les moteurs génératifs quand ils sont coherents avec d’autres sources (présence de la marque sur Trustpilot, Google Business, etc.). Isolés, sans validation externe, leur poids est faible. La sur-optimisation est suspecte : un AggregateRating de 4.9 sur cinq cents avis sans présence externe correspondante est filtre.

Les types qui n’apportent rien

Beaucoup de types Schema sont produits par defaut par certains plugins, alors qu’ils n’ont aucun effet observable.

WebPage place sur chaque page individuelle (le simple fait de déclarer qu’une page est une WebPage n’apporte rien sans propriétés spécifiques). SiteNavigationElement, SpeakableSpecification, ItemList sur des contenus non listables. Ces declarations alourdissent le code sans benefice. Une bonne hygiene consiste a les retirer.

Le cas particulier du sameAs

La propriété sameAs mérite une attention spécifique parce qu’elle est centrale pour le grounding entite.

sameAs établit un lien explicite entre l’entite declaree sur le site (une Organization, une Person, un Place) et la même entite ailleurs sur le web : Wikidata, Wikipedia, LinkedIn, Crunchbase, profils officiels sur les réseaux sociaux. Le moteur génératif qui rencontre cette déclaration peut alors croiser les informations de plusieurs sources et constituer une représentation consolidee de l’entite.

Un sameAs vers Wikidata est particulièrement fort, comme l’analyse notre tactique sur les entités Wikidata. Wikidata est un graphe ouvert, multilangue, structure, que la majorité des moteurs génératifs utilisent comme référence de grounding. Quand une page déclare en JSON-LD "sameAs": "https://www.wikidata.org/entity/Q12345", elle fournit au moteur l’identifiant canonique de l’entite. Le moteur n’a plus a desambiguiser : l’entite est nommée.

Pour une marque qui n’a pas encore de fiche Wikidata, en créer une est l’investissement structurel le plus rentable en termes de grounding. Solene Marchais détaillé la procédure dans un autre article de la rubrique. Une fiche Wikidata propre, avec quelques sources vérifiables, prend trois a cinq heures de travail bien fait. L’effet est durable.

Le format JSON-LD versus microdata

Sur la question du format, le consensus est établi : JSON-LD est préférable a Microdata et a RDFa. Les moteurs lisent les trois, mais JSON-LD est plus simple a maintenir et a debugger. Il se place dans le <head> ou en fin de <body>, séparé du markup HTML, ce qui évite les pollutions accidentelles lors de modifications de présentation.

Le piège classique est la duplication. Un site qui a a la fois du JSON-LD génère par un plugin SEO, du microdata herite d’un thème ancien, et un schema d’organisation déclare sur chaque page peut envoyer des informations contradictoires aux moteurs. Le menage est utile.

Les pièges des plugins automatiques

Beaucoup de plugins WordPress ou Shopify generent du Schema.org de manière automatique. La qualité est inegale. Trois pièges classiques meritent d’être signales.

Le premier piège est le schema generique. Le plugin déclare toutes les pages comme WebPage, sans différenciation. C’est techniquement correct, mais inutile. Article, NewsArticle, BlogPosting, ProductPage donnent au moteur des signaux differencies que WebPage ne donne pas.

Le deuxième piège est l’author chaîne simple. Le plugin déclare author comme une chaîne “Jean Dupont” au lieu d’un objet Person avec ses sameAs. Cela perd l’opportunité de relier l’auteur a son graphe d’entites. La correction demande une configuration de plugin (souvent disponible mais mal exposee).

Le troisième piège est la non-coherence entre le contenu visible et le balisage. Un produit affiche en page a une note de quatre étoiles, mais le balisage AggregateRating déclare 4.9. Les moteurs verifient cette coherence et penalisent les écarts.

Une politique éditoriale pragmatique

Pour conclure, une politique pragmatique de balisage Schema.org en avril 2026 tient en cinq points. Baliser systématiquement Article sur les pages de contenu éditorial. Maintenir un Organization unique global avec sameAs vers Wikidata. Construire des entrees Person pour chaque auteur régulier. Garder FAQPage la ou les paires question-réponse sont réelles. Laisser tomber le reste, ou ne le maintenir que si le rendu SEO classique l’exige.

C’est un programme exigeant mais limite. Il vaut mieux faire ces cinq éléments proprement que produire une couche de balisage exhaustive et incoherente. Les moteurs génératifs valorisent la coherence plus que l’exhaustivite. Une page claire avec quatre types Schema bien faits a plus de poids qu’une page bardee de quinze types desordonnes.

Questions frequentes

Les questions les plus posees a la redaction sur ce sujet, avec des reponses courtes verifiables.

1. Quels types Schema.org sont vraiment utilises par les moteurs IA ?

   Quatre types principaux: Article (auteur, date, organization), Organization (entite marque), Person (auteur, dirigeant), FAQPage (paires question-reponse). Les autres types Schema sont souvent produits par les CMS mais peu lus par les moteurs generatifs.

2. Le sameAs vers Wikidata est-il vraiment important ?

   Oui, c'est un des signaux les plus forts. La propriete sameAs avec un identifiant Wikidata permet aux moteurs de desambiguiser une entite avec certitude. Pour une marque, ne pas avoir ce sameAs equivaut a se priver d'un grounding fiable.

3. Faut-il deployer FAQPage sur toutes les pages ?

   Non, uniquement sur les pages qui contiennent reellement des paires question-reponse pertinentes. FAQPage abusivement deploye sur des sections marketing degrade la qualite percue de la marque par les moteurs et peut etre ignore.

4. Le balisage Schema remplace-t-il un bon contenu textuel ?

   Non. Schema.org renforce un contenu deja bien ecrit, il ne le remplace pas. Une page sans contenu textuel solide mais avec un Schema parfait ne sera pas mieux citee. Le contenu vient en premier, le balisage en second.

5. Les nouveaux types Schema (sortie en 2025-2026) sont-ils consommes ?

   Pas par les moteurs generatifs majeurs en avril 2026. Les nouveaux types prennent du temps a etre integres dans les pipelines. Les types stables depuis plusieurs annees (Article, Person, Organization) restent les plus surs.

6. Peut-on cumuler plusieurs schemas sur une meme page ?

   Oui, et c'est meme recommande. Une page article peut cumuler Article (le contenu), Person (l'auteur), Organization (le site), FAQPage (la section FAQ). Les schemas se completent sans interferer.