Données structurées SEO : quels types poser, comment les écrire et les valider

Les données structurées sont un balisage normalisé, ajouté au code source d'une page, qui décrit son contenu aux moteurs de recherche dans le vocabulaire Schema.org. Elles ne modifient pas le classement : elles rendent la page éligible aux résultats enrichis affichés par Google.

Qu'est-ce qu'une donnée structurée en SEO ?

Une page web ordinaire présente son contenu à un lecteur humain, qui comprend sans effort qu'un nombre suivi d'un symbole est un prix et qu'une suite d'étoiles est une note. Un robot d'indexation, lui, ne voit que des balises et du texte. Les données structurées comblent cet écart : elles déclarent le type de l'objet décrit, produit, article ou entreprise, puis la valeur de chaque propriété, dans un format que tous les moteurs interprètent à l'identique. C'est cette information supplémentaire qui sert le référencement de la page.

Concrètement, il s'agit d'un bloc de code ajouté au code source, invisible pour le visiteur, qui annonce aux moteurs de recherche « cette page décrit un produit, son nom est X, son prix est Y, sa disponibilité est Z ». L'information n'est pas nouvelle, elle est déjà visible dans la page ; le balisage la rend seulement lisible par une machine, sans ambiguïté.

Un vocabulaire partagé par les principaux moteurs

Ce vocabulaire s'appelle Schema.org. Il n'appartient pas à Google : c'est un projet collaboratif lancé en 2011 par Google, Bing et Yahoo, rejoints ensuite par Yandex, précisément pour que les éditeurs n'aient pas à décrire leurs pages quatre fois dans quatre langages différents. Le vocabulaire Schema.org recense aujourd'hui plusieurs centaines de types, du plus général au plus spécialisé.

Tous ces types ne présentent pas le moindre intérêt pour le référencement. Un point mérite d'être posé tout de suite, parce qu'il évite beaucoup de travail inutile : Google n'exploite qu'une fraction du vocabulaire Schema.org, celle pour laquelle il a défini une fonctionnalité d'affichage. Baliser un type que Google n'exploite pas ne produit aucun résultat visible, et n'est pas une faute pour autant.

Trois formats, un seul recommandé par Google

Le balisage peut s'écrire de trois manières. Les microdonnées et le RDFa s'insèrent dans le HTML existant, en ajoutant des attributs aux balises qui portent déjà le contenu visible. Le JSON-LD, lui, se place dans un bloc autonome et décrit la page sans toucher à sa structure. C'est aujourd'hui le format le plus utilisé des trois.

Google recommande le JSON-LD, et cette recommandation a une conséquence pratique très concrète. Un balisage mêlé au HTML se casse au premier changement de gabarit : il suffit qu'un développeur déplace une balise pour que la propriété qu'elle portait disparaisse, sans que personne ne s'en aperçoive. Un bloc JSON-LD séparé survit aux refontes graphiques et se relit d'un coup d'oeil. C'est aussi le format le plus simple à générer depuis une base de données, ce qui compte dès qu'un site dépasse quelques dizaines de pages.

Ce que le balisage change, et ce qu'il ne change pas

C'est le contresens le plus répandu sur le sujet, et il vaut la peine d'être dissipé avant d'investir du temps dans un chantier de balisage. Les données structurées ne sont pas un facteur de classement. Ajouter du Schema.org à une page ne la fera pas remonter dans les résultats de recherche, et Google le dit sans détour dans sa documentation.

Ce que le balisage apporte est différent, et parfois plus rentable. Il rend la page éligible à des formats d'affichage enrichis : étoiles d'avis, prix, fil d'Ariane, image de recette, dates d'événement. Un résultat enrichi occupe davantage de place dans la page de résultats, attire l'oeil plus longtemps et se distingue des liens bleus qui l'entourent. Ces affichages sont ceux que le métier désigne sous le nom de rich snippets, et ils peuvent apparaître aussi bien sur ordinateur que sur mobile. Le gain se mesure donc sur le taux de clic, pas sur la position : à nombre d'impressions constant, la page gagne du trafic sans avoir bougé d'une place. C'est ainsi, et pas autrement, que le balisage améliore la visibilité d'un site.

Deux nuances méritent d'être connues. La première est que l'éligibilité n'est pas une garantie : Google décide au cas par cas d'afficher ou non un résultat enrichi, en fonction de la requête, du support et de sa propre appréciation de la qualité du site. Un balisage parfaitement valide peut ne jamais produire d'affichage enrichi. La seconde est indirecte : en aidant les moteurs à identifier sans ambiguïté les entités décrites par un site, le balisage participe à la compréhension globale de son sujet, ce qui rejoint le travail de structuration mené dans un cocon sémantique.

Cette distinction change la façon de prioriser. Sur un site dont les pages ne se positionnent pas encore, le balisage n'est pas le levier : mieux vaut commencer par un audit SEO et par le travail de fond sur le contenu. Sur un site déjà visible, dont les pages apparaissent sans être cliquées, il devient au contraire l'un des chantiers au meilleur rendement.

Les types de balisage Schema.org vraiment utiles

Voici les types que Google exploite réellement, et la fonctionnalité que chacun débloque. C'est cette liste qui doit guider un projet de balisage, pas l'étendue du vocabulaire Schema.org.

L'ordre de priorité dépend entièrement du modèle du site. Une boutique en ligne commence par Product, dont l'effet sur la présentation des offres est immédiat, et c'est l'un des premiers gestes d'un chantier de référencement e-commerce. Un site de services commence par Organization et LocalBusiness, qui appuient sa présence en référencement local. Un éditeur de contenu commence par Article et BreadcrumbList. Un site qui publie beaucoup de vidéos gagne à baliser VideoObject, un levier détaillé dans notre page sur le référencement vidéo.

Le cas des FAQ et des tutoriels, à connaître avant de baliser

Beaucoup d'articles publiés sur le sujet recommandent encore le balisage FAQPage comme un moyen simple d'occuper davantage d'espace dans les résultats de recherche. Cette information est périmée, et la reprendre fait perdre du temps.

En août 2023, Google a annoncé deux restrictions. Les résultats enrichis FAQ ne sont plus affichés que pour les sites gouvernementaux et de santé faisant autorité ; pour tous les autres, le balisage reste valide mais ne produit plus d'affichage particulier. Les résultats enrichis HowTo, qui présentaient des tutoriels étape par étape, ont pour leur part été abandonnés. Baliser une FAQ garde un intérêt pour la compréhension de la page par les machines, mais il ne faut plus en attendre le gain de visibilité qui était le sien avant cette date.

Écrire un balisage JSON-LD correct

Un bloc JSON-LD est un objet écrit dans un fichier de type texte, placé entre des balises script d'un type spécifique, que le navigateur n'exécute pas et que le robot de Google lit. Il commence toujours par deux propriétés : le contexte, qui pointe vers le vocabulaire Schema.org, et le type, qui annonce ce que la page décrit.

Plusieurs types sur une seule page

Une page décrit rarement un seul objet. Une fiche produit porte l'article vendu, mais aussi le fil d'Ariane qui indique sa place dans le catalogue et l'organisation qui la publie. Ces types coexistent sans se gêner : on peut les écrire dans plusieurs blocs distincts, ou les regrouper dans un tableau unique, Google acceptant les deux formes.

La difficulté n'est donc pas d'en poser plusieurs, mais d'éviter qu'ils se contredisent. Deux blocs qui déclarent des prix différents pour une seule référence, ou deux entités qui prétendent chacune être l'éditeur du site, produisent une information ambiguë que les moteurs de recherche tranchent à notre place. Quand un site atteint ce degré de complexité, il devient nécessaire de relier les entités entre elles par un identifiant stable plutôt que de les répéter dans chaque bloc.

Où placer le bloc dans la page

Google accepte le bloc dans l'en-tête comme dans le corps du document, et son emplacement n'a aucune incidence sur l'interprétation. En pratique, le placer dans l'en-tête présente un avantage : il est lu tôt, et il ne risque pas d'être déplacé par un script d'affichage. Un point mérite attention sur les sites dont le contenu est généré en JavaScript côté navigateur : Google exécute le JavaScript avant d'interpréter le balisage, mais cette exécution est différée, ce qui retarde d'autant la prise en compte des données structurées. Servir le bloc directement dans le code source évite ce délai, et cela rejoint les principes d'optimisation technique qui gouvernent l'exploration d'un site.

Propriétés obligatoires et propriétés recommandées

Chaque type Schema.org exploité par Google possède deux listes de propriétés. Les propriétés obligatoires conditionnent l'éligibilité : il en manque une, et la page n'est plus candidate au résultat enrichi. Les propriétés recommandées ne bloquent rien, mais elles enrichissent l'affichage et augmentent les chances qu'il soit retenu.

Pour une fiche produit, le nom et une offre comportant un prix et sa devise figurent parmi les exigences les plus courantes ; la note moyenne, la marque et l'image relèvent des recommandations. Le détail varie selon la fonctionnalité visée. La distinction se lit dans la documentation de référence, et c'est elle qu'il faut consulter avant d'écrire quoi que ce soit, plutôt qu'un exemple trouvé au hasard : le référentiel évolue, et les guides publiés il y a trois ans décrivent des exigences aujourd'hui caduques.

Un exemple de balisage, propriété par propriété

Pour rendre les choses concrètes, voici ce que contient le balisage d'une fiche produit qui obtient un affichage enrichi. Chaque élément de cette liste correspond à une propriété du vocabulaire, et leur ordre n'a aucune importance.

• Le type annonce ce que la page décrit, ici un produit.
• Le nom reprend l'intitulé exact affiché à l'utilisateur, sans ajout promotionnel.
• La description résume le produit en une phrase, et rien n'oblige à recopier la méta description de la page.
• L'image pointe vers un visuel accessible publiquement, faute de quoi la galerie de résultats reste vide.
• L'offre regroupe le prix, la devise et la disponibilité : ce sont les trois valeurs que Google affiche.
• La note et le nombre d'avis, facultatifs, déclenchent les étoiles quand la page les montre elle aussi.

Un guide de référence n'ira jamais beaucoup plus loin qu'un exemple de ce genre, parce que le détail des propriétés change d'un type à l'autre. C'est la documentation officielle qui fait autorité, et elle se consulte à chaque nouveau type balisé. Le libellé retenu pour le nom et la description gagne par ailleurs à rester cohérent avec les balises meta de la page, que l'internaute lit dans le résultat.

Vérifier et valider son balisage

Un balisage ne se déploie jamais sans contrôle. Une virgule mal placée invalide le bloc entier, et l'erreur reste silencieuse : la page continue de s'afficher normalement, seul le résultat enrichi ne vient pas. Aucune alerte n'avertit l'éditeur : la réponse de Google à une page mal balisée est simplement le silence.

Deux outils de test, et ce qui les sépare

Le premier est le test des résultats enrichis de Google, qui répond à une question précise : cette page est-elle éligible à une fonctionnalité d'affichage de Google, et laquelle. Il ignore délibérément les types que Google n'exploite pas, ce qui déroute quand on vient d'écrire un balisage parfaitement valide et qu'il n'en dit rien.

Le second est le validateur de Schema.org, connu sous le nom de Schema Markup Validator. Il contrôle la conformité au vocabulaire, sans se soucier de ce que Google en fait. C'est lui qui a succédé à l'ancien Structured Data Testing Tool, que Google a retiré et confié à Schema.org. Les deux outils sont complémentaires : le validateur dit si le code est correct, le test de Google dit s'il sert à quelque chose.

Le suivi dans la Google Search Console

Les deux outils précédents examinent une page à la fois, ce qui suffit pour une mise au point et pas pour un site entier. La Google Search Console prend le relais : elle ouvre un rapport par type de données structurées détecté, distingue les erreurs bloquantes des simples avertissements, et surtout donne le nombre d'URL concernées. C'est le seul endroit où l'on voit qu'une erreur touche une page ou douze mille.

Ce rapport se lit à côté des performances. Comparer le taux de clic d'un groupe de pages avant et après la mise en place du balisage est la seule manière honnête de quantifier le gain obtenu, et cela suppose un suivi de positionnement établi avant le chantier. Sans mesure de départ, toute amélioration constatée reste une impression.

Les erreurs qui coûtent l'éligibilité

Quelques fautes reviennent constamment, et la plupart ne relèvent pas de la technique.

• Baliser un contenu absent de la page. C'est la règle la plus stricte : les informations déclarées dans le balisage doivent être visibles par l'utilisateur. Annoncer une note moyenne que la page n'affiche nulle part est une infraction caractérisée.
• Publier des avis sur sa propre entreprise. Google n'accepte pas les avis qu'une entreprise publie à propos d'elle-même sur son propre site. Le balisage sera ignoré, au mieux.
• Laisser les prix se désynchroniser. Sur un site marchand, un prix figé dans le balisage pendant que la fiche évolue produit une contradiction que Google finit par sanctionner en retirant l'éligibilité.
• Confondre balisage et contenu. Les données structurées décrivent une page, elles ne la remplacent pas. Une page mince reste une page mince, quel que soit le soin apporté à son balisage, et c'est la rédaction web qui règle ce problème.
• Dupliquer le balisage sur des pages jumelles. Une variante d'URL qui reprend le balisage de l'originale envoie un signal contradictoire, que seule une balise canonique correcte permet de lever.

Le manquement à la première règle porte un nom dans les consignes de Google : le spam de données structurées. Il expose à une action manuelle, c'est-à-dire à une intervention humaine qui retire le site des résultats enrichis, et parfois davantage. La sortie d'une telle situation suit le parcours décrit sur notre page consacrée à la pénalité Google, et elle est autrement plus coûteuse que le contrôle qui l'aurait évitée.

Combien de temps avant de voir un effet ?

C'est la question qui vient juste après la mise en ligne, et la réponse honnête est qu'elle ne se compte pas en heures. Un résultat enrichi ne peut apparaître qu'après un nouveau passage du robot de recherche sur la page, et ce passage dépend de la fréquence d'exploration du site, laquelle tient à sa notoriété et à son rythme de publication. Quelques jours suffisent sur un site actif, plusieurs semaines sont courantes ailleurs, et rien n'en est visible pour l'utilisateur pendant ce délai.

Deux gestes accélèrent la vérification sans rien garantir. L'inspection d'URL de la Search Console permet de demander une réindexation page par page, ce qui suffit à valider un gabarit avant de le déployer sur tout un site. Le rapport dédié, lui, se met à jour avec un décalage : constater qu'il reste vide le lendemain n'apprend rien. L'essentiel est de suivre l'évolution sur un mois complet plutôt que de conclure au bout de deux jours.

Sur un blog, la patience est plus grande encore. Le balisage Article, ou sa déclinaison BlogPosting, ne produit pas d'affichage spectaculaire dans les pages de recherche : son utilisation sert surtout à déclarer l'auteur, la date de publication et l'image, et ce sont ces informations qui comptent pour la présentation d'un article dans Google Discover. Un blog gagne donc en visibilité par ce canal plutôt que par un enrichissement du lien bleu que voit l'utilisateur.

Extensions, CMS et balisage automatique

Dans la pratique, la plupart des sites ne rédigent pas leur balisage à la main. Les gestionnaires de contenu et leurs extensions le génèrent, et c'est une bonne chose : une extension applique la règle à des milliers de pages sans se tromper, là où une saisie manuelle dérive au bout de quelques dizaines.

Cette automatisation demande toutefois trois vérifications, que peu de sites effectuent. La première porte sur les doublons : quand un thème et une extension balisent tous deux l'entreprise éditrice, deux blocs concurrents se retrouvent sur la page d'accueil et les moteurs de recherche ne savent pas lequel utiliser. La deuxième porte sur ce que l'extension déclare réellement, car certaines émettent par défaut des propriétés qui ne correspondent à aucun contenu visible, ce qui expose exactement au risque décrit plus haut. La troisième est la mise à jour : les exigences de Google évoluent, et un balisage généré par une extension abandonnée cesse un jour d'être conforme.

Le réflexe utile tient en une phrase : une extension est une ressource commode, elle ne dispense pas du contrôle. Les sites qui utilisent WordPress avec une extension de référencement disposent le plus souvent d'un balisage correct par défaut, qu'il suffit de compléter sur les types spécifiques à leur activité. Encore faut-il aller vérifier ce qu'elle publie, plutôt que de supposer qu'elle fait ce qu'on attend d'elle.

Données structurées et moteurs génératifs

La question se pose depuis que les assistants conversationnels et les aperçus générés par intelligence artificielle s'intercalent entre l'internaute et les sites. Ce que l'on désigne par generative engine optimization, ou GEO, prolonge le travail de référencement naturel plutôt qu'il ne le remplace.

Sur ce terrain, il faut se garder des promesses. Aucun éditeur de modèle génératif ne publie de règle disant qu'un balisage Schema.org augmente les chances d'être cité, et personne n'est en mesure de le démontrer aujourd'hui. Ce que l'on peut affirmer est plus modeste et suffit à justifier l'effort : un contenu dont les entités, les dates, les prix et les auteurs sont déclarés explicitement se prête mieux à une extraction automatique qu'un contenu où la machine doit tout deviner. Les systèmes génératifs de Google s'appuient par ailleurs sur l'index de recherche, qu'alimentent ces données.

La conclusion pratique tient en une phrase : le balisage reste un investissement raisonnable, à condition de l'entreprendre pour ce qu'il fait de vérifiable, et non pour une promesse invérifiable. Le raisonnement vaut pour l'ensemble d'une stratégie de content marketing, où la clarté de la structure sert autant le lecteur que la machine.

Notre accompagnement sur les données structurées

Nous commençons par un inventaire de l'existant, car un site a rarement zéro balisage : les gestionnaires de contenu et leurs extensions en génèrent souvent, parfois incomplet, parfois en double. Deux blocs Organization concurrents sur la page d'accueil sont un cas fréquent, et il vaut mieux le corriger que d'empiler un troisième.

Nous identifions ensuite les types pertinents pour votre activité et votre modèle de site, puis nous écrivons le code JSON-LD en suivant les propriétés obligatoires de chaque fonctionnalité visée. Pour les catalogues, le balisage est généré depuis la base de données, afin que prix et disponibilité restent synchronisés sans intervention manuelle. Chaque gabarit est validé avec les deux outils avant mise en ligne, jamais après.

Le suivi vient en dernier, et il conditionne tout le reste : relevé des rapports de la Search Console, contrôle de l'apparition effective des résultats enrichis, et mesure du taux de clic page par page pour quantifier ce que le chantier a réellement rapporté. Ce travail s'inscrit dans une démarche de référencement naturel plus large, dont il constitue une brique technique parmi d'autres.

Les questions qui reviennent le plus

Les données structurées améliorent-elles le classement dans Google ?

Non. Google indique que les données structurées ne sont pas un facteur de classement direct. Elles rendent une page éligible aux résultats enrichis, dont l'effet se mesure sur le taux de clic et non sur la position.

Quel format faut-il utiliser pour baliser ses pages ?

Le JSON-LD, que Google recommande explicitement. Il se place dans un bloc autonome, ne dépend pas de la structure du HTML et survit donc aux refontes graphiques, contrairement aux microdonnées et au RDFa.

Comment vérifier les données structurées de mes pages ?

Avec le test des résultats enrichis de Google pour l'éligibilité aux fonctionnalités d'affichage, et avec le validateur de Schema.org pour la conformité au vocabulaire. Pour un site entier, les rapports de la Google Search Console prennent le relais.

Le balisage FAQ sert-il encore à quelque chose ?

Depuis août 2023, Google réserve les résultats enrichis FAQ aux sites gouvernementaux et de santé faisant autorité. Le balisage reste valide et aide les machines à comprendre la page, mais il ne produit plus d'affichage enrichi pour les autres sites.

Combien de types de balisage faut-il poser sur une page ?

Autant que la page en décrit réellement, sans plus. Une fiche produit porte légitimement Product et BreadcrumbList. Ajouter des types qui ne correspondent à aucun contenu visible expose à une action manuelle pour spam de données structurées.

Faut-il baliser un site qui n'est pas encore visible ?

Ce n'est pas la priorité. Le balisage agit sur la présentation d'un résultat déjà affiché ; si les pages ne se positionnent pas, le travail doit d'abord porter sur le contenu et sur la structure du site.

Pour approfondir, la documentation de Google Search Central sur le balisage fait référence, et le vocabulaire complet se consulte sur Schema.org. Le choix des pages à baliser en premier découle, lui, d'une analyse de mots-clés et des requêtes sur lesquelles le site apparaît déjà.