Données structurées : quels types choisir pour booster votre site

Un client m'envoie un mail l'autre jour : « On a mis du schema partout, on est bons, non ? » Je jette un œil à son site. Trois balisages Organization différents sur la même page d'accueil, un Article sur une page catégorie, un LocalBusiness sur une page qui parle de livraison nationale. Et zéro rich result en trois mois. Le problème n'était pas la quantité de données structurées — c'était le choix des types.

C'est la question qu'on me pose le plus souvent quand on parle de référencement technique : quels types de données structurées choisir pour son site ? Et la réponse honnête, c'est qu'il n'existe pas de liste universelle. Il existe un arbre de décision, qui dépend du type de page, de ce que Google accepte réellement d'afficher, et de votre capacité à tenir le balisage à jour. Voilà comment je procède concrètement.

Quel type de données structurées choisir pour votre site ?

La règle de base tient en une phrase : choisissez le type qui décrit ce qu'il y a sur la page, pas celui qui vous fait le plus rêver. Un article de blog, c'est un Article. Une fiche produit, c'est un Product. Une page qui présente une entreprise avec adresse et horaires, c'est un LocalBusiness. Point.

Sauf que dans la vraie vie, une page fait souvent plusieurs choses à la fois. Une page produit contient aussi un fil d'Ariane, parfois des avis, parfois une FAQ. Et là commence le vrai travail d'arbitrage.

L'arbre de décision que j'utilise systématiquement

Avant d'écrire une ligne de JSON, je réponds à trois questions : de quel type de contenu s'agit-il, ce type est-il éligible à un rich result chez Google, et ai-je toutes les propriétés obligatoires sous la main ? Si la troisième réponse est non, je ne balise pas. Un balisage incomplet passe les validateurs mais ne produit rien.

Le tableau ci-dessous, c'est celui que je dégaine à chaque audit. Il liste ce que Google sait encore afficher, et ce qui relève du décor.

Type de page	Type Schema.org	Propriétés obligatoires	Effet SERP attendu
Article de blog / actu	Article, NewsArticle	headline, datePublished, author, image	Oui — carte enrichie, Discover
Fiche produit	Product + Offer	name, image, offers (price, priceCurrency, availability)	Oui — prix, stock, étoiles
Page entreprise	Organization	name, url, logo	Indirect (Knowledge Panel, logo dans les résultats mobiles)
Commerce local	LocalBusiness	name, address, telephone, openingHours	Indirect + fiche locale
Navigation	BreadcrumbList	itemListElement avec position, name, item	Oui — fil affiché dans l'URL
Questions fréquentes	FAQPage	mainEntity → Question / Answer	Très limité depuis les restrictions sur les sites gouvernementaux et de santé
Événement	Event	name, startDate, location	Oui — dates en SERP
Recette	Recipe	name, image, recipeIngredient, recipeInstructions	Oui — carrousel, temps de cuisson

Deux choses sautent aux yeux dans ce tableau. D'abord, FAQPage a perdu l'essentiel de son intérêt : Google n'affiche plus les accordéons de questions que sur un périmètre restreint. Ensuite, Organization ne génère pas de carte enrichie au sens strict, mais c'est lui qui alimente le logo dans les résultats mobiles et la compréhension de votre entité. Ça vaut le coup, ne serait-ce que pour ça.

Les types à baliser en priorité (et ceux qu'on peut ignorer)

Franchement, la majorité des sites n'ont pas besoin de plus de quatre types. J'ai audité une plateforme e-commerce l'an dernier qui avait implémenté onze types différents — dont Course et HowTo sur des pages qui n'avaient rien à voir. Résultat après nettoyage : le nombre de pages avec rich results valides est passé de 340 à 1 200. On avait retiré du bruit qui masquait les vraies erreurs dans la Search Console.

Product, Offer et AggregateOffer : le trio e-commerce

Sur une fiche produit, le type Product seul ne suffit pas. C'est Offer qui porte le prix, la devise et la disponibilité — c'est lui qui déclenche l'affichage. Et quand plusieurs vendeurs proposent le même article, on bascule sur AggregateOffer, avec lowPrice et highPrice. J'ai vu des équipes passer à côté d'une fourchette de prix affichée en SERP simplement parce qu'elles avaient mis un Offer unique sur une page qui comparait cinq revendeurs.

• Le prix doit être strictement identique au prix affiché à l'utilisateur, pas au prix remisé en base de données
• La disponibilité (InStock, OutOfStock) doit suivre le stock réel, pas une valeur figée
• Une note d'avis sans reviewCount ne s'affiche pas — et un avis inventé vous expose
• Le balisage doit être régénéré au rendu, jamais en dur dans un template

Organization et LocalBusiness : deux rôles distincts

Confusion classique. Organization décrit votre entité, LocalBusiness décrit un point de vente physique. Une chaîne de restaurants a besoin des deux : un Organization sur la page d'accueil, un LocalBusiness différent sur chaque page d'établissement, avec adresse, téléphone et horaires propres. Si vous mettez trois LocalBusiness sur une même page en espérant couvrir plusieurs agences, Google en ignorera deux.

Et le BreadcrumbList ? C'est le seul type que je pose systématiquement sur tous les sites, sans exception. Peu de propriétés, un rendu visible dans l'URL des résultats, un coût de maintenance quasi nul. Le meilleur rapport effort / bénéfice du lot, de mon point de vue.

Les pièges qui coûtent vraiment cher

Le pire scénario que j'ai rencontré : un site de formation qui balisait chaque page en Course avec des avis à cinq étoiles générés par un plugin. Les avis n'apparaissaient nulle part sur la page. Google n'a pas attendu longtemps. Action manuelle pour spammy structured markup, disparition des étoiles sur tout le domaine pendant près de deux mois. Le plugin coûtait 49 euros par an. La perte de trafic, elle, s'est comptée en dizaines de milliers de visites.

Voilà les erreurs que je vois le plus souvent :

1. Balisage qui ne correspond pas au contenu visible (avis, prix, notes)
2. Types inadaptés posés par des extensions qui ajoutent du schema à toutes les pages sans distinction
3. Données de test ou de préproduction laissées en production
4. Un Article sur des pages catégories qui ne contiennent aucun article
5. Le dateModified mis à jour automatiquement à chaque requête — signal de fraîcheur artificiel

Peut-on sur-baliser en schema ?

Oui, et c'est plus fréquent qu'on ne le croit. Empiler cinq types sur une page n'améliore rien : ça dilue la lecture, multiplie les erreurs de validation et brouille ce que Google retient. Si votre page n'a qu'un seul contenu identifiable, un seul type principal suffit. Les types secondaires (BreadcrumbList, WebSite, Organization) vivent sur les pages où ils ont du sens, pas en injection globale dans le header.

Valider, puis mesurer : le workflow qui compte

Un balisage correct sur 92 % des pages ne sert à rien si vous ne savez pas ce que les 8 % restantes disent. Et surtout, il ne sert à rien si vous ne mesurez pas l'effet. Je l'ai appris à mes dépens : pendant six mois, j'ai installé du schema sur un site de presse sans jamais regarder le CTR. Quand je m'y suis penché, on avait gagné de la visibilité sur une catégorie… et perdu sur une autre, à cause d'un Article mal renseigné qui affichait des dates incohérentes.

Quel outil pour valider les données structurées ?

Trois outils suffisent, et ils ne font pas la même chose. Le test des résultats enrichis de Google vérifie l'éligibilité à un rich result précis. Le validateur de Schema.org contrôle la conformité au vocabulaire, sans se soucier de ce que Google affiche. Et le rapport « Améliorations » de la Search Console donne la vue agrégée, page par page, avec les erreurs réelles constatées par le moteur. Ce dernier est le seul qui compte vraiment, parce qu'il reflète ce que Google a effectivement traité.

• Testez la page en production, pas en local
• Vérifiez le HTML rendu (après JavaScript), pas la source brute
• Comparez le nombre d'URL valides entre deux crawls espacés d'un mois
• Croisez avec le rapport « Résultats de recherche » : impressions et CTR par type

Comment mesurer l'impact réel sur le référencement ?

Deux courbes à surveiller : le CTR moyen des pages balisées, et le nombre d'impressions dans les fonctionnalités enrichies. Sur un site de e-commerce que j'ai suivi, l'ajout des étoiles d'avis sur les fiches produits a fait grimper le CTR de 2,8 % à 4,3 % en six semaines — sur les mêmes positions moyennes. Rien n'avait changé dans le contenu. Ce n'est pas une preuve absolue, mais c'est un signal qu'on ne peut pas ignorer.

Attention toutefois : corrélation n'est pas causalité. Entre deux mesures, il y a aussi les mises à jour de l'algorithme, les concurrents qui bougent, la saisonnalité. Je compare toujours des groupes de pages similaires, jamais l'ensemble du site.

Par où commencer, concrètement

Si vous partez de zéro, l'ordre que je recommande est simple : BreadcrumbList et Organization sur tout le site (une demi-journée de travail), puis le type principal de vos pages les plus stratégiques. Pas toutes. Les cinquante qui génèrent 80 % du trafic organique. On regarde l'effet, on ajuste, on étend.

Le reste — les types exotiques, les balisages de niche, les extensions qui promettent du schema magique — attendra. La question du départ n'était pas « combien de types puis-je installer », mais « lequel décrit le mieux cette page ». Tant que vous répondez à celle-là, vous êtes dans le bon ordre de grandeur.

Et si un plugin vous propose d'ajouter quinze types en un clic ? Demandez-vous ce qu'il va baliser à votre place. C'est souvent la première source d'erreurs que je corrige chez mes clients.

Faut-il baliser les pages qui n'ont pas de rich result associé ?

Dans la plupart des cas, non. Un balisage sans débouché SERP consomme de la maintenance pour rien. L'exception notable reste le balisage d'entité (Organization, WebSite), utile pour la compréhension du site par les moteurs et les systèmes d'IA générative, même sans affichage visible.

Peut-on mélanger plusieurs types sur une même page ?

Oui, à condition qu'ils décrivent des éléments distincts et réellement présents. Un Article avec un BreadcrumbList et une Organization, c'est cohérent. Un Article avec un Product et un Event sur une page qui ne vend ni ne présente d'événement, c'est du bruit qui se retourne contre vous.

Le passage à 2026 change-t-il quelque chose ?

La donne technique n'a pas bougé : JSON-LD, Schema.org, validation par la Search Console. Ce qui évolue, c'est la lecture des contenus par les moteurs qui intègrent des réponses génératives. Un balisage propre reste un signal de structure lisible, mais il ne remplace jamais la qualité du contenu lui-même. J'ai vu trop de sites bien balisés et mal écrits plafonner pour le savoir.