Vous avez remarqué que certains résultats de recherche affichent des étoiles, un temps de préparation, une liste de questions dépliables ou un prix. Ce n’est pas un privilège accordé aux gros sites : c’est le résultat d’un balisage que n’importe quel site peut mettre en place. Encore faut-il choisir les bons types, les déclarer correctement, et éviter quelques erreurs qui annulent tout l’effort.
Ce que les données structurées apportent
Une page web est faite pour être lue par des humains. Un moteur, lui, doit deviner ce qu’elle contient : ce nombre est-il un prix, une note, une durée ? Cette date est-elle celle de publication ou celle d’un événement à venir ?
Les données structurées suppriment cette devinette. Elles décrivent explicitement le contenu dans un vocabulaire normalisé, compris par tous les grands moteurs. Vous ne dites plus « 4,7 » quelque part dans la page, vous dites « note moyenne de 4,7 sur 5, fondée sur 128 avis ».
Deux bénéfices en découlent. Le premier est une meilleure compréhension de votre contenu, qui aide le moteur à savoir de quoi traite la page et à quelle entité elle se rattache. Le second est l’éligibilité aux affichages enrichis : étoiles, images, prix, questions dépliables, fil d’Ariane, informations d’événement.
Ce que les données structurées ne font pas, en revanche, mérite d’être dit clairement : elles n’améliorent pas directement votre classement. Aucun type de balisage ne fait monter une page dans les résultats. Leur effet réel passe par le taux de clicun résultat enrichi attire davantage l’œil qu’un résultat ordinaireet par la clarté du signal envoyé. C’est indirect, mais c’est réel. Cette frontière entre effet direct et effet indirect est développée en détail sur seo-jimenezjulien.com, et elle conditionne les attentes qu’on peut raisonnablement placer dans ce travail.
Choisir les types utiles
Le vocabulaire compte plusieurs centaines de types. Vous en utiliserez trois ou quatre.
Un choix à faire type par type : chaque page reçoit le balisage qui correspond à sa nature réelle, et un seul. La tentation d’empiler tous les types plausibles sur une même page est l’erreur de débutant la plus répandue, et elle produit des signaux contradictoires que le moteur finit par ignorer.

Organisation ou entreprise locale, à déclarer une fois, sur la page d’accueil. Nom, logo, coordonnées, réseaux sociaux officiels, horaires d’ouverture s’il y a un lieu physique. C’est le balisage fondateur, celui qui rattache votre site à une entité identifiée.
Article, pour vos contenus éditoriaux : titre, auteur, dates de publication et de modification, image principale.
Produit, pour les fiches commerciales : nom, description, prix, devise, disponibilité, éventuellement note et avis.
Événement, pour les dates, ateliers, séances : nom, dates de début et de fin, lieu, mode de participation, billetterie.
Recette, pour les contenus culinaires, avec ingrédients, étapes, durées et valeurs nutritionnelles.
Questions fréquentes, pour les blocs de questions-réponses réellement présents sur la page.
Fil d’Ariane, à déclarer sur l’ensemble du site. Peu spectaculaire, très utile : il améliore l’affichage du chemin dans les résultats et clarifie votre architecture.
Sur une activité de bien-être, la combinaison la plus pertinente est généralement : entreprise locale sur l’accueil, article sur les contenus, événement sur les séances ou ateliers, et fil d’Ariane partout.
Où et comment les déclarer
Trois formats existent. Un seul mérite d’être retenu.
Le format JSON-LD est recommandé par Google, et pour de bonnes raisons : il se place dans un bloc <script> distinct, sans se mêler au balisage HTML de la page. Vous pouvez donc le modifier sans toucher au contenu visible, et inversement. Les deux autres formats, qui imposent d’insérer des attributs directement dans les balises HTML, sont fragiles et pénibles à maintenir.
Le bloc se place dans l’en-tête ou dans le corps de la page, cela n’a pas d’importance. La seule exigence est qu’il soit présent dans le HTML serviun balisage injecté tardivement par JavaScript sera pris en compte, mais avec un délai et une fiabilité moindres.
Chaque type distingue des propriétés obligatoires et recommandées. Les premières conditionnent l’éligibilité aux affichages enrichis : sans elles, le balisage est valide mais inutile. Les secondes améliorent la richesse du résultat. Consultez la documentation officielle du type concerné avant d’implémenterles exigences évoluent.
Règle absolue : toute information balisée doit être visible sur la page. Baliser un prix qui n’apparaît nulle part, ou des avis absents du contenu, constitue une violation explicite des règles.
Les erreurs les plus fréquentes
Cinq écueils reviennent systématiquement.
Baliser des informations absentes de la page. Déjà évoqué, c’est le plus grave. Cela expose à une action manuelle qui retire l’ensemble de vos résultats enrichis, parfois pour longtemps.
Les avis auto-attribués. Une organisation ne peut pas baliser sa propre note globale sur sa page d’accueil ou sur ses pages de service. Les avis balisés doivent porter sur un élément précisun produit, une recette, un livreet provenir d’utilisateurs, pas de vous.
Les types en doublon. Deux blocs de balisage déclarant la même entité avec des valeurs différentes. Le moteur ne sait pas lequel croire, et il tranche rarement en votre faveur. Cela arrive fréquemment quand une extension SEO et un thème génèrent chacun leur balisage.
Le balisage de questions fréquentes détourné. Créer un bloc de questions artificiel uniquement pour occuper plus d’espace dans les résultats. Les critères d’affichage de ce type se sont considérablement resserrés.
Les propriétés obligatoires manquantes. Le balisage passe la validation générale mais reste inéligible. Vérifiez toujours dans l’outil de test dédié aux résultats enrichis, pas seulement dans le validateur de syntaxe.
Tester et surveiller
Deux outils, deux usages complémentaires.
Le validateur de syntaxe vérifie que votre code est conforme au vocabulaire. Il détecte les erreurs de structure, les propriétés inconnues, les valeurs mal formées.
L’outil de test des résultats enrichis vous dit ce qui compte vraiment : votre page est-elle éligible à un affichage enrichi, et pour quel type. C’est celui qu’il faut utiliser en priorité.
Après mise en production, surveillez les rapports d’amélioration dans vos outils pour webmasters. Ils remontent, type par type, le nombre de pages valides, en avertissement et en erreur. Une erreur apparue soudainement sur cinq cents pages signale presque toujours une modification de gabarit.
Comptez deux à quatre semaines avant que les rapports reflètent une nouvelle implémentation.
Ce que ça change dans les résultats
Soyons précis sur ce qu’on peut espérer, pour éviter la déception.
Un balisage correct rend votre page éligible à un affichage enrichi. Il ne le garantit jamais. Google décide au cas par cas, en fonction de la requête, de l’appareil, de la qualité générale de la page et de la pertinence de l’affichage. Une même page peut apparaître enrichie sur une requête et ordinaire sur une autre.
Les types éligibles évoluent également : certains affichages ont été restreints ou supprimés ces dernières années. Ne construisez pas une stratégie entière sur un format d’affichage particulier.
L’effet mesurable porte sur le taux de clic, avec des gains observés variables mais réels sur les pages qui obtiennent un affichage enrichi. C’est un travail rentable, pas un levier miraculeux.
La checklist de mise en production
Huit points à valider avant de déployer.
Le type choisi correspond-il à la nature réelle de la page ? Un seul type principal est-il déclaré ? Toutes les propriétés obligatoires sont-elles renseignées ? Chaque information balisée est-elle visible dans le contenu ? Le format JSON-LD est-il utilisé ? Le balisage est-il présent dans le HTML servi, sans dépendre d’un script ? La page passe-t-elle l’outil de test des résultats enrichis sans erreur ? Aucun autre balisage concurrent n’est-il généré par une extension ou par le thème ?
Huit réponses satisfaisantes, et vous pouvez déployer. Revérifiez ensuite un échantillon de pages réelles en production : le rendu final diffère parfois de l’environnement de test.