Ce que les données structurées changent réellement
Une page web est un texte que le moteur doit interpréter. Les données structurées suppriment cette interprétation : elles déclarent explicitement que ce nombre est un prix, que cette date est une date d’événement, que cette personne est l’auteur. Le format retenu par Google pour cette déclaration est le JSON-LD, un bloc de code isolé dans l’en-tête de la page, sans effet sur l’affichage.
L’effet direct sur le classement est nul, et il faut le dire clairement pour éviter les fausses attentes. Aucun balisage ne fait remonter une page. Ce qu’il produit, c’est un affichage enrichi dans les résultats : étoiles de notation, prix, disponibilité, questions dépliables, fil d’Ariane lisible, image de recette. Cet affichage occupe plus de surface et attire davantage de clics à position égale.
L’effet indirect est plus profond. Un site correctement balisé devient une source que les systèmes automatiques comprennent sans ambiguïté, ce qui compte de plus en plus à mesure que les moteurs génèrent des réponses plutôt que des listes de liens. Déclarer proprement son entité, ses services et ses auteurs n’est plus une optimisation marginale, c’est la façon dont une organisation se rend lisible.
Le JSON-LD se place dans une balise de script dédiée, généralement dans l’en-tête du document. Il n’est ni visible ni indexé comme du texte, et il ne remplace pas le contenu de la page. Un balisage qui déclare une information absente de la page est une infraction aux consignes de Google et expose à une action manuelle.
Les trois formats et pourquoi un seul compte
Trois syntaxes coexistent historiquement pour exprimer la même chose. Les microdonnées et le RDFa s’insèrent dans le HTML visible, en ajoutant des attributs aux balises existantes. Le JSON-LD vit à part, dans un bloc autonome.
Google recommande explicitement le JSON-LD depuis plusieurs années, pour une raison pratique : le balisage étant séparé du contenu, il se génère, se modifie et se valide sans toucher au gabarit. Sur un site où le contenu est produit par plusieurs personnes, cette séparation évite qu’une modification éditoriale casse le balisage sans que personne ne s’en aperçoive.
Les deux autres formats restent lus et interprétés, il n’y a donc pas d’urgence à migrer un site qui les utilise correctement. En revanche, mélanger deux formats sur la même page produit des déclarations concurrentes et des résultats imprévisibles. Un seul format par page, et de préférence le JSON-LD.
Le vocabulaire Schema.org, et comment s’y retrouver
Schema.org est un vocabulaire partagé, maintenu conjointement par les principaux moteurs. Il définit des centaines de types et des milliers de propriétés, ce qui décourage à la première lecture. En pratique, une dizaine de types couvrent la quasi-totalité des besoins d’un site professionnel.
Les types dont vous aurez réellement besoin
Organization déclare l’entreprise elle-même, son nom, son logo, ses coordonnées et ses profils officiels. LocalBusiness et ses sous-types précisent l’établissement physique, ses horaires et sa zone servie. Article couvre les contenus éditoriaux, Product les fiches produit, FAQPage les questions fréquentes, BreadcrumbList le fil d’Ariane, Person les auteurs et Service les prestations.
Le principe de choix est simple : prendre le type le plus précis qui existe. Déclarer un restaurant comme LocalBusiness fonctionne, le déclarer comme Restaurant transmet davantage. Un cabinet dentaire gagne à utiliser Dentist plutôt que MedicalBusiness. Cette précision coûte le même effort et améliore la compréhension.
Le graphe, pour éviter les déclarations orphelines
Une page bien balisée ne déclare pas trois blocs indépendants, elle déclare un ensemble d’entités reliées entre elles. La structure en graphe permet de dire que cet article a pour auteur cette personne, laquelle appartient à cette organisation, laquelle édite ce site.
Techniquement, cela consiste à regrouper les entités dans un tableau et à leur donner des identifiants stables, puis à les référencer par ces identifiants plutôt que de recopier leurs propriétés. Le gain est double : le fichier reste lisible, et les moteurs consolident les informations d’une page à l’autre autour des mêmes identifiants.
Les balisages qui déclenchent un affichage enrichi
Tous les types ne produisent pas d’affichage particulier. Voici ceux qui donnent un résultat visible, par ordre de fréquence sur les sites d’entreprise.
FAQPage, le plus rentable à mettre en place
Il déclare des questions et leurs réponses, et permet un affichage dépliable sous le résultat. Le gain de surface est net et le coût de mise en œuvre faible, puisque le contenu existe déjà sur la page. La condition à respecter est stricte : chaque question et chaque réponse déclarées doivent être visibles par le visiteur, y compris si elles sont repliées dans un accordéon.
BreadcrumbList, discret mais systématique
Il remplace l’adresse brute affichée sous le titre par un chemin lisible. L’effet sur le taux de clic est modeste pris isolément, mais il s’applique à toutes les pages du site et il ne coûte qu’une génération automatique depuis l’arborescence. C’est le balisage au meilleur rapport entre effort et couverture.
Product et AggregateRating, pour le commerce
Prix, disponibilité, note moyenne et nombre d’avis apparaissent directement dans les résultats. L’impact sur le taux de clic est le plus fort de tous les balisages. La contrainte est proportionnelle : les avis déclarés doivent être réels, collectés sur le site, et visibles. Déclarer une note agrégée sans avis affichés est une infraction fréquente et sanctionnée.
LocalBusiness, pour les établissements
Il consolide l’entité auprès de Google et recoupe les informations de la fiche d’établissement. Il ne déclenche pas d’affichage spectaculaire mais il participe à la cohérence des signaux locaux, sujet détaillé dans notre guide du SEO local.
Écrire un balisage propre, les règles qui évitent les erreurs
La syntaxe est simple, les erreurs sont presque toujours logiques plutôt que techniques.
La première règle est la correspondance stricte entre le balisage et la page. Un prix déclaré doit être le prix affiché. Une date de publication déclarée doit correspondre à celle visible. Cette exigence paraît évidente et elle est violée en permanence par des balisages générés automatiquement à partir de champs mal renseignés.
La deuxième règle est la stabilité des identifiants. Une entité conserve le même identifiant d’une page à l’autre et d’une année sur l’autre. Changer l’identifiant d’une organisation à chaque refonte revient à créer une nouvelle entité et à perdre la consolidation accumulée.
La troisième est la complétude raisonnée. Renseigner les propriétés obligatoires puis les propriétés recommandées suffit. Empiler des dizaines de propriétés facultatives n’apporte rien et allonge un fichier qu’il faudra maintenir. Mieux vaut cinq types bien renseignés que quinze types incomplets.
La quatrième concerne les caractères spéciaux. Un balisage est du JSON, donc les guillemets internes doivent être échappés et les retours à la ligne encodés. Une esperluette non traitée ou une apostrophe typographique mal encodée suffit à rendre tout le bloc invalide, et l’échec est silencieux : le moteur ignore simplement le balisage.
Valider, et surtout valider le bon rendu
La validation est l’étape que tout le monde saute et celle qui révèle la moitié des problèmes.
Les deux outils à utiliser, dans cet ordre
Le validateur de Schema.org contrôle la conformité au vocabulaire : types existants, propriétés autorisées, valeurs correctement typées. Le test des résultats enrichis de Google contrôle autre chose : l’éligibilité à un affichage enrichi, avec les propriétés que Google exige en plus de celles que Schema.org autorise.
Les deux sont complémentaires et un balisage peut passer le premier en échouant au second. Utiliser les deux évite de conclure trop vite qu’un balisage est correct parce qu’aucune erreur de syntaxe n’apparaît.
Tester l’URL en ligne, pas le code collé
C’est la précaution la plus importante et la plus négligée. Coller son code dans le validateur teste ce qu’on a écrit. Tester l’adresse en ligne teste ce que le serveur envoie réellement, après passage des extensions, du cache et des éventuelles réécritures. L’écart entre les deux est fréquent, et c’est justement là que se cachent les doublons de déclaration.
La Search Console fournit ensuite un suivi dans la durée, par type de balisage, avec les erreurs remontées sur l’ensemble des pages explorées. C’est le seul endroit où l’on voit qu’un problème touche quatre cents fiches produit et pas seulement celle qu’on a testée.
Les erreurs de balisage les plus fréquentes
Six erreurs reviennent sur presque tous les audits que nous menons.
- Déclarer un contenu absent de la page. Des questions balisées qui n’apparaissent nulle part, ou une note agrégée sans avis visibles. C’est l’infraction la plus sanctionnée.
- Laisser deux sources générer le même type. L’extension SEO et le gabarit produisent chacun leur bloc, et les deux se contredisent.
- Baliser la page d’accueil comme un Article. Elle n’en est pas un, elle est une WebPage ou une Organization selon ce qu’elle présente.
- Oublier de mettre à jour la date de modification. Un article révisé qui déclare toujours sa date d’origine perd le bénéfice de la fraîcheur.
- Utiliser un type trop général. LocalBusiness quand Restaurant, Dentist ou HomeAndConstructionBusiness existe.
- Ne jamais revalider après une mise à jour. Une mise à jour d’extension change parfois le balisage généré, sans avertissement.
Aucune de ces erreurs n’est difficile à corriger. Elles persistent parce que personne ne regarde le balisage une fois qu’il a été posé, alors qu’il vit et se dégrade comme le reste du site.
Le balisage par type de site
Les priorités diffèrent selon l’activité. Voici ce que nous posons systématiquement selon le profil.
Site de prestation de services
Organization pour l’entité, LocalBusiness si un établissement reçoit du public, Service pour chaque prestation avec sa zone servie, BreadcrumbList partout, FAQPage sur les pages qui en comportent, et Person pour l’auteur des contenus éditoriaux. Ce socle couvre l’essentiel et se génère depuis le gabarit.
Boutique en ligne
Product sur chaque fiche, avec Offer pour le prix et la disponibilité, AggregateRating si des avis existent réellement, BreadcrumbList sur le chemin de catégories, et Organization au niveau du site. Le point d’attention est la génération automatique sur des milliers de fiches : une erreur de gabarit se réplique instantanément partout.
Site éditorial et blog
Article ou BlogPosting selon la nature, avec auteur identifié, dates de publication et de modification, et image. La déclaration de l’auteur mérite un soin particulier car elle participe directement aux signaux d’expertise, sujet que nous traitons du côté de la prestation de référencement naturel.
Le balisage sur une boutique en ligne, cas particulier
Le commerce concentre à la fois le plus fort potentiel d’affichage enrichi et le plus grand risque d’erreur de masse. Une déclaration produit fausse ne touche pas une page, elle touche l’intégralité du catalogue en une seule mise en ligne.
Le prix déclaré doit correspondre au prix effectivement payé, toutes taxes comprises pour une clientèle de particuliers, et la devise doit être explicite. Les boutiques qui affichent un prix hors taxes en façade et déclarent le même montant dans leur balisage produisent des résultats trompeurs qui finissent par être signalés.
La disponibilité pose un problème de synchronisation. Un produit épuisé qui continue de se déclarer disponible génère de la frustration et dégrade la confiance accordée au domaine. La déclaration doit se brancher sur l’état réel du stock, pas sur une valeur figée dans le gabarit.
Les variantes enfin. Un produit décliné en plusieurs tailles ou coloris peut se déclarer comme une entité unique avec une fourchette de prix, ou comme plusieurs entités distinctes. Le choix dépend de la structure des adresses retenue, qui elle-même dépend de la plateforme, sujet traité dans notre comparatif WordPress ou Shopify. Les deux approches fonctionnent, les mélanger sur un même catalogue ne fonctionne pas.
Sur les gros catalogues, la règle de prudence est de tester le gabarit sur trois produits représentatifs avant de le déployer, puis de vérifier dans la Search Console pendant les deux semaines qui suivent. Une erreur répliquée sur huit cents fiches se corrige aussi vite qu’elle s’est propagée, mais encore faut-il la voir. C’est l’un des points de contrôle d’une prestation de SEO e-commerce.
Le balisage se décide avec l’architecture, pas après
Une remarque de méthode qui vaut pour tous les projets. Le balisage exprime la structure du site, il ne la crée pas. Un site dont l’arborescence est confuse produit un fil d’Ariane confus, et aucune déclaration ne rattrapera une hiérarchie mal pensée.
C’est pourquoi nous traitons le balisage au moment où l’architecture se dessine, avec la même logique que celle exposée dans notre méthode de cocon sémantique. Les identifiants d’entités, les relations entre pages piliers et pages filles, la hiérarchie des catégories : tout cela se décide une fois, puis se traduit mécaniquement en balisage.
Sur un projet neuf, cette exigence se formalise dans le cahier des charges du site internet, au même titre que les seuils de performance. Elle coûte alors quelques heures. Ajoutée après la mise en ligne, elle suppose de revenir sur chaque gabarit et de vérifier chaque type, ce qui représente plusieurs jours.
Le cas des sites multilingues mérite une mention. Chaque version linguistique porte son propre balisage, avec la langue déclarée et des identifiants d’entité partagés entre les versions. L’organisation reste la même entité quelle que soit la langue, ce que la déclaration doit refléter, faute de quoi le moteur voit quatre organisations distinctes portant le même nom.
Ce que coûte un balisage complet
La question du budget arrive toujours, et la réponse dépend surtout du nombre de gabarits, pas du nombre de pages.
Sur un site de prestation classique, comptez une journée pour l’inventaire et le nettoyage, une journée pour concevoir le graphe et poser le socle, une demi-journée par gabarit spécifique restant. Un site vitrine de vingt pages avec trois gabarits se traite en deux à trois jours.
Sur une boutique, ajoutez le gabarit produit et le gabarit catégorie, plus le temps de vérification sur un échantillon représentatif. Le catalogue lui-même ne change rien au coût puisque le balisage se génère, ce qui explique qu’une boutique de huit cents références ne coûte pas plus cher à baliser qu’une boutique de cinquante.
Ce budget est modeste rapporté à l’effet, et c’est ce qui en fait l’une des interventions au meilleur rendement d’un chantier de référencement. Les sites que nous livrons dans nos réalisations partent tous avec ce socle en place, ce qui évite d’y revenir.
Ce que le balisage ne fera pas pour vous
Une mise au point utile, parce que le sujet attire les promesses excessives.
Le balisage ne fait pas monter une page dans les résultats. Une page mal écrite, sur un site lent et sans autorité, restera à sa place quelle que soit la qualité de ses déclarations. Les gains observés après un balisage viennent du taux de clic amélioré, pas d’un changement de position.
Il ne garantit pas non plus l’affichage enrichi. L’éligibilité est une condition nécessaire, l’affichage reste une décision de Google prise requête par requête. Une page parfaitement balisée peut n’afficher aucun enrichissement pendant des mois, puis en afficher subitement.
Il ne compense enfin aucun défaut technique. Un site dont les pages mettent cinq secondes à s’afficher a un problème que le balisage ne touche pas, et qui se traite d’abord, comme détaillé dans notre article sur les Core Web Vitals. L’ordre des priorités compte : accessibilité technique, contenu, architecture, puis balisage.
Mettre en place le balisage sur un site existant
La méthode que nous appliquons tient en cinq temps et s’étale généralement sur deux à trois jours de travail pour un site de taille moyenne.
Inventaire d’abord : quels gabarits existent, quel balisage est déjà produit et par quoi. Cette étape révèle presque toujours des générations automatiques oubliées, héritées d’une ancienne extension.
Nettoyage ensuite : désactiver les sources concurrentes pour ne garder qu’un émetteur par type. C’est l’étape qui règle le plus de problèmes et elle ne produit aucun contenu nouveau.
Conception du graphe : définir les identifiants stables de l’organisation, de l’établissement et des auteurs, une bonne fois pour toutes. Ces identifiants serviront sur toutes les pages et ne devront plus changer.
Implémentation par gabarit, en commençant par celui qui couvre le plus de pages. Un balisage posé sur le gabarit d’article couvre instantanément tout le blog, alors qu’un balisage posé page par page ne finit jamais.
Validation enfin, sur les adresses en ligne et non sur le code, puis suivi mensuel dans la Search Console pendant le premier trimestre. Cette dernière étape attrape les régressions provoquées par les mises à jour, qui sont la principale cause de dégradation dans la durée. Elle fait partie de ce que couvre un contrat de maintenance sérieux.
Un mot sur la documentation interne. Sur les sites où plusieurs personnes interviennent, écrire une page décrivant les identifiants d’entités retenus et le type attendu par gabarit évite qu’un développeur suivant reparte sur d’autres conventions. Cette page tient en une demi-page et elle épargne des heures de démêlage deux ans plus tard.
Ce que vous devez retenir
Le JSON-LD déclare explicitement ce qu’une page contient, pour que le moteur n’ait pas à le deviner. Il ne fait pas gagner de positions, il fait gagner de la surface et des clics, et il rend l’entreprise lisible par des systèmes automatiques dont l’importance augmente.
Trois règles suffisent à éviter la quasi-totalité des problèmes. Ne déclarer que ce qui est visible sur la page. N’avoir qu’une seule source de génération par type. Tester l’adresse en ligne plutôt que le code écrit, parce que l’écart entre les deux est précisément là où se logent les erreurs.
Commencez par BreadcrumbList et FAQPage, qui couvrent beaucoup de pages pour peu d’effort, puis ajoutez le socle Organization et LocalBusiness. Le reste se traite gabarit par gabarit, par ordre de nombre de pages couvertes. C’est une intervention courte, mesurable, et dont l’effet se lit dans la Search Console en quelques semaines.
Une précision sur la maintenance du balisage. Les types et les propriétés de Schema.org évoluent, et les exigences de Google pour l’affichage enrichi changent plus vite encore : des types ont perdu leur éligibilité, d’autres l’ont gagnée. Une revue annuelle du balisage, alignée sur la revue technique du site, suffit à rester à jour sans y consacrer un suivi permanent. Ce contrôle prend une heure et évite de découvrir après coup qu’un affichage a disparu depuis six mois.
