La microdonnée est un format de balisage défini par la spécification HTML, qui ajoute aux éléments d’une page des attributs décrivant la nature et les propriétés du contenu, pour que des programmes puissent l’extraire et l’interpréter.
On emploie surtout le pluriel, microdonnées, qui traduit l’anglais microdata. Le mécanisme repose sur des groupes de paires nom-valeur. Chaque groupe forme un objet, appelé item, et chaque paire en constitue une propriété. L’attribut itemscope ouvre un objet. L’attribut itemtype indique son type, identifié par une URL. L’attribut itemprop, placé sur un élément descendant, déclare une propriété dont la valeur est, selon l’élément, son texte, son adresse ou un attribut dédié, comme une date. Deux attributs complètent le dispositif : itemid donne à l’objet un identifiant global, itemref lui rattache des propriétés situées ailleurs dans la page.
Les microdonnées n’ont de sens qu’avec un vocabulaire, qui fixe le nom des types et de leurs propriétés. Pour le référencement, le vocabulaire de référence est schema.org : un produit y porte un nom, un prix et une disponibilité, un événement une date et un lieu. Les microdonnées s’insèrent le plus souvent dans le texte visible. L’information affichée au lecteur et sa description pour les machines partagent donc les mêmes balises.
Elles sont l’une des façons d’encoder une donnée structurée, au même titre que le format JSON-LD, qui place la description dans un bloc de script séparé du texte, et que RDFa, extension du HTML tournée vers les données liées. Elles se distinguent des microformats, qui expriment la même intention avec des noms de classes plutôt qu’avec des attributs dédiés. Elles relèvent du SEO technique et se traitent dans les gabarits d’un site, lors d’une refonte ou d’un audit.
La documentation de Google sur les données structurées (Google Search Central, décembre 2025) cite trois formats pris en charge : JSON-LD, les microdonnées et RDFa. Elle recommande JSON-LD lorsque l’organisation du site le permet. Elle précise aussi que les trois formats se valent pour le moteur, à condition que le balisage soit valide et correctement mis en œuvre. Le balisage peut rendre une page éligible à un extrait enrichi. La documentation ne le présente pas comme une garantie d’affichage.
Notre lecture : un site déjà balisé en microdonnées n’a aucune raison urgente de migrer. La question se pose au moment où l’on touche aux gabarits.
L’atout des microdonnées tient à leur emplacement. La propriété décrite est le plus souvent le texte affiché : le prix balisé est alors le prix que voit le lecteur. Le risque d’écart entre la page et sa description diminue d’autant.
Leur faiblesse est le revers de cet atout. Le balisage dépend de la mise en page. Un intégrateur qui réorganise un bloc, renomme un élément ou déplace un prix peut casser une propriété sans le voir. Un bloc JSON-LD, généré à partir de la base de données du site, survit mieux aux changements graphiques. Il impose en revanche de vérifier qu’il reste fidèle au contenu visible.
Ces indicateurs sont des repères de pilotage que nous proposons. Un affichage enrichi dépend aussi de décisions du moteur, hors de portée du site.
Advalians pilote vos projets de site en assistance à maîtrise d’ouvrage : analyse de l’existant, coordination des prestataires et suivi régulier.
Advalians, cabinet de conseil indépendant en marketing et communication, vous aide à clarifier vos choix et à décider.
Les deux formats décrivent la même information avec le même vocabulaire, mais à des endroits différents. Les microdonnées sont des attributs posés sur les balises du texte visible. JSON-LD est un bloc de script séparé, qui reprend les valeurs sous forme de données.
Critère de choix : si vos pages sont produites par un gestionnaire de contenu qui sait générer un bloc à partir de sa base, JSON-LD est plus simple à maintenir. Si le balisage est écrit à la main dans le code, les microdonnées limitent le risque d’écart entre ce qui est affiché et ce qui est décrit.
Travaillez gabarit par gabarit, jamais page par page. Repérez d’abord les types de pages qui correspondent à un type du vocabulaire schema.org : produit, article, événement, organisation. Dans chaque gabarit, ouvrez l’objet avec itemscope et itemtype sur le bloc qui le contient. Ajoutez ensuite itemprop sur chaque élément qui porte une propriété : nom, prix, date.
Faites tester le gabarit avant la mise en ligne, puis un échantillon de pages réelles. Consignez le balisage dans la documentation technique du site.
Contrôlez à deux niveaux. Au niveau de la page, un outil de test du balisage indique les objets détectés, leurs propriétés et les erreurs. Au niveau du site, les rapports du moteur dénombrent les pages valides, en erreur ou avec avertissement, par type de balisage.
Suivez ensuite la part des pages balisées qui obtiennent un affichage enrichi et leur taux de clics. Un relevé mensuel suffit en régime courant. Après une refonte graphique, vérifiez dès la mise en ligne, car un changement de mise en page peut casser le balisage.
L’erreur la plus coûteuse consiste à décrire une information que la page n’affiche pas, ou qui a changé. Un prix balisé qui ne correspond plus au prix affiché trompe le lecteur et expose la page à perdre son éligibilité aux affichages enrichis.
Viennent ensuite les erreurs de syntaxe : objet non ouvert, propriété mal orthographiée, valeur vide. Elles passent inaperçues à l’écran. Pour les repérer, ajoutez un test automatique du balisage à la recette de chaque mise en production.
Pas dans l’urgence. Un balisage en microdonnées valide reste pris en charge, et une migration ne crée pas de valeur par elle-même. Elle se justifie dans trois cas : une refonte des gabarits est déjà prévue, le balisage casse souvent à chaque évolution graphique, ou l’équipe ne sait plus le maintenir.
Si vous migrez, faites-le type par type. Retirez l’ancien balisage au moment où le nouveau entre en ligne, pour ne pas décrire deux fois le même objet. Comparez les rapports d’erreurs avant et après.
