Données structurées

Ce que le balisage dit vraiment aux moteurs

Une page web est un document non structuré : du texte libre, des images, une mise en page pensée pour un œil humain. Le moteur qui la parcourt doit inférer que « 24,90 € » est un prix et non une référence produit, que le nom affiché en haut est celui de l'auteur et pas celui d'une personne citée, que le bloc du bas contient des avis. Les données structurées suppriment cette inférence. Elles ajoutent une couche lisible par machine, en pratique un bloc JSON-LD, qui déclare le type d'entité décrit par la page et ses propriétés dans un format prédéfini.

La typologie données structurées, semi-structurées, non structurées vient des bases relationnelles, où le schéma est imposé par le moteur de stockage. En SEO le rapport de force est inversé : personne n'oblige un éditeur à respecter un schéma, il le déclare volontairement, et Google décide ensuite d'y croire. C'est toute la différence entre une base de données et un balisage : la première garantit la cohérence, le second la revendique. Cette asymétrie explique pourquoi Google traite un balisage qui contredit le contenu visible comme du spam et non comme une erreur de format.

La vidéo ci-dessous pose proprement la frontière entre les trois familles de données, utile quand on vient du SEO plutôt que de la data.

Le vocabulaire vient de l'ontologie partagée maintenue par le consortium schema.org, une hiérarchie de types et de propriétés à laquelle contribuent Google, Microsoft, Yahoo et Yandex. La version 30.0 est sortie le 19 mars 2026, un peu plus de trois mois après la 29.4 du 8 décembre 2025 : elle ajoute des classes comme Credential et Error, la propriété floorLevel pour LocalBusiness et Residence, jobDuration pour JobPosting, et fait hériter Quantity de DataType. Point régulièrement raté en audit : schema.org publie beaucoup plus de types que Google n'en exploite. Déclarer un type non supporté ne déclenche aucun affichage particulier, ça reste une description d'entité que d'autres consommateurs, moteurs alternatifs ou agrégateurs, peuvent lire.

Ce que le balisage rapporte vraiment en 2026

Les chiffres qui circulent sur le gain de CTR se manient avec des pincettes. Digidop citait en janvier 2026 des données BrightEdge donnant environ 30 % de clics supplémentaires pour les pages balisées, et le guide 2026 de DigitalApplied avance 35 % de CTR en plus via les résultats enrichis. Ces mesures sont corrélationnelles et publiées par des acteurs qui vendent de l'outillage : les sites qui déploient un balisage propre sont aussi ceux qui soignent leurs titres, leur maillage et leur temps de chargement. L'ordre de grandeur reste crédible pour les formats qui modifient réellement l'affichage, étoiles, prix, disponibilité, fil d'Ariane. Il l'est nettement moins pour un balisage Article posé sur un blog B2B, où l'apparence du résultat ne change quasiment pas.

Cette vidéo prend l'angle opérationnel, avec des exemples de mise en œuvre directement exploitables.

Le fait marquant de 2026 n'est pas un gain, c'est une série de retraits. Google a supprimé les résultats enrichis FAQ de la recherche le 7 mai 2026, avec une note de dépréciation ajoutée à la documentation FAQPage dès le lendemain. Le type Practice Problem a suivi le même chemin : avertissement le 5 novembre 2025, documentation retirée le 6 janvier 2026, disparition des rapports Search Console, du test de résultats enrichis et des filtres d'apparence à partir de janvier 2026. En novembre 2025, Google a également clarifié que le balisage Dataset ne sert qu'à Dataset Search et pas à la recherche classique, tout en confirmant le maintien de Book Actions. Sept autres types avaient déjà quitté la documentation en septembre 2025, lors d'une passe de simplification qu'on attribue souvent à tort à 2026.

La lecture à retenir : la fenêtre où un bloc FAQ balisé grignotait de la surface SERP presque gratuitement est fermée, et elle ne rouvrira pas. Ce qui subsiste est un socle étroit mais stable. Organization, Article ou BlogPosting, Product, LocalBusiness et BreadcrumbList concentrent l'essentiel des affichages enrichis encore actifs, et aucun de ces types n'a été touché par les retraits successifs. Un déploiement 2026 qui couvre ces cinq types correctement fait l'essentiel du travail utile ; le reste relève de cas verticaux, recettes, événements, offres d'emploi.

JSON-LD, Microdata, RDFa : ce qui compte encore

Trois syntaxes coexistent officiellement pour exprimer le même vocabulaire. Le format que Google recommande explicitement isole le balisage dans un script indépendant du HTML de rendu : on peut le générer côté serveur depuis les mêmes données que la page, le versionner, le tester unitairement. Microdata dissémine des attributs itemscope, itemtype et itemprop directement dans le markup visible, ce qui le rend fragile à la moindre refonte de template et pénible à auditer. RDFa, héritée du web sémantique et des CMS des années 2010, survit surtout dans de vieux Drupal et dans des thèmes jamais nettoyés.

Position tranchée : maintenir du Microdata ou du RDFa sur un site refondu après 2023 est de la dette technique, pas une redondance protectrice. Les deux couches finissent par diverger, et un moteur qui lit deux déclarations contradictoires pour la même entité n'arbitre pas en votre faveur. Migrer vers un unique bloc JSON-LD généré par le template, puis supprimer l'ancien balisage plutôt que le laisser en place, coûte moins cher qu'un audit annuel sur les deux couches.

Autre piège fréquent : l'injection du JSON-LD via un gestionnaire de balises. Google rend le JavaScript et finit par le lire, mais on introduit une dépendance au rendu, un décalage possible entre ce que voit le testeur et ce qui est indexé, et une source de vérité hors du dépôt de code. Sur un site que vous contrôlez, le template serveur reste le bon endroit. Le gestionnaire de balises est un contournement quand le CMS est verrouillé, pas une architecture.

Google continue par ailleurs d'étoffer les types survivants : nouvelles propriétés supportées pour DiscussionForum et QAPage le 24 mars 2026, ajout de hasAdultConsideration aux fiches Product et Merchant listing le 20 mai 2026 pour les produits sensibles, et une recommandation du 2 mars 2026 sur l'image préférée précisant que le balisage image de schema.org et la balise og:image sont tous deux utilisés pour choisir la vignette dans Search et Discover. Ce dernier point est le plus rentable pour un média éditorial : deux déclarations cohérentes, une vignette prévisible, moins d'aléatoire sur l'affichage en Discover.

Données structurées et GEO : signal de confiance, pas de levier

Le décor a changé côté SERP. Le benchmark GEO 2026 de ConvertMate, construit sur plus de 12 500 requêtes et 8 000 domaines, situe la présence d'AI Overviews autour de 48 % des requêtes en février 2026, un ordre de grandeur cohérent avec les données BrightEdge. La synthèse statistique de SearchLab pour 2026 note une baisse moyenne du CTR organique de 18 à 25 % sur les requêtes concernées, et le jeu de données Seer Interactive de 3 119 requêtes affiche une chute de 1,76 % à 0,61 %, soit 61 % de moins quand un AI Overview est présent.

L'étude Ahrefs de février 2026, portant sur 863 000 SERP et environ 4 millions d'URL citées en AI Overview, montre que 38 % seulement des pages citées figurent dans le top 10 organique, contre 76 % à la mi-2025. ConvertMate va dans le même sens avec 83 % de citations issues de pages hors top 10, note que 61 % des pages citées utilisent du balisage, et mesure un trafic issu de la recherche IA qui convertit 4,4 fois mieux que l'organique classique.

La tentation est de relier ces deux derniers chiffres et d'en conclure que le balisage fait citer. Ahrefs a testé l'hypothèse en causal, sur environ 1 885 pages ayant ajouté du JSON-LD entre août 2025 et mars 2026 : aucun effet statistiquement significatif sur les citations en AI Mode ou ChatGPT, et une variation de -4,6 % sur les AI Overviews pour les pages déjà citées. L'expérience contrôlée publiée par Search Engine Land en septembre 2025, où seule la version balisée d'une page entrait dans un AI Overview, porte sur un cas unique : c'est une anecdote intéressante, pas une preuve. Le consensus praticien raisonnable en 2026 tient en une phrase : le balisage aide un système génératif à identifier de quoi parle la page et à ancrer sa réponse, il ne crée pas la citation.

Ce qui crée la citation, c'est d'exister comme entité reconnue et d'être reprise par d'autres pages. Sur les médias éditoriaux que nous opérons en propre, le balisage Article, Organization et BreadcrumbList est posé au build et pas page par page : c'est de l'hygiène technique, jamais un argument commercial. Travailler la visibilité dans les moteurs de réponse IA se joue ailleurs : dans la présence de la marque sur plusieurs sources tierces, par exemple via des pages construites autour des questions en éventail que posent ces systèmes, pas dans une propriété JSON-LD de plus. Le déplacement de visibilité, lui, vient des reprises éditoriales tierces, et c'est là que choisir soi-même ses médias dans un catalogue consultable sans inscription pèse infiniment plus lourd qu'une propriété JSON-LD supplémentaire.

Les erreurs qu'on voit casser un balisage en audit

La première, la plus coûteuse parce qu'elle donne l'illusion du travail fait : le balisage incomplet. DigitalApplied insiste sur ce point dans son guide 2026 et l'observation en audit le confirme, un Article sans propriété author ou un Product sans priceCurrency ne produit aucun gain partiel. Les résultats enrichis fonctionnent en tout ou rien, sur des propriétés requises. Une page avec cinq propriétés sur six utiles ne récolte pas 83 % de l'effet, elle récolte zéro.

Vient ensuite le balisage en double. Un thème qui injecte son Organization, une extension SEO qui injecte le sien, un script tiers qui ajoute un WebSite : trois blocs, des identifiants @id incohérents, et un moteur qui doit arbitrer entre des déclarations concurrentes. Le symptôme classique en audit est un rapport Search Console qui remonte des entités inconnues de l'équipe. Le correctif n'est jamais d'ajouter un quatrième bloc plus correct, c'est de couper les sources parasites.

Troisième famille, le type inapproprié. Un Product déclaré sur une page catégorie qui liste trente références, un Article posé sur une page de service, des avis balisés qui n'apparaissent nulle part dans le contenu visible. Ce dernier cas n'est pas une maladresse technique : Google le range dans ses règles anti-spam, et la sanction ne se limite pas à la perte de l'affichage enrichi. Le principe opérationnel est simple, tout ce qui est déclaré doit être visible et vrai sur la page, y compris les dates. Rafraîchir dateModified sans toucher au contenu ne relance pas le crawl, ça abîme un signal de confiance.

Sur la mesure, le Rich Results Test valide la syntaxe et l'éligibilité, rien de plus : il ne prédit ni l'affichage ni le trafic. Le validateur schema.org, lui, teste la conformité au vocabulaire, y compris pour des types que Google ignore. Le seul instrument qui parle de résultat est le rapport d'aspect dans Search Console, croisé avec les impressions et le CTR par apparence, sur des fenêtres avant et après de durée identique. Sans cette symétrie, on attribue au balisage une saisonnalité.

Dernier arbitrage, budgétaire. Un déploiement propre sur les cinq types du socle représente quelques jours de développement, une fois, et se maintient dans le template. Ce n'est pas comparable à un poste d'acquisition récurrent : mis en regard de ce que coûte réellement une publication éditoriale sur un média tiers, le balisage est la dépense la plus facile à justifier d'un plan technique. Ce qui ne signifie pas qu'il remplace l'acquisition de liens, seulement qu'il n'y a aucune raison rationnelle de le repousser.