Données structurées : ce qui sert encore

Ce que Google en fait, d'après sa documentation

Google recommande le format JSON-LD : un bloc de script placé dans la page, que le visiteur ne voit pas. Le vocabulaire est en général celui de schema.org, mais la présentation de Google précise que c'est sa propre documentation qui fait foi pour la recherche Google, et non celle de schema.org.

Il ne promet rien en échange. Ses consignes générales le disent : même un balisage correct ne garantit pas que les données apparaissent dans les résultats.

Les mêmes consignes posent la règle qui compte le plus. Les données structurées doivent représenter fidèlement le contenu de la page, et ne pas décrire ce que le visiteur ne voit pas. Un balisage trompeur peut entraîner une action manuelle de Google, qui retire à la page son éligibilité aux résultats enrichis.

Les types qui servent encore

La liste des types pris en charge par Google a raccourci. Pour la plupart des sites, cinq types restent utiles.

• Organization : le nom, le logo, l'adresse et les identifiants de l'entreprise. Google peut les reprendre dans le panneau qui présente une organisation.
• WebSite, sur la page d'accueil : il indique le nom du site que Google affiche au-dessus de chaque résultat. Son autre usage, le champ de recherche sous le résultat, n'est plus affiché depuis novembre 2024.
• BreadcrumbList : le fil d'Ariane, qui situe la page dans l'arborescence du site.
• Article : le titre, les dates et l'auteur d'un article, d'une actualité ou d'un billet.
• Product : le prix, la disponibilité et les avis d'un produit. Ses valeurs changent avec le catalogue, et le bloc doit changer avec elles.

Le balisage FAQ n'a plus d'affichage : le journal de la documentation de Google annonce sa disparition des résultats à partir du 7 mai 2026, puis le retrait de sa documentation en juin. Google dit des balises qui ne servent plus qu'elles ne causent aucun problème. Les retirer n'a rien d'urgent, et en ajouter n'apporte rien à la recherche Google.

Les blocs que personne ne relit

Un bloc de données structurées ne s'affiche nulle part. Personne ne le relit en parcourant le site, et il vieillit sans que rien ne le montre : un prix modifié sur la page mais pas dans le bloc, un logo remplacé, une adresse qui a changé.

Le format est strict. Une virgule en trop rend le bloc illisible, et un moteur le laisse de côté en entier, sans que la page affiche la moindre erreur.

Notre propre site en a fait l'expérience. Il existe en français et en anglais, et chaque texte affiché passe par deux dictionnaires confrontés l'un à l'autre. Les blocs de données structurées n'y passaient pas. Deux noms, celui du service et celui de son catalogue d'offres, y étaient écrits en français, sous un bloc déclaré anglais, sur les deux pages qui présentent l'offre. Aucune lecture de la page anglaise ne pouvait le montrer.

Depuis, un contrôle compare chaque page à sa jumelle dans l'autre langue, champ par champ, et bloque la publication quand un texte y est identique dans les deux langues. Les noms qui ne se traduisent pas, comme celui de la marque, sont tirés de la même source que la page plutôt qu'écrits dans une liste.

Ces blocs disent aussi qui publie le site et qui signe un article. Le guide sur l'E-E-A-T explique ce que ces signaux de confiance recouvrent.

Ce que les assistants d'IA en lisent

Pour ses réponses générées (AI Overviews, mode IA), Google indique qu'aucun balisage schema.org particulier n'est nécessaire, ni aucun fichier destiné aux IA. Parmi les pratiques de base qu'il rappelle figure une condition déjà vue : des données structurées qui correspondent au texte visible de la page.

Pour les autres assistants, nous ne promettons rien. Un bloc cohérent avec la page leur donne un fait de plus ; un bloc qui la contredit leur en donne deux versions. Le guide sur le fichier llms.txt traite d'une autre proposition faite aux assistants.

Ce que l'audit regarde, et pourquoi

L'audit lit les blocs de chaque page analysée, dans la page telle que le navigateur l'affiche.

• Les blocs illisibles. Un bloc qui ne s'analyse pas est relevé, puisqu'un moteur l'ignore en entier.
• Les types déclarés sur chaque page, et leur pertinence pour ce qu'elle contient : une fiche produit sans Product, un article sans Article.
• Les champs de chaque type : ceux sans lesquels le bloc ne sert à rien, comme le nom et l'adresse web d'une Organization, ou l'image et l'offre d'un Product, et ceux qui le complètent, comme le logo ou la marque. Pour un produit décliné en variantes, un champ porté par les variantes compte.
• Les pages sans aucune donnée structurée, relevées dans l'Analyse détaillée des pages.
• Le pays et la devise que les blocs déclarent, qui comptent parmi les indices du pays de l'éditeur du site.

Ces relevés entrent dans l'appréciation du pilier. Aucune règle du barème ne retire à elle seule des points pour l'absence de données structurées : un site sans elles reste lisible par les moteurs.

Ce qui se corrige simplement, ce qui demande un projet

Un champ manquant ou un bloc illisible se corrige dans le gabarit qui l'écrit, une fois pour toutes les pages de ce gabarit.

Le travail devient un projet quand les blocs sont écrits à part des données qu'ils décrivent : à la main, ou par une extension que personne ne relit. Il faut alors les produire depuis la même source que la page, pour que le prix affiché et le prix déclaré ne puissent plus diverger.

Ce que cette vérification ne dit pas

Par Quentin Mathis, Z29K · mis à jour le 28 septembre 2026