La question qui revient le plus souvent quand on parle de données structurées, ce n'est pas "comment on en met ?", c'est "lequel je choisis ?". Et là, franchement, la documentation officielle ne vous aide pas beaucoup. Schema.org recense des centaines de types, Google n'en supporte officiellement qu'une trentaine dans ses résultats enrichis, et au milieu de tout ça, vous avez une page qui pourrait rentrer dans quatre cases différentes.
J'ai longtemps cru qu'il fallait viser l'exhaustivité. Mauvaise idée. Sur un ancien projet, j'avais balisé chaque page avec cinq ou six types différents en me disant que "plus il y en a, mieux c'est". Résultat : deux avertissements dans la Search Console, un type ignoré purement et simplement par Google, et une bonne demi-journée perdue à déboguer un truc qui n'apportait rien. Depuis, je pars d'une règle beaucoup plus simple, et c'est celle que je vais dérouler ici.
Points clés à retenir
- Le bon type Schema.org se déduit de l'intention de la page, pas de la richesse de votre vocabulaire technique.
- Google ne récompense qu'une trentaine de types via les résultats enrichis : les autres servent la compréhension, pas l'affichage.
- Un type non supporté par Google n'est pas inutile — il nourrit les moteurs de réponse et les LLM.
- Une page = un type principal, puis des types secondaires imbriqués (fil d'Ariane, organisation, FAQ).
- Le JSON-LD reste le format à privilégier, sauf contrainte technique particulière.
- Un mauvais choix se voit rarement tout de suite : il se paie en avertissements et en perte de contrôle.
Comment choisir le bon type de balisage schema.org pour une page
Le réflexe naturel, quand on découvre Schema.org, c'est d'ouvrir la liste des types et de chercher celui qui "colle le mieux". C'est l'erreur de départ. La bonne question n'est pas "quel type décrit le mieux ma page ?" mais "à quoi sert cette page, et qu'est-ce que Google peut en faire ?".
Parce que le choix se joue sur deux plans distincts, et qu'on les confond tout le temps.
Les deux plans qu'il ne faut pas mélanger
Premier plan : l'éligibilité aux résultats enrichis. Google maintient une liste de types pour lesquels il peut générer un affichage spécial dans les résultats de recherche — étoiles de notation, prix, dates, vignettes. Si votre type n'est pas dans cette liste, vous n'aurez jamais de rich snippet, quoi qu'il arrive.
Second plan : la compréhension sémantique. Là, tous les types comptent. Un ScholarlyArticle, un MedicalWebPage ou un Recipe que Google n'affiche pas spécialement restent des signaux exploitables par les moteurs de réponse et les modèles de langage qui recopient votre contenu dans leurs synthèses.
Concrètement, ça veut dire qu'une page peut très bien avoir un type principal non éligible aux rich results et vivre très bien comme ça. Le tout est de savoir dans quel plan on joue.
Une méthode de décision en quatre questions
Voici comment je procède désormais, dans l'ordre. Ça prend deux minutes par page et ça évite 90 % des erreurs.
- De quel objet parle la page ? Un article ? Un produit ? Un événement ? Une entreprise locale ? Un mode d'emploi ? Si la réponse est floue, c'est que la page elle-même a un problème de positionnement.
- Ce type est-il supporté par Google ? Si oui, vous jouez sur les deux tableaux. Si non, vous restez sur la compréhension sémantique — ce qui reste utile.
- La page combine-t-elle plusieurs objets ? Un article qui contient une FAQ, c'est Article + FAQPage. Un produit avec des avis, c'est Product + AggregateRating. On imbrique, on ne remplace pas.
- Ai-je les données pour remplir les propriétés obligatoires ? Un type bien choisi mais à moitié rempli fait plus de mal que pas de balisage du tout : les données contradictoires déclenchent des avertissements, voire désactivent l'affichage enrichi.
Cette dernière question est celle qu'on oublie le plus. On choisit Product, on met trois propriétés sur douze, et on s'étonne que rien ne s'affiche.
Le tableau de correspondance : type de contenu → type Schema
Pour couper court aux hésitations, voici la grille que j'utilise. Elle couvre la grande majorité des pages qu'on trouve sur un site classique.
| Contenu de la page | Type principal | Types secondaires utiles |
|---|---|---|
| Article de blog, actualité | Article (ou BlogPosting) | BreadcrumbList, Organization, Person (auteur) |
| Fiche produit | Product | Offer, AggregateRating, BreadcrumbList |
| Page de contact / local commercial | LocalBusiness | PostalAddress, OpeningHoursSpecification, GeoCoordinates |
| Événement daté | Event | Place, Offer, Organization |
| Page de questions fréquentes | FAQPage | Question, Answer |
| Tutoriel étape par étape | HowTo | HowToStep, HowToSupply, HowToTool |
| Page "à propos" | AboutPage | Organization, Person |
| Site entier | WebSite | SearchAction, Organization |
Un mot sur la ligne "site entier" : le type WebSite ne se pose pas sur chacune de vos pages, mais idéalement sur la page d'accueil, avec la propriété SearchAction si vous avez un moteur de recherche interne. C'est le type qu'on oublie le plus souvent, alors qu'il aide à la fois à la compréhension du site et à l'affichage d'une barre de recherche dans les résultats.
Peut-on cumuler plusieurs types sur une seule page ?
Oui, et c'est même la norme dès qu'une page a un peu de substance. La règle que je m'impose : un type principal par page, puis les types secondaires qui en découlent logiquement. Le fil d'Ariane, lui, est quasiment systématique — il aide Google à comprendre la hiérarchie du site, en plus d'améliorer l'affichage de l'URL dans les résultats.
Techniquement, on écrit tout ça dans un seul bloc JSON-LD, souvent avec une clé @graph qui regroupe les entités. L'avantage, c'est qu'on peut les relier entre elles par des identifiants plutôt que de tout dupliquer. Sur un site de taille moyenne, cette approche m'a fait passer d'un fichier de balisage de 400 lignes illisibles à quelque chose qu'un développeur peut reprendre sans se prendre la tête.
JSON-LD, Microdata ou RDFa : faut-il vraiment choisir ?
Franchement, la question est tranchée depuis longtemps. JSON-LD est le format recommandé par Google, il ne touche pas au HTML, et il se génère proprement côté serveur ou côté JavaScript. À choisir, je vous conseille JSON-LD sans hésiter — et je défendrai cet avis bec et ongles, quitte à passer pour un sectaire.
Microdata et RDFa gardent un intérêt dans les CMS qui les génèrent nativement, ou sur des sites anciens dont la refonte n'est pas prévue. Mais si vous partez de zéro, ne vous posez même pas la question. Un principe simple : le format se choisit une fois pour tout le site, pas page par page.
Les erreurs de choix de type qui coûtent cher
Ici, je parle d'expérience. J'ai commis les trois premières, et j'ai vu les suivantes chez des clients.
- Choisir un type non supporté pour obtenir un affichage enrichi. Google ignore simplement le type. C'est un travail perdu pour le riche, mais pas pour la compréhension : à vous de savoir ce que vous visiez.
- Mettre un balisage Recipe sur une page qui ne contient pas de recette, juste parce qu'on a vu que ça affichait des étoiles. La sanction peut aller jusqu'à la désindexation du balisage sur le site entier, et là ça fait mal.
- Remplir des propriétés qui se contredisent entre JSON-LD et contenu visible. Google compare les deux. Un prix affiché dans le balisage et un autre dans la page, c'est un coup à tout perdre.
- Oublier d'indiquer l'auteur et la date sur les articles. C'est pourtant deux propriétés qui comptent pour la fraîcheur du contenu.
- Multiplier les blocs JSON-LD sur une même page, avec des entités qui se marchent dessus. Mieux vaut un seul bloc bien structuré.
Le pire, dans toutes ces erreurs, c'est qu'elles ne se voient pas immédiatement. On pose le balisage, on est fier de soi, et six semaines plus tard on découvre un avertissement perdu dans la Search Console.
Comment vérifier que votre choix est le bon
Deux outils suffisent, et je les utilise systématiquement avant de pousser quoi que ce soit en production.
Le premier, c'est le validateur de Schema.org, qui vérifie que votre code respecte bien les spécifications du vocabulaire. Le second, c'est le test des résultats enrichis de Google, qui vous dit si votre page est éligible à un affichage spécial — et sinon, pour quelle raison.
La différence entre les deux compte : un balisage peut être parfaitement valide pour Schema.org et ne rien déclencher côté Google, parce que le type n'est tout simplement pas éligible. Les deux résultats sont normaux et complémentaires.
Schema.org, c'est quoi exactement ?
Schema.org, c'est un vocabulaire partagé : une liste de types et de propriétés que les moteurs de recherche se sont accordés à reconnaître pour décrire du contenu. Concrètement, vous dites à une machine : "cette page est un article, écrit par telle personne, publié à telle date, et voici son sujet". Ce n'est pas un langage de programmation, c'est un dictionnaire — on l'utilise pour écrire des données structurées que les moteurs peuvent lire sans ambiguïté.
Le malentendu le plus courant : croire que Schema.org est un standard figé, piloté par Google. Non. C'est un projet collaboratif, auquel Google participe, mais qui évolue selon les besoins de tout l'écosystème.
Google exploite-t-il tous les types Schema.org ?
Non, et c'est un point qu'il faut intégrer une bonne fois pour toutes. Le vocabulaire en compte des centaines, mais Google ne documente qu'une trentaine de types pour ses résultats enrichis. Les autres restent utiles pour la compréhension du contenu, sans garantie d'affichage. Ce n'est pas un défaut du vocabulaire, c'est juste le périmètre que Google a choisi de supporter.
Pourquoi ce choix compte encore plus à l'ère des moteurs de réponse
Le paysage a changé. Aujourd'hui, une part croissante des internautes obtient sa réponse directement dans une synthèse générée, sans jamais cliquer sur un site. Et ces systèmes se nourrissent aussi des données structurées, parce que c'est la façon la moins ambiguë de comprendre à quoi correspond un contenu.
Résultat : des types que Google n'affiche pas spécialement peuvent devenir utiles parce qu'ils aident un modèle à citer correctement votre page. C'est un renversement assez récent, et je vois encore beaucoup de gens baliser uniquement pour les étoiles dans les résultats. C'est passer à côté de la moitié du sujet.
Le bon réflexe, à mon sens : choisir un type principal juste, même s'il n'est pas éligible aux résultats enrichis, et compléter avec les types secondaires qui ont du sens. La précision paie plus que la démonstration technique.
Et si vous ne devez retenir qu'une chose de tout ça, c'est peut-être celle-ci : le meilleur balisage schema.org n'est pas le plus spectaculaire, c'est celui que vous arriverez encore à maintenir dans un an, quand le site aura grandi et que trois personnes différentes y toucheront. Le type le plus rare ne vous vaudra jamais autant qu'un choix cohérent, posé une fois, et tenu dans la durée.
