Une donnée structurée nomme, pour les moteurs de recherche, ce que contient une page web : le prix et la disponibilité d'un produit, l'auteur d'un article de blog, l'adresse d'une entreprise. Ce balisage Schema.org ne touche pas au classement du site dans Google ; il rend l'URL éligible à un résultat enrichi.
Les trois points à vérifier
- Le format à écrire est JSON-LD : un bloc de code séparé du contenu, que l'aide de Google recommande pour tous les types de balisage.
- Quatre types de données structurées couvrent un site courant : l'entreprise, le fil d'Ariane, l'article de blog et, en commerce, la fiche produit avec son prix et ses avis.
- Un balisage valide n'est pas un résultat enrichi obtenu : l'outil de test de Google, le validateur Schema.org et le rapport de la Search Console répondent à trois questions différentes.
Ce que le balisage change réellement dans les résultats de recherche
Le vocabulaire Schema.org a été publié en 2011 par Google, Bing, Yahoo et Yandex, qui l'utilisent tous les quatre pour lire le web dans une langue commune. Sans lui, un moteur de recherche doit deviner qu'un nombre suivi d'un symbole monétaire est un prix, qu'une suite de chiffres est une date de publication ou qu'une adresse désigne une entreprise. Le balisage supprime cette part d'interprétation : il nomme chaque élément du contenu par une propriété dédiée, et c'est cette description explicite que la recherche exploite ensuite pour structurer ce qu'elle affiche.
Google est clair sur le sujet dans son guide destiné aux développeurs : ce vocabulaire ne constitue pas un critère de positionnement direct. Une URL mal écrite ne remontera pas parce qu'elle porte du code supplémentaire. Ce que le balisage rend possible, c'est un affichage différent : une note en étoiles sous le titre, un prix et une mention de disponibilité sur une fiche produit, un chemin de navigation en lieu et place de l'URL, une image sur un résultat de recette.
Éligible ne veut pas dire retenu
C'est la nuance que la plupart des sites découvrent trop tard. Un balisage correct rend l'URL éligible à un résultat enrichi ; le moteur reste libre de ne pas l'utiliser, en fonction de la requête, de l'appareil de l'utilisateur ou de la confiance qu'il accorde au domaine. Une fiche peut donc afficher zéro erreur dans tous les outils de test et ne jamais obtenir l'affichage attendu. Cette distinction évite deux réactions inutiles : refaire un balisage déjà valide, et conclure qu'un chantier de SEO technique a échoué alors qu'il a fait ce qu'il pouvait faire.
L'intérêt se lit donc dans le taux de clics, et non dans la position. Un résultat qui occupe deux lignes de plus, qui montre un prix ou une image, capte une part de l'attention que ses voisins n'ont pas. C'est un gain de visibilité à position constante, ce qui en fait l'un des rares chantiers d'optimisation dont l'effet se lit sans attendre un mouvement de classement, et une visibilité obtenue sans acheter le moindre clic.
Quels balisages poser selon le type de page
Le vocabulaire Schema.org compte plusieurs centaines de types, dont une petite minorité déclenche réellement un affichage enrichi chez Google. Poser le reste ne nuit pas, mais n'apporte rien de visible. Le tableau ci-dessous récapitule les types utiles sur un site classique, avec les propriétés sans lesquelles le bloc est rejeté. Un type absent de cette liste peut être posé sans risque, il ne fera simplement rien apparaître de particulier dans la recherche, et son importance se mesure à l'affichage qu'il ouvre, jamais au nombre de types déclarés.
| Type de page | Type Schema.org | Propriétés indispensables |
|---|---|---|
| Page d'accueil | Organization | name, logo, sameAs, adresse du site |
| Toutes les pages internes | BreadcrumbList | itemListElement, position, name |
| Article de blog | Article | headline, image, datePublished, author |
| Fiche produit | Product et Offer | name, image, offers, price, priceCurrency, availability |
| Adresse physique | LocalBusiness | name, address, telephone, openingHoursSpecification |
| Page d'événement | Event | name, startDate, location |
Un site de référencement e-commerce concentre l'essentiel de sa valeur sur la quatrième ligne : le prix, la disponibilité et la marque sont exactement les informations que le moteur reprend sous le titre, et leur absence prive la fiche de son avantage le plus visible. Sur un site éditorial ou un blog, le trio Organization, BreadcrumbList et Article couvre déjà l'essentiel du contenu publié.
Les vidéos et les images, un balisage souvent oublié
Le type VideoObject est le grand absent de la plupart des chantiers. Il décrit un contenu visuel par son titre, sa vignette, sa durée et sa date de mise en ligne, et rend la vidéo éligible à un affichage dédié dans la recherche, avec un aperçu animé et parfois des marqueurs de chapitres. Sur un site qui héberge ses propres démonstrations ou qui reprend ses vidéos publiées ailleurs, c'est un gain de visibilité disponible sans écrire une ligne de texte supplémentaire, et une manière simple d'aider le moteur à comprendre un contenu qu'il ne sait pas lire.
Le balisage d'image obéit à une logique voisine : une galerie de photos ou un visuel de produit correctement décrit a plus de chances d'apparaître dans la recherche par images, un canal que les sites éditoriaux sous-estiment. La condition, une fois de plus, est la cohérence : le visuel balisé doit être celui que le visiteur voit, à une résolution suffisante pour être repris.
Les avis et les notes, l'affichage le plus visible
Les types Review et AggregateRating méritent une mention à part, parce qu'ils produisent l'ornement le plus repérable de la page de résultats : les étoiles. Une note agrégée réclame trois propriétés, la valeur moyenne, l'échelle utilisée et le nombre d'avis pris en compte, et elle ne s'applique qu'à ce que le vocabulaire autorise : un produit, un service, un livre, une recette, un logiciel. Le balisage d'un avis portant sur l'entreprise elle seule, posé en page d'accueil, ne donne rien depuis que Google a fermé cet usage.
La contrainte tenue est celle de la sincérité : les avis balisés doivent être visibles sur la page, provenir d'utilisateurs identifiables et refléter la note réellement calculée. Une moyenne inventée, ou construite sur trois retours choisis, est exactement ce que les équipes anti-spam recherchent. Sur une offre commerciale, c'est la première ligne à faire préciser : d'où viennent les avis, et qui les modère.
Le cas des FAQ, restreint depuis 2023
Beaucoup de guides recommandent encore d'ajouter un bloc FAQPage sur chaque page. Google a réduit cet affichage en août 2023 : les blocs de questions ne sont plus repris que pour les sites gouvernementaux et pour les publications de santé faisant autorité. Le balisage HowTo a suivi le chemin inverse et a été retiré des résultats. Poser ces deux types reste licite et aide un moteur à comprendre la structure du document, mais espérer un affichage enrichi n'a plus de fondement. C'est le genre de promesse à écarter d'une proposition commerciale.
Écrire le balisage en JSON-LD plutôt qu'en microdonnées
Trois formats coexistent pour exprimer le vocabulaire Schema.org. Les microdonnées et le format RDFa s'écrivent en attributs HTML, greffés directement sur les balises qui entourent le contenu visible : un attribut par propriété, au risque de rendre le gabarit illisible dès qu'il faut le faire évoluer. Le format JSON-LD, lui, est un bloc autonome, placé dans un script à part et sans lien avec la mise en page. C'est celui que Google recommande, et la raison est pratique : un bloc séparé se génère, se relit et se corrige sans toucher au gabarit du site.
Concrètement, le balisage prend la forme suivante, à poser dans le <head> ou n'importe où dans le corps de la page :
<script type="application/ld+json">{"@context":"https://schema.org","@type":"Organization","name":"Nom de l'entreprise","logo":"https://exemple.fr/logo.png"}</script>
Plusieurs blocs sur une seule page
Rien n'oblige à tout réunir. Une page de fiche produit peut porter un bloc Product, un bloc BreadcrumbList et un bloc Organization, chacun dans son script. Les moteurs les lisent ensemble. Cette séparation simplifie beaucoup la maintenance : quand une propriété change de nom dans le vocabulaire, un seul bloc est à reprendre. Le point d'attention porte sur l'identité des ressources, avec la propriété @id, qui permet de relier un article à son auteur ou un produit à son vendeur sans dupliquer l'information.
Le balisage doit décrire ce que le visiteur voit
La règle la plus stricte de Google tient en une phrase : le code doit correspondre au contenu visible par l'utilisateur. Déclarer une note moyenne introuvable dans le texte, un prix différent de celui du panier ou un auteur inventé vaut au domaine une action manuelle pour balisage trompeur, sanction qui lui retire d'un coup tous ses affichages enrichis. Le gain espéré n'a aucune commune mesure avec le risque, et c'est une ligne rouge à poser noir sur blanc dans un cahier des charges.
Comment vérifier qu'un balisage passe
C'est l'étape que les sites sautent le plus souvent, et celle où le travail se prouve. Trois outils se partagent le travail, et aucun ne remplace les deux autres. Leur finalité respective est simple à retenir, et c'est cette finalité qui décide lequel ouvrir.
Outil de test des résultats enrichis et validateur Schema.org
Le premier, le Rich Results Test de Google, celui qui décide de l'apparition des rich snippets, répond à une seule question : cette page est-elle éligible à un affichage enrichi, et lequel ? Les types dont Google ne fait rien en sont écartés d'office, ce qui surprend la première fois : un bloc parfaitement valide peut ne figurer nulle part dans son rapport. Le second, le Schema Markup Validator hébergé sur validator.schema.org, contrôle la conformité au vocabulaire complet, sans se prononcer sur ce que Google en fera. Il a remplacé l'ancien Structured Data Testing Tool en 2021.
La règle d'utilisation est simple : le validateur pour savoir si le code est correct, l'outil de Google pour savoir s'il sert à quelque chose. Les deux acceptent une URL ou un extrait de code collé, ce qui permet de tester un balisage avant sa mise en ligne.
Le rapport de la Search Console, une fois le site en ligne
Les outils de test analysent une page à la demande. La Google Search Console travaille à l'échelle du site et sur ce que le moteur a réellement exploré : un rapport par type de balisage, avec le nombre d'éléments valides, les avertissements et les erreurs, chacune reliée à la liste des URL concernées. C'est la seule source qui dise combien de pages sont couvertes, et non si une page l'est. Après correction, le bouton de validation demande une nouvelle analyse et suit le traitement du lot, ce qui donne une date de référence pour mesurer l'effet.
Tester la page rendue, pas le code source
Dernier piège, fréquent sur les sites récents : quand le balisage est généré en JavaScript, par une extension ou par le thème, il est absent du code source servi au premier appel et n'apparaît qu'après exécution du script. Un contrôle par affichage de la source conclut alors à un balisage manquant, alors qu'il est bien là pour le robot. Les deux outils de test, eux, travaillent sur la page rendue et voient le code généré. En cas de doute, la fonction d'inspection d'URL de la Search Console montre le HTML tel que le robot l'a obtenu.
Les cinq défauts qui font perdre l'affichage enrichi
- Une propriété obligatoire absente. Un bloc Product sans
priceou sansavailabilityest simplement ignoré pour l'affichage marchand, sans message ailleurs que dans les outils. - Un bloc recopié d'un modèle. Les valeurs d'exemple laissées en place, ou une URL d'image qui ne répond plus, invalident le bloc entier.
- Une date au mauvais format. Les propriétés de date attendent la norme ISO 8601 ; une date écrite en toutes lettres est rejetée.
- Deux blocs contradictoires. Une extension et un thème qui posent chacun leur balisage Article aboutissent à deux titres différents pour la page, et le moteur choisit de n'en retenir aucun.
- Un bloc posé sur une URL bloquée. Une page en
noindex, exclue par le fichier robots.txt ou victime d'un défaut d'indexation Google ne produira jamais de résultat enrichi, quelle que soit la qualité de son code.
Ces cinq points constituent une liste de contrôle utilisable en recette, avant de valider la livraison d'un prestataire. Chacun se vérifie en quelques minutes sur un échantillon représentatif, un exemple par type de gabarit. C'est le contrôle le plus rentable du chantier : il coûte une heure et évite de payer un balisage qui ne fera jamais apparaître quoi que ce soit.
Au bout de combien de temps l'affichage change, et comment le suivre
Le balisage n'est pris en compte qu'après une nouvelle exploration de la page. Sur un site publié régulièrement et bien maillé, cela prend quelques jours ; sur un site rarement mis à jour, plusieurs semaines. Le rapport de la Search Console est le premier indicateur à bouger, avant tout changement visible dans les résultats de recherche affichés à l'utilisateur.
La mesure de l'effet demande un peu de méthode, parce que le taux de clics varie aussi avec la position et la saison. La comparaison honnête porte sur un groupe de pages balisées et un groupe témoin de pages comparables laissées en l'état, sur une période identique, dans le rapport de performances. Un gain de taux de clics à position constante est le seul signal grâce auquel l'apport du balisage se chiffre vraiment. Ce travail d'analyse rejoint celui d'un audit SEO classique : sans point de comparaison, un chiffre ne prouve rien.
Sur les moteurs de réponse et les assistants qui reprennent des extraits, la donnée balisée sert au-delà du seul affichage : elle fournit un contenu déjà découpé, avec des entités nommées et des valeurs typées, plus facile à citer qu'un paragraphe. C'est le principe de ce que l'on appelle depuis peu la generative engine optimization, ou SEO GEO : structurer l'information pour qu'une machine puisse la reprendre sans se tromper. C'est une raison supplémentaire de baliser les pages qui portent des faits, des prix ou des références, en complément du travail sur les featured snippets.
Un balisage vieillit, et personne ne s'en aperçoit
C'est le point que les prestations oublient le plus souvent : un balisage posé une fois n'est pas acquis. Google retire régulièrement des fonctionnalités d'affichage, comme il l'a fait récemment pour les blocs FAQ, et chaque nouveauté du vocabulaire Schema.org ajoute des propriétés recommandées que les blocs déjà en ligne n'ont pas. Une baisse dans le rapport de la Search Console n'a donc pas toujours pour cause une erreur du site.
Les trois événements qui font vraiment baisser la couverture
La mise à jour d'un plugin change la présentation du code généré ; une refonte supprime la propriété que le développeur ne savait pas nécessaire ; un changement de fonctionnement du catalogue vide les prix. Dans les trois cas, la baisse apparaît d'abord dans le rapport et jamais dans le trafic, ce qui laisse le temps d'agir avant tout impact commercial. Un second plugin qui double le balisage produit le symptôme inverse : la couverture reste bonne, l'affichage disparaît.
Une habitude de suivi plutôt qu'un audit annuel
La gestion tient en peu de chose : analyser le rapport une fois par mois, comparer le nombre d'éléments valides au relevé précédent, et rattacher chaque variation à un événement connu. Cette organisation ne coûte que quelques minutes et évite de découvrir six mois plus tard que l'affichage enrichi a disparu. C'est la clé d'une stratégie de balisage qui tient dans la durée, et l'expérience montre que son absence annule l'essentiel de l'investissement initial. Sur un site local, cette surveillance est d'autant plus nécessaire que la fiche d'établissement et le balisage LocalBusiness doivent rester cohérents : une adresse modifiée d'un côté et pas de l'autre affaiblit les deux. Le raisonnement vaut aussi pour les balises meta et le titre, dont la rédaction obéit à une discipline de cohérence identique entre le code et ce que la fiche raconte.
Faire poser un balisage : ce qu'il faut demander
Sur un site sous WordPress, une grande partie du travail est déjà faite par les extensions : la plupart des outils de SEO WordPress génèrent Organization, BreadcrumbList et Article sans intervention. Le chantier se réduit alors à un contrôle et à quelques compléments sur les gabarits spécifiques. Sur un site développé sur mesure ou sur une boutique à gros catalogue, la génération doit être branchée sur la base de données, et le travail devient un vrai développement.
Quand une prestation est confiée à un référenceur extérieur, quatre demandes suffisent à distinguer une proposition sérieuse d'un argumentaire creux : la liste des types posés page par page, la méthode de génération retenue, une capture des outils de test après livraison, et le suivi du rapport de la Search Console pendant les semaines qui suivent. Un référenceur qui promet un gain de classement ou un affichage enrichi garanti annonce ce que personne ne peut tenir, et la documentation de Google suffit à le démontrer. Les critères de sélection et les tarifs du référencement se lisent de la même façon pour ce poste que pour le reste : ce qui est vérifiable d'un côté, ce qui relève de la promesse de l'autre.
Reste la question du périmètre. Baliser l'ensemble d'un catalogue de plusieurs milliers de références a du sens ; baliser une par une les pages d'un site de trente pages n'en a aucun, la génération automatique par gabarit coûtant moins cher et vieillissant mieux. Ce choix technique se pose avant le devis, pas après, et il pèse plus lourd sur la facture que le nombre de types retenus. Une agence SEO ou un référenceur indépendant qui commence par cette question travaille dans le bon ordre.
Les questions qui reviennent avant de lancer un chantier de balisage
Qu'est-ce que les données structurées en SEO ?
Les données structurées sont un code ajouté à une page pour décrire son contenu dans un vocabulaire normalisé, Schema.org, compris par les principaux moteurs de recherche. Elles servent à lever l'ambiguïté sur la nature des informations présentes, et rendent la page éligible à un affichage enrichi.
Comment utiliser les données structurées pour le SEO ?
La démarche tient en trois étapes : identifier les types utiles pour chaque gabarit du site, générer le balisage en JSON-LD depuis les données déjà présentes, puis contrôler le résultat avec un outil de test avant de suivre le rapport de la Search Console.
Quels sont les types de données structurées ?
Une poignée de types couvre la majorité des besoins : Organization pour l'identité du site, BreadcrumbList pour le fil d'Ariane, Article pour les publications, Product et Offer pour une fiche produit, LocalBusiness pour un commerce et Event pour un événement daté.
Comment vérifier les données structurées de mes pages ?
Trois contrôles se complètent, et chacun répond à une question distincte : l'outil de test de Google dit si l'URL est éligible, le validateur Schema.org dit si le code respecte le vocabulaire, et le rapport de la Search Console donne la couverture réelle du site.
Comment les données structurées influencent-elles le classement ?
Non, pas directement. Google indique que ce balisage ne constitue pas un critère de positionnement. L'effet passe par l'affichage : un résultat enrichi attire davantage de clics à position égale, ce qui améliore le trafic sans modifier le classement lui-même.
