Données structurées (JSON-LD) : pourquoi Google — et les IA — en ont besoin

Les données structurées ne modifient pas le contenu visible d'une page pour un visiteur humain — elles ajoutent, en arrière-plan, une description explicite et normalisée de ce que la page représente : un article et son auteur, un produit et son prix, une recette et son temps de préparation, une question et sa réponse directe. Cette description suit un vocabulaire commun défini par schema.org, un projet collaboratif soutenu conjointement par Google, Microsoft (Bing), Yahoo et Yandex depuis 2011, précisément pour éviter que chaque moteur de recherche impose son propre format incompatible avec les autres, ce qui aurait multiplié la charge de travail pour les éditeurs de sites cherchant à être compris de tous les moteurs simultanément.

Avant cette initiative collaborative, chaque moteur de recherche expérimentait ses propres microformats et extensions propriétaires pour extraire des informations structurées du web, avec des résultats fragmentés et peu adoptés par les développeurs, faute de standard unifié suffisamment large pour justifier l'effort d'implémentation. La création de schema.org a résolu ce problème de coordination en offrant un vocabulaire unique, exhaustif, et régulièrement enrichi de nouveaux types au fil des besoins émergents du web.

JSON-LD, microdata, RDFa : trois syntaxes, un seul vocabulaire

Le vocabulaire schema.org peut s'exprimer selon plusieurs syntaxes techniques différentes, ce qui prête parfois à confusion chez les personnes qui découvrent le sujet. Le microdata et le RDFa s'intègrent directement dans les attributs des balises HTML existantes, au moyen d'attributs spécifiques ajoutés directement sur les éléments visuels de la page, ce qui les rend plus fastidieux à maintenir puisqu'ils sont dispersés dans tout le document et étroitement couplés à la structure visuelle du HTML — toute modification du gabarit visuel risque de casser accidentellement le balisage sémantique associé.

Le JSON-LD, à l'inverse, regroupe toute l'information structurée dans un unique bloc de script placé n'importe où dans le document, entièrement séparé du HTML visuel qui gère l'affichage — c'est la syntaxe explicitement recommandée par Google depuis plusieurs années, car elle est plus simple à générer dynamiquement depuis une base de données, plus simple à valider indépendamment du rendu visuel de la page, et plus simple à faire évoluer sans toucher au reste du template de la page ni risquer de casser l'affichage visuel en modifiant le balisage sémantique.

Ce que ça change concrètement dans les résultats de recherche

Le balisage schema.org n'est pas, en lui-même, un facteur de classement direct confirmé par Google dans sa documentation officielle. Son effet est indirect mais réel et mesurable : il conditionne l'éligibilité à des formats d'affichage enrichis dans les résultats de recherche — étoiles d'avis sous un lien, questions dépliables directement dans les résultats sans avoir à cliquer, fil d'Ariane visuel affiché à la place de l'URL brute et technique, carrousel de recettes avec photo et temps de préparation affichés directement dans les résultats, ou encore affichage du prix et de la disponibilité directement sous un résultat produit.

Ces formats enrichis augmentent mécaniquement la visibilité et le taux de clic d'un résultat par rapport à un résultat standard sans enrichissement visuel, sans changer sa position de classement dans la liste des résultats. Un résultat en troisième position avec des étoiles d'avis clairement visibles peut ainsi capter davantage de clics qu'un résultat en première position sans aucun enrichissement visuel, simplement parce qu'il attire davantage l'œil et rassure davantage sur la qualité perçue avant même le clic, sans que sa position dans le classement change pour autant.

Les types les plus couramment utilisés

• Article / BlogPosting : pour le contenu éditorial, avec auteur, date de publication, date de mise à jour, image associée — un type particulièrement pertinent au regard des critères E-E-A-T abordés par ailleurs.
• Product : pour les fiches produit e-commerce, avec prix, devise, disponibilité en stock, et note moyenne agrégée des avis clients.
• FAQPage : pour les pages de questions-réponses, permettant un affichage dépliable directement dans les résultats de recherche sans nécessiter de clic.
• BreadcrumbList : pour afficher le fil d'Ariane structuré à la place de l'URL technique brute dans l'affichage des résultats de recherche.
• Organization / LocalBusiness : pour les informations d'entreprise, en particulier utiles pour le référencement local et l'affichage dans Google Maps et le pack local.
• Recipe, Event, JobPosting : des types spécialisés, chacun débloquant un format enrichi propre à sa thématique, avec des champs spécifiques adaptés (temps de cuisson pour une recette, date et lieu pour un événement, salaire et type de contrat pour une offre d'emploi).
• HowTo : pour les contenus de type tutoriel étape par étape, avec un affichage potentiellement enrichi listant chaque étape directement dans les résultats.
• VideoObject : pour les contenus vidéo intégrés à une page, permettant un affichage avec vignette et durée dans les résultats de recherche.

Un enjeu qui dépasse désormais Google

L'essor des moteurs de réponse basés sur des modèles de langage change sensiblement la donne pour les données structurées. Un modèle de langage qui doit résumer ou citer une information factuelle a objectivement plus de facilité à extraire un fait clairement balisé dans un champ structuré et normalisé (un prix précisément identifié dans un champ price, un auteur identifié dans un champ author avec ses qualifications) qu'à le déduire par inférence d'une phrase en prose noyée dans un paragraphe rédactionnel où l'information pertinente n'est pas explicitement délimitée.

Cette différence de fiabilité d'extraction devient un avantage concret et mesurable pour les sites qui documentent proprement leurs données structurées, à mesure que les réponses générées par IA — AI Overviews affichés directement dans Google, ChatGPT avec fonctionnalité de navigation web, Perplexity et ses concurrents — deviennent une part croissante et durable du parcours de recherche des utilisateurs. Un site dont les informations factuelles sont dispersées dans un texte narratif sans structure explicite s'expose à un risque réel de citation moins précise ou de non-citation pure et simple face à un concurrent dont l'information équivalente est clairement balisée et donc plus facilement vérifiable et extractible par un système automatisé.

Les pièges techniques les plus fréquents

Une erreur de syntaxe JSON dans le bloc JSON-LD — une virgule manquante entre deux propriétés, une accolade mal fermée, des guillemets non échappés correctement dans une chaîne de texte — invalide généralement l'intégralité du bloc concerné, pas seulement le champ fautif : le balisage entier devient inexploitable pour Google jusqu'à correction complète de l'erreur de syntaxe, même si le reste du balisage était par ailleurs parfaitement correct et bien structuré.

Autre piège fréquent et potentiellement plus grave en termes de conséquences : un balisage qui décrit un contenu absent de la page visible pour l'utilisateur humain — par exemple une note moyenne d'avis balisée en JSON-LD alors qu'aucun avis n'est réellement affiché nulle part sur la page, ou un prix balisé qui ne correspond pas au prix réellement affiché à l'écran. Cette pratique, appelée balisage trompeur dans la documentation de Google, va directement à l'encontre des règles de qualité et peut entraîner une action manuelle qui désactive purement et simplement l'affichage des résultats enrichis pour l'ensemble du site concerné, pas seulement pour la page fautive isolée, avec un impact potentiellement lourd sur la visibilité globale du site dans les résultats de recherche.

Un troisième piège, plus subtil et plus difficile à détecter sans outil dédié, concerne la cohérence entre plusieurs blocs de balisage présents sur la même page : des informations contradictoires entre deux types de données structurées (par exemple deux prix différents pour le même produit, l'un déclaré dans un bloc Product principal et l'autre dans un bloc Offer imbriqué à l'intérieur) créent une ambiguïté que Google peut résoudre en ignorant simplement l'ensemble du balisage plutôt qu'en devinant lequel des deux champs contradictoires est réellement correct, annulant de fait le bénéfice recherché par l'implémentation initiale.

Un quatrième piège concerne la maintenance dans la durée : un balisage correctement implémenté au moment de sa création peut se dégrader silencieusement au fil du temps si le champ de données sous-jacent change de format ou de structure dans le système de gestion de contenu, sans que personne ne pense à vérifier que le balisage JSON-LD généré automatiquement reste cohérent avec ce changement — un risque particulièrement présent lors des migrations de plateforme ou des refontes techniques importantes.

Comment vérifier que c'est bien fait

L'outil de test des résultats enrichis de Google reste la référence pour valider la syntaxe d'un balisage donné et voir précisément quels types de résultats enrichis sont éligibles pour une URL spécifique, avec un signalement clair des erreurs bloquantes et des avertissements non bloquants qui pourraient néanmoins limiter l'affichage optimal du résultat enrichi correspondant.

Le rapport "Résultats enrichis" de Google Search Console complète cette vérification ponctuelle par un suivi dans la durée, à l'échelle de l'ensemble du site plutôt que d'une seule URL isolée, avec un décompte précis des pages valides, des pages avec avertissements à corriger, et des pages en erreur bloquante nécessitant une intervention. Une bonne pratique consiste à vérifier systématiquement ce rapport après chaque changement de gabarit de page, puisqu'une modification du template peut casser silencieusement le balisage sur des centaines ou des milliers de pages d'un coup si le champ concerné est généré dynamiquement à partir d'une source de données commune à toutes ces pages.

L'implémentation progressive plutôt que l'exhaustivité immédiate

Face à la diversité des types disponibles dans le vocabulaire schema.org, une approche progressive est généralement plus efficace qu'une tentative d'implémentation exhaustive immédiate. Commencer par les types les plus directement liés au cœur de l'activité du site (Product pour un site e-commerce, Article pour un site éditorial, LocalBusiness pour une entreprise avec présence physique) permet d'obtenir un bénéfice mesurable rapidement, avant d'étendre progressivement le balisage à des types complémentaires une fois la première implémentation validée et stabilisée dans le temps.

Cas pratique : baliser une fiche produit de bout en bout

Prenons l'exemple concret d'une fiche produit e-commerce classique. Le bloc JSON-LD correspondant déclarerait typiquement un type Product avec, au minimum, un nom, une description, une image, et une marque. À l'intérieur de ce même bloc, une propriété offers de type Offer préciserait le prix, la devise utilisée, la disponibilité en stock (via des valeurs normalisées comme InStock ou OutOfStock), et l'URL de la page elle-même. Si des avis clients sont affichés sur la page, une propriété aggregateRating viendrait compléter le balisage avec la note moyenne obtenue et le nombre total d'avis pris en compte dans ce calcul.

Chacune de ces propriétés doit impérativement correspondre exactement à ce qui est visuellement affiché sur la page pour l'utilisateur : un prix balisé à 49 euros alors que la page affiche 59 euros, ou une disponibilité balisée comme InStock alors que le produit est explicitement marqué comme épuisé sur la page, constituent des incohérences que Google peut détecter et sanctionner via une action manuelle sur l'ensemble du site, comme évoqué plus haut dans cet article à propos du balisage trompeur.

Une fois ce bloc rédigé, le passer par l'outil de test des résultats enrichis avant publication permet de vérifier qu'aucune propriété obligatoire n'est manquante, et que la syntaxe JSON est valide sans erreur de formatage qui invaliderait l'ensemble du bloc. Cette vérification préalable, qui ne prend que quelques minutes, évite de découvrir l'erreur seulement plusieurs semaines plus tard via le rapport de Search Console, une fois que Google a déjà tenté et échoué à exploiter le balisage sur un nombre potentiellement important de pages similaires générées par le même gabarit.

Comment tester en local avant publication

Pour les équipes techniques qui développent un site avec un processus de mise en production structuré, valider le balisage JSON-LD directement dans l'environnement de développement, avant tout déploiement en production, permet de détecter une erreur de génération dès sa création plutôt qu'après coup. Plusieurs bibliothèques de validation JSON Schema, indépendantes de l'outil en ligne de Google, permettent d'intégrer cette vérification directement dans un pipeline d'intégration continue, de façon à bloquer automatiquement une mise en production si le balisage généré ne respecte pas la structure attendue pour le type schema.org concerné.

Cette approche préventive est particulièrement recommandée sur les sites où le balisage JSON-LD est généré dynamiquement à partir d'un grand nombre de champs de données saisis par différentes personnes au sein de l'organisation (équipe produit, équipe éditoriale) : plus le nombre de contributeurs et de champs de données impliqués est important, plus le risque d'incohérence ou de champ manquant augmente avec le temps, sans un mécanisme de vérification automatisé qui ne dépende pas d'une vigilance humaine constante et nécessairement faillible sur la durée.

Questions fréquentes

Les données structurées garantissent-elles l'apparition d'un résultat enrichi ? Non, en aucun cas. Elles rendent seulement la page éligible à un affichage enrichi potentiel, mais Google conserve toujours la décision finale d'afficher ou non le format enrichi correspondant, selon des critères de qualité globaux qui lui sont propres et qui ne sont pas documentés dans le détail au-delà des exigences techniques minimales de validité du balisage.

Faut-il baliser toutes les pages d'un site en données structurées ? Seulement les pages où un type schema.org pertinent existe réellement et correspond fidèlement au contenu affiché. Forcer un balisage générique sur des pages qui n'en ont pas l'usage naturel n'apporte aucun bénéfice réel et complexifie inutilement la maintenance technique du site sans contrepartie.

Le balisage schema.org peut-il remplacer une bonne rédaction de contenu ? Non, absolument pas. Les données structurées décrivent et complètent un contenu qui doit d'abord exister et être de qualité par lui-même — elles ne créent aucune information nouvelle et ne compensent en rien un contenu par ailleurs pauvre, incomplet, ou peu pertinent pour l'utilisateur.

Existe-t-il un risque à mal implémenter les données structurées ? Le principal risque n'est pas une pénalité directe pour une erreur de bonne foi (une propriété manquante, une syntaxe imparfaite), qui se traduit simplement par une non-éligibilité aux résultats enrichis concernés. Le risque réel et documenté concerne le balisage délibérément trompeur, qui peut entraîner une action manuelle affectant l'ensemble du site, une distinction importante à garder à l'esprit pour ne pas confondre une simple erreur technique corrigible avec une pratique sanctionnable.

Faut-il maintenir plusieurs blocs JSON-LD séparés ou un seul bloc regroupant tous les types ? Les deux approches sont techniquement valides selon la spécification. Regrouper les types étroitement liés dans un seul bloc (par exemple un Product et son Offer associée) facilite généralement la lecture et la maintenance, tandis que des blocs séparés peuvent avoir du sens pour des types plus indépendants les uns des autres, comme un balisage Organization commun à toutes les pages et un balisage Article spécifique à chaque contenu éditorial.

L'évolution du vocabulaire schema.org dans le temps

Le vocabulaire schema.org n'est pas figé : de nouveaux types et de nouvelles propriétés sont régulièrement ajoutés par la communauté qui le maintient, au fil de l'émergence de nouveaux besoins sur le web. Des types relativement récents comme ClaimReview, destiné au balisage de contenus de vérification factuelle, ou SpeakableSpecification, destiné à signaler les passages d'une page adaptés à une lecture audio par un assistant vocal, illustrent cette évolution continue du vocabulaire face à de nouveaux usages du web qui n'existaient pas nécessairement au moment de la création initiale du projet en 2011.

Cette évolution continue invite à une veille périodique plutôt qu'à une implémentation figée une fois pour toutes : un site qui a correctement balisé son contenu il y a plusieurs années selon les types alors disponibles peut avoir intérêt à revisiter régulièrement son balisage pour vérifier si de nouveaux types plus précis ou de nouvelles propriétés plus riches sont désormais disponibles pour mieux décrire son contenu qu'au moment de l'implémentation initiale.

Les données structurées et les autres moteurs de recherche

Bien que cet article se concentre largement sur l'usage que Google fait des données structurées, le vocabulaire schema.org a été conçu dès l'origine comme un standard partagé, également exploité par Bing, Yahoo et Yandex selon des modalités qui leur sont propres. Un site qui balise correctement son contenu selon schema.org bénéficie donc potentiellement de cette compatibilité sur plusieurs moteurs de recherche simultanément, sans avoir à dupliquer l'effort d'implémentation pour chacun d'entre eux séparément, contrairement à ce qu'imposeraient des formats propriétaires distincts.

Cette portée multi-moteurs renforce d'autant l'intérêt d'investir dans un balisage rigoureux et bien maintenu : l'effort technique consenti une seule fois profite potentiellement à l'ensemble de l'écosystème de recherche, plutôt qu'à un seul acteur, ce qui constitue un argument supplémentaire en faveur d'une implémentation soignée plutôt que superficielle, y compris pour des sites dont l'essentiel du trafic organique provient aujourd'hui principalement de Google.

Les principaux fournisseurs d'IA générative s'appuient eux aussi de plus en plus directement sur ce même vocabulaire schema.org pour interpréter le contenu d'une page de façon fiable, ce qui signifie concrètement qu'un balisage pensé et implémenté à l'origine pour les résultats enrichis classiques de Google profite également, sans effort supplémentaire particulier, à la visibilité du contenu dans les réponses génératives évoquées plus en détail dans l'article dédié à ce sujet sur ce blog — une convergence technique qui simplifie d'autant la priorisation des efforts pour un éditeur de site aux ressources limitées.

Qui doit porter la responsabilité de la maintenance des données structurées au sein d'une équipe ? Sur un site géré par plusieurs personnes aux compétences différentes, la tentation est grande de laisser cette responsabilité flotter entre l'équipe technique et l'équipe éditoriale sans qu'elle soit clairement attribuée. En pratique, la génération technique du balisage relève naturellement de l'équipe de développement, mais la justesse des données qui alimentent ce balisage (prix, disponibilité, auteur) dépend directement de l'équipe qui gère le contenu au quotidien — une clarification explicite des rôles respectifs évite que chacun suppose que l'autre partie surveille la cohérence du balisage dans la durée.

Le balisage schema.org doit-il être visible dans le code source consultable par n'importe qui ? Oui, par nature : le JSON-LD est intégré directement au HTML de la page et reste donc consultable par quiconque examine le code source, ce qui n'est ni un problème ni une exception, puisque son objectif même est d'être lu par des machines externes au site (robots de recherche, modèles de langage). Aucune information sensible ou confidentielle ne devrait, de toute façon, jamais figurer dans un balisage destiné à être exposé publiquement de cette manière.

Seoditum vérifie ce point automatiquement, avec preuve à l'appui, sur l'ensemble de votre site.