Données structurées : quels schémas prioriser et comment les implémenter en 2026

En SEO, les données structurées sont un balisage standardisé, le plus souvent en JSON-LD avec le vocabulaire Schema.org, qui décrit explicitement le contenu d’une page aux moteurs de recherche : ce produit coûte tel prix, cet article a été écrit par telle personne, cet événement a lieu à telle date. Depuis la suppression des résultats enrichis FAQ le 7 mai 2026, beaucoup de sites se demandent quels schémas méritent encore l’effort. La réponse dépend de votre type de site : un socle commun à tous, puis quelques schémas ciblés selon que vous publiez des articles, vendez des produits, gérez des établissements ou organisez des événements. Ce guide vous aide à prioriser, à implémenter proprement et à éviter les balisages qui ne servent plus.

01Données structurées : définition et formats

Le terme a deux sens. En informatique et en data, une donnée structurée est une donnée organisée selon un modèle fixe (une table, des colonnes typées), par opposition aux données non structurées comme un texte libre ou une image. En SEO, Google définit les données structurées, dans son introduction au balisage des données structurées, comme un format standardisé pour fournir des informations sur une page et classer son contenu. C’est ce second sens qui nous intéresse ici.

Concrètement, le balisage associe un vocabulaire (Schema.org, qui définit les types comme Product, Article ou Event et leurs propriétés) à un format d’écriture. Google accepte trois formats :

• JSON-LD : un bloc de code dans une balise script, séparé du HTML visible. C’est le format que Google recommande dans la plupart des cas, parce qu’il est le plus simple à implémenter et à maintenir.
• Microdata : des attributs ajoutés directement aux balises HTML du contenu.
• RDFa : une extension HTML5 qui ajoute elle aussi des attributs dans les balises.

Google précise qu’il peut lire un JSON-LD injecté dynamiquement, par exemple par JavaScript. Un balisage présent dans le HTML serveur reste toutefois plus robuste, notamment pour les autres moteurs et outils qui exploitent mal le rendu JavaScript. Dernier point essentiel : les données structurées rendent une page éligible à un affichage enrichi, elles ne le garantissent pas. Les propriétés obligatoires doivent être présentes, et Google décide ensuite de l’affichage.

02Ce qui a changé : FAQ, HowTo et types retirés

Le paysage des résultats enrichis s’est nettement resserré en quelques années :

• HowTo : plus affiché dans les résultats Google depuis 2023.
• FAQ : limité aux sites gouvernementaux et de santé faisant autorité depuis août 2023, puis supprimé pour tous le 7 mai 2026. Le rapport Search Console et le test des résultats enrichis correspondants ont été arrêtés en juin 2026. Notre article sur la fin des FAQ rich results et les schémas qui restent utiles détaille ce changement.
• Sept autres fonctionnalités annoncées comme progressivement retirées le 12 juin 2025 : Book Actions, Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement et Vehicle Listing.

La galerie officielle des données structurées prises en charge par Google liste encore environ vingt-cinq fonctionnalités, parmi lesquelles Article, Breadcrumb, Event, Job posting, Local business, Organization, Product, Profile page, Q&A, Recipe, Review snippet, Software app et Video. C’est cette liste, et non les anciens articles de blog, qui doit guider vos priorités.

Correction fréquente : un balisage FAQ ou HowTo n’est pas une erreur. Il reste valide au sens de Schema.org et ne pénalise pas la page. Il ne produit simplement plus d’affichage enrichi dans Google, et ne doit donc plus figurer dans une liste de priorités SEO.

03Quels schémas prioriser selon votre site

Socle commun : Organization, WebSite et BreadcrumbList

Ces trois types conviennent à presque tous les sites et demandent peu d’effort :

• Organization (ou un sous-type comme LocalBusiness) sur la page d’accueil ou la page « à propos » : nom, logo, URL, coordonnées, profils officiels via la propriété sameAs. Il aide Google à comprendre qui édite le site et à associer le bon logo.
• WebSite sur la page d’accueil : Google s’en sert notamment pour déterminer le nom du site affiché dans les résultats.
• BreadcrumbList sur les pages internes : il décrit la position de la page dans l’arborescence. Sur ordinateur, il peut remplacer l’URL brute par un fil d’Ariane lisible ; sur mobile, Google n’affiche plus que le domaine depuis janvier 2025.

Contenus éditoriaux : Article et ProfilePage

Pour un blog, un média ou une base de connaissances, le type Article (ou NewsArticle, BlogPosting) précise le titre, les images, les dates de publication et de mise à jour et l’auteur. L’auteur se décrit avec le type Person (nom, URL de la page auteur, profils sameAs). Person n’est pas un résultat enrichi en soi, mais il clarifie qui écrit, ce qui compte pour la compréhension des entités. Sur les pages auteur ou les profils de forum, le type ProfilePage figure dans la galerie de Google.

E-commerce : Product, Offer et avis

C’est le domaine où les données structurées gardent le plus d’effet visible. Le type Product, avec une Offer (prix, devise, disponibilité) et éventuellement AggregateRating et Review, alimente les extraits produits et les fiches marchandes. Points de vigilance :

• Prix et disponibilité doivent correspondre exactement à la page et, si vous utilisez Merchant Center, au flux produits.
• Les avis doivent être réels, visibles sur la page et collectés sur le produit concerné.
• Les avis qu’une entreprise publie sur elle-même (LocalBusiness ou Organization) ne génèrent pas d’étoiles dans Google.
• Les variantes (tailles, couleurs) se décrivent proprement plutôt que par une accumulation d’offres incohérentes.

Exemple typique : une boutique affiche des étoiles dans ses résultats pour certaines fiches seulement. L’analyse révèle que le module d’avis injecte AggregateRating uniquement lorsque le produit a au moins un avis, ce qui est normal, mais aussi que l’extension SEO ajoute un second bloc Product sans prix. Google reçoit deux descriptions concurrentes de la même fiche. La correction consiste à fusionner les deux sources dans un seul bloc Product, alimenté par le catalogue, puis à vérifier le résultat dans le test des résultats enrichis.

Local et événementiel : LocalBusiness et Event

Un commerce, un cabinet ou un réseau d’agences gagne à baliser chaque établissement avec LocalBusiness (adresse, horaires, téléphone, zone desservie), en cohérence avec les fiches Google Business Profile. Un organisateur de salons, de formations ou de concerts utilisera Event : nom, dates, lieu physique ou en ligne, statut (reporté, annulé), billetterie.

Pour un réseau d’agences, la règle est simple : une page par établissement, un bloc LocalBusiness par page, avec le sous-type le plus précis disponible dans Schema.org (par exemple un type de commerce ou de service professionnel plutôt que le type générique). Les horaires doivent suivre les changements saisonniers et les fermetures exceptionnelles. Pour les événements, pensez à mettre à jour le statut plutôt qu’à supprimer la page quand un événement est reporté : les internautes et les moteurs disposent ainsi d’une information exacte.

Vidéo, recettes, offres d’emploi et autres cas spécifiques

Certains types ne concernent qu’un secteur, mais y restent très utiles : VideoObject pour les pages dont la vidéo est le contenu principal, Recipe pour les sites culinaires, JobPosting pour les offres d’emploi, SoftwareApplication pour les logiciels et applications, Dataset pour les jeux de données, DiscussionForumPosting et QAPage pour les forums et les pages de questions-réponses générées par les utilisateurs. Attention à ne pas confondre QAPage, prévu pour une question unique avec des réponses d’utilisateurs, et l’ancien balisage FAQ.

04Implémenter les données structurées pas à pas

1. Cartographier les gabarits : listez les types de pages (accueil, catégorie, fiche, article, établissement) et associez à chacun le ou les types Schema.org pertinents.
2. Choisir le mode de génération : balisage généré par le CMS ou le thème, extension dédiée, ou développement sur mesure. Sur WordPress, les extensions SEO courantes produisent déjà un graphe de base (Organization, WebSite, Article, BreadcrumbList) : vérifiez ce qu’elles génèrent avant d’ajouter une couche, pour éviter les doublons.
3. Alimenter depuis les données réelles : prix, stock, dates et auteurs doivent provenir des mêmes champs que le contenu affiché, jamais d’une saisie parallèle.
4. Relier les entités : utilisez des identifiants (@id) pour relier l’article à son auteur et à l’organisation éditrice, plutôt que de répéter des blocs isolés.
5. Valider : test des résultats enrichis de Google pour l’éligibilité, validateur de balisage Schema.org pour la conformité au vocabulaire.
6. Déployer puis surveiller : rapports d’améliorations de Search Console, par type, pour repérer les erreurs et les avertissements.

Exemple minimal pour un article de blog, à adapter à vos URL et à vos données :

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Titre de l'article",
  "datePublished": "2026-09-26",
  "dateModified": "2026-09-26",
  "author": {
    "@type": "Person",
    "name": "Prénom Nom",
    "url": "URL de la page auteur"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Nom de l'organisation",
    "logo": "URL du logo"
  },
  "image": "URL de l'image principale"
}

Une remarque sur l’injection par un gestionnaire de balises : c’est une solution de dépannage acceptable pour tester un type sur quelques pages, puisque Google lit le JSON-LD ajouté en JavaScript. À grande échelle, elle crée une dépendance fragile entre le balisage et le contenu réel de la page, et elle échappe souvent aux contrôles des équipes de développement. Dès que le test est concluant, intégrez le balisage au gabarit côté serveur.

Le bloc d’exemple ci-dessus s’insère dans une balise script de type application/ld+json. Côté maintenance, une vérification automatisée évite les régressions silencieuses : un workflow n8n peut, chaque semaine, récupérer un échantillon d’URL par gabarit, extraire le JSON-LD, contrôler la présence des propriétés attendues (prix, disponibilité, dateModified) et signaler les écarts dans un Google Sheet ou par e-mail.

05Données structurées, IA et GEO

La question revient souvent : faut-il ajouter des schémas spécifiques pour apparaître dans les AI Overviews ou AI Mode ? La documentation Google « AI features and your website » est claire : aucun balisage Schema.org particulier n’est nécessaire, pas plus qu’un fichier dédié à l’IA. Parmi ses recommandations figure en revanche le fait de vérifier que les données structurées correspondent au contenu visible de la page.

Le rôle réaliste des données structurées dans une stratégie GEO est donc indirect :

• Désambiguïser les entités : une organisation, ses produits, ses auteurs et leurs profils officiels sont décrits sans ambiguïté.
• Fiabiliser les faits : prix, horaires, dates et disponibilités sont exposés dans un format lisible par les machines, à condition d’être à jour.
• Renforcer la cohérence : le même nom, le même logo et les mêmes identifiants sur le site, les profils sociaux, Merchant Center et Google Business Profile.

Exemple : un cabinet de conseil apparaît sous trois noms différents selon les pages de son site, ses profils sociaux et sa fiche d’établissement. Harmoniser le nom, déclarer Organization avec le logo officiel et les profils sameAs, puis relier chaque article à son auteur et à l’organisation ne garantit aucune citation, mais supprime une source d’ambiguïté pour tous les systèmes qui cherchent à identifier l’entité.

Hors de Google, chaque moteur conversationnel (ChatGPT Search, Perplexity, Copilot) a son propre fonctionnement : consultez sa documentation avant d’en tirer des conclusions, et ne promettez pas un gain de citations IA lié au seul balisage. Pour décider quels types méritent l’effort, les données d’adoption publiées par Schema.org apportent un éclairage utile ; notre article sur les types Schema.org les plus utilisés en 2026 les analyse.

Enfin, les données structurées ne remplacent pas le travail sur le contenu lui-même. Une réponse claire, structurée en paragraphes courts et en listes, reste la meilleure façon d’être repris dans un extrait. Notre guide des techniques pour décrocher un featured snippet complète ce point.

06Mesurer l’effet des données structurées

Un balisage n’a de valeur que s’il produit un effet observable. Trois niveaux de mesure sont disponibles dans Search Console :

• Les rapports d’améliorations par type : nombre d’éléments valides, avec avertissements ou invalides. Une chute soudaine des éléments valides signale souvent une régression de gabarit après une mise en production.
• Le filtre « Apparence dans les résultats de recherche » du rapport Performances : il isole les clics et impressions obtenus avec un affichage enrichi (extraits produits, fiches marchandes, extraits d’avis, vidéos selon les cas). C’est la meilleure façon de relier le balisage à un résultat.
• La comparaison avant/après sur un groupe de pages balisées, rapportée à un groupe témoin non modifié, sur des périodes comparables.

Deux précautions de lecture. D’abord, l’affichage enrichi n’est jamais garanti : une page valide peut ne pas l’obtenir sur toutes les requêtes. Ensuite, un gain de taux de clic mesuré sur quelques semaines peut venir d’autres causes (saisonnalité, évolution de la page de résultats). Documentez la date de déploiement, par exemple dans les annotations de Search Console, pour faciliter l’analyse.

Si le suivi montre qu’un type n’apporte ni affichage ni clics après plusieurs mois, ce n’est pas forcément une raison de le retirer : un balisage propre et exact ne coûte rien à maintenir s’il est généré automatiquement. En revanche, un balisage saisi à la main, qui dérive à chaque mise à jour de contenu, mérite d’être automatisé ou supprimé.

07Erreurs à éviter

• Baliser ce qui n’est pas visible : Google demande que le balisage décrive le contenu présent sur la page. Un avis, un prix ou une question absents de la page exposent à une action manuelle.
• Continuer à investir dans FAQ et HowTo pour l’affichage : ils ne produisent plus de résultats enrichis.
• Empiler les générateurs : thème, extension SEO et extension e-commerce qui produisent chacun leur propre Product ou Organization créent des doublons contradictoires.
• Laisser dériver les données : un prix promotionnel terminé ou un produit en rupture encore marqué « en stock » crée une incohérence avec la page et le flux marchand.
• Ignorer les avertissements : une propriété recommandée manquante n’empêche pas l’éligibilité, mais prive souvent l’affichage d’informations utiles.
• Attendre un effet de classement direct : les données structurées aident Google à comprendre et à afficher, elles ne font pas monter une page dans le classement à elles seules.

La bonne stratégie tient en une phrase : un socle propre sur tout le site, quelques types ciblés là où Google les affiche encore, des données alimentées par la source réelle et un contrôle régulier. Pour replacer ce chantier dans votre plan global, notre page SEO présente l’ensemble de la démarche.