Données structurées SEO en 2026 : balise moins de types, mais balise-les juste

Ton balisage schema.org ne te fera pas gagner une seule position. Google l'a répété assez souvent pour qu'on arrête d'en débattre : les données structurées ne sont pas un facteur de classement. Elles servent à deux choses. D'abord, rendre une page éligible aux résultats enrichis (prix, stock, étoiles, vidéo, fil d'Ariane). Ensuite, lever l'ambiguïté sur les entités dont parle ton site, ce qui alimente le Knowledge Graph et, par ricochet, les réponses des moteurs génératifs.

Concrètement, des données structurées SEO, c'est un bloc de code JSON-LD placé dans le HTML de la page, qui décrit son contenu avec le vocabulaire schema.org. Il dit par exemple : « cette page présente un Product, il coûte 89,90 €, il est en stock, il a une note moyenne de 4,6 sur 128 avis ». Le moteur lit l'information directement au lieu de la deviner dans le texte.

Sur la plupart des sites que j'audite, le problème est le même : on balise trop, et mal. Des FAQPage collées sur chaque article alors que Google les a quasiment retirées de la SERP depuis 2023. Des plugins qui empilent des descriptions concurrentes de la même entreprise. Des prix JSON-LD qui ne suivent plus le prix affiché depuis la dernière promo. En 2026, ce qui paie, c'est une poignée de types bien choisis, implantés au niveau des templates, alimentés par la vraie donnée du site et contrôlés à chaque mise en production.

Ce que le balisage dit à Google que ton HTML ne dit pas

Les données structurées sont des informations lisibles par les machines, ajoutées au code d'une page web pour décrire explicitement ses entités et leurs propriétés : type de contenu, auteur, prix, note, date, organisation. Elles reposent sur le vocabulaire schema.org et donnent ces informations aux moteurs de recherche sans qu'ils aient à interpréter le texte.

Deux couches qui doivent raconter la même chose

Ton HTML s'adresse à un humain. Un « 89,90 € » affiché en gros sous une photo, l'internaute comprend tout de suite que c'est le prix. Le crawler voit une chaîne de caractères parmi d'autres : un prix barré, le prix d'un accessoire en cross-sell, un seuil de livraison gratuite. Avec "price": "89.90" et "priceCurrency": "EUR", il n'a plus rien à interpréter.

Conséquence directe : les deux couches doivent concorder. Les règles générales de Google sur les données structurées sont explicites là-dessus. Baliser une information que l'utilisateur ne voit pas sur la page est une infraction aux consignes, et Google la traite comme telle.

Schema.org, un dictionnaire bien plus large que ce que Google exploite

Schema.orgVocabulaire standardisé de balisage structuré reconnu par Google, Bing et Yahoo. est le vocabulaire commun lancé en 2011 par Google, Bing, Yahoo et Yandex. Il compte plusieurs centaines de types, de Product à MedicalCondition, dont Google n'exploite qu'une petite fraction pour ses résultats enrichis. Un balisage valide au sens de schema.org peut donc très bien n'avoir aucun affichage possible dans Google. Une bonne partie des erreurs de cadrage que je croise en audit vient de cette confusion.

L'adoption n'est plus un sujet. Le Web Almanac 2024 du HTTP Archive mesure JSON-LDFormat recommandé par Google pour implémenter les données structurées dans le code source. sur environ 41 % des pages analysées, contre 34 % en 2022. Avoir du balisage ne te distingue donc de personne. Ce qui fait la différence, c'est sa justesse.

Ce que les données structurées rapportent vraiment en 2026

La plupart des articles positionnés sur ce sujet promettent que les données structuréesCode ajouté au HTML pour aider les moteurs à comprendre le contenu et générer des rich snippets. « améliorent ton référencement ». C'est faux. Et c'est ce discours qui pousse des équipes à baliser n'importe quoi en attendant un effet sur le classementPosition d'une page web dans les résultats de recherche pour une requête donnée. qui ne viendra jamais. Les gains réels se jouent sur trois terrains.

Les résultats enrichis qui existent encore

La liste a fondu. HowTo a disparu des résultats en 2023, et les extraits FAQ sont réservés depuis la même année aux sites gouvernementaux et de santé reconnus. En 2025, Google a retiré une série de types de niche, comme ClaimReview ou Estimated Salary, et supprimé le fil d'Ariane des résultats mobiles, où seul le domaine apparaît désormais.

Ce qui tient : Product (extraits produit et fiches marchand, avec prix, disponibilité, livraison et retours), les notes produit, Video, Recipe, Event, JobPosting et Organization pour le logo et les informations de l'entreprise. Pour un e-commerce, c'est là que se trouve l'essentiel du gain. Pour un site éditorial, le gain visible dans la SERP est devenu mince.

Le dilemme zero-click

Un résultat enrichi élargit ta surface dans la page de résultatsSearch Engine Results Page. Page affichée par un moteur de recherche en réponse à une requête utilisateur.. Mais s'il répond entièrement à la question (prix, horaires, note), l'internaute n'a plus besoin de cliquer. Sur une fiche produitPage dédiée à un produit, devant être optimisée avec description unique, images et données structurées., ça joue plutôt en ta faveur : le clic qui arrive est qualifié, le visiteur connaît déjà le prix. Sur une page informationnelle, le calcul est moins évident, tu peux gagner en visibilité et perdre du trafic dans le même mouvement.

Les entités, le Knowledge Graph et la GEO

C'est le gain le moins visible, et celui que je trouve le plus sous-estimé. Un Organization complet avec des sameAs vers tes profils officiels, ou un Person cohérent pour tes auteurs, aide Google à rattacher ton site à une entité identifiée du Knowledge GraphBase de connaissances de Google affichant des informations structurées sur des entités (personnes, entreprises, lieux).. Les AI Overviews s'appuient sur l'indexProcessus par lequel Google ajoute une page à sa base de données pour qu'elle puisse apparaître dans les résultats. et sur la compréhension des entités de Google. Côté ChatGPTAgent conversationnel d'OpenAI utilisant un LLM pour générer des réponses. ou PerplexityMoteur de recherche conversationnel basé sur l'IA, concurrent émergent de Google., les preuves publiques que le JSON-LD est lu tel quel restent minces.

Le balisage rend une entité non ambiguë. Il ne rend pas un contenu citable pour autant, ça c'est le travail du fond : une donnée originale, une réponse nette. Le balisage aide ensuite le moteur à savoir à qui attribuer ce qu'il cite.

Le bon type de données structurées pour chaque page

Pars du type de page plutôt que de la liste schema.org. Pour chaque template, pose-toi une seule question : quelle entité principale cette page décrit-elle, et Google en fait-il quelque chose ?

Fiche produit, le seul terrain où le retour est net

Les extraits produit et les fiches marchand sont les résultats enrichis qui déplacent encore des clics de façon mesurable. Renseigne name, image, offers (avec price, priceCurrency, availability), brand, les identifiants (gtin, sku) et aggregateRating, ce dernier uniquement si les avis sont visibles sur la page. Pour les déclinaisons taille ou couleur, Google prend en charge ProductGroup avec hasVariant et variesBy depuis 2024. Les politiques de livraison et de retour (OfferShippingDetails, MerchantReturnPolicy) comptent aussi pour les fiches marchand.

Une erreur revient sur beaucoup de catalogues : un balisage Product sur les pages catégories. Google réserve ce type aux pages consacrées à un produit prAlgorithme historique de Google évaluant l'importance d'une page selon ses backlinks. Toujours utilisé en interne.écis. Sur une liste de produits, au mieux ça ne sert à rien, au pire tu sors des guidelines.

Éditorial, événement, recette, vidéo

Pour un article : Article ou BlogPosting avec author (relié à un Person qui a sa propre page), datePublished, dateModified et image. N'attends pas d'affichage spectaculaire, mais l'auteur et la date deviennent clairs pour le moteur. Recipe, Event et VideoObject restent rentables si c'est ton cœur de métier. Sinon, ne les force pas.

Ce que tu peux arrêter de baliser

FAQPage sur chaque article de blog, HowTo sur les tutoriels, avis clientsÉvaluations laissées par les clients sur Google Business Profile. Facteur de ranking local. sur ta propre Organization ou ton LocalBusiness (Google n'affiche plus ces avis auto-attribués depuis 2019). Rien de tout ça ne casse quelque chose de grave. Ça alourdit les templates et ça noie les vraies erreurs sous des avertissements. Le pire, c'est l'impressionNombre de fois qu'une page apparaît dans les résultats de recherche, qu'elle soit cliquée ou non. que le chantier est fait.

JSON-LD, microdonnées ou RDFa : prends JSON-LD

Google le recommande. Il vit dans un bloc script séparé du rendu, se génère côté serveur à partir de tes données et se déploie sans toucher au HTML visible. Les microdonnées et RDFa sont mêlés aux attributs HTML : chaque refonteModification majeure du design ou de la structure d'un site. Risque SEO si mal gérée. de thème casse quelque chose, et personne ne s'en aperçoit avant que le rapport Search ConsoleOutil gratuit Google pour surveiller et optimiser la présence d'un site dans les résultats de recherche. chute. Le seul cas où je les garderais : un vieux thème qui les produit proprement et zéro budget de dev. Même là, prévois la migration au prochain chantier.

Implanter tes données structurées au niveau des templates

Le balisage se pose sur les templates, et chaque template se nourrit de la donnée de référence du site. Le reste (balisage à la main, injection via un gestionnaire de tags, plugins empilés) finit en dette technique. Beaucoup d'agences vendent un « audit données structurées » qui consiste à passer dix URLUniform Resource Locator. Adresse unique d'une page web. Une URL optimisée est courte, descriptive et contient le mot-clé. dans l'outil de Google. Ça n'apprend pas grand-chose. Le travail utile, c'est de cartographier les templates et de rattacher chaque propriété à sa source.

Cartographier les templates avant d'écrire une ligne

Crawle le site et regroupe les URL par template : fiche produit, catégorie, article, page auteur, page magasin, home. Sur un e-commerce de taille moyenne, tu dépasses rarement huit à dix templates réels. Pour chacun, remplis trois colonnes : l'entité principale, les propriétés qui existent vraiment en base, le résultat enrichi visé.

La colonne du milieu est celle que tout le monde saute. Si ton PIM ne stocke pas de GTIN, oublie gtin13. Si les avis viennent d'un widget tiers en iframe non indexable, ton aggregateRating n'a aucun contenu visible en face. La cartographie te montre ce que tu peux déclarer honnêtement. Ce que schema.org autorise en théorie est une autre liste, bien plus longue, et elle ne t'intéresse pas.

Construire un graphe d'entités avec des @id stables

Plutôt que des blocs JSON-LD isolés, sors un seul @graph par page, où chaque entité porte un @id stable, réutilisé partout. La convention la plus lisible : l'URL canoniqueBalise indiquant la version principale d'une page en cas de contenu dupliqué ou similaire. suivie d'un fragment.

{
  "@context": "httpsProtocole sécurisé de transfert de données. Facteur de ranking depuis 2014.://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.exemple.fr/#organization",
      "name": "Exemple",
      "url": "https://www.exemple.fr/",
      "logo": "https://www.exemple.fr/logo.png",
      "sameAs": ["https://www.linkedin.com/company/exemple"]
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://www.exemple.fr/chaussures/trail-x/#breadcrumbNavigation secondaire montrant le chemin hiérarchique de la page actuelle. Améliore l'UX et le SEO.",
      "itemListElement": [
        {"@type": "ListItem", "position": 1, "name": "Chaussures", "item": "https://www.exemple.fr/chaussures/"},
        {"@type": "ListItem", "position": 2, "name": "Trail X"}
      ]
    },
    {
      "@type": "Product",
      "@id": "https://www.exemple.fr/chaussures/trail-x/#product",
      "name": "Trail X",
      "image": "https://www.exemple.fr/img/trail-x.jpg",
      "sku": "TX-42",
      "brand": {"@type": "Brand", "name": "Exemple"},
      "offers": {
        "@type": "Offer",
        "price": "89.90",
        "priceCurrency": "EUR",
        "availability": "https://schema.org/InStock",
        "url": "https://www.exemple.fr/chaussures/trail-x/",
        "seller": {"@id": "https://www.exemple.fr/#organization"}
      },
      "aggregateRating": {"@type": "AggregateRating", "ratingValue": "4.6", "reviewCount": "128"}
    }
  ]
}

Le nœud Organization est déclaré dans le layout global, identique sur toutes les pages, avec le même @id. Les autres entités y renvoient (seller, publisher) au lieu de redéclarer une organisation à chaque fois. Tu obtiens une seule description de l'entreprise, la même sur tout le site.

Brancher le balisage sur la vraie donnée

Le JSON-LD doit être rendu côté serveurTechnique générant le HTML sur le serveur, facilitant l'indexation du contenu JavaScript. par le même code que celui qui affiche le prix et le stock, à partir des mêmes variables. Évite tout second appel à un cache différent et tout tag injecté en JavaScriptLangage de programmation web. Son mauvais usage peut bloquer l'indexation par les moteurs de recherche. après coup. Google sait lire du JSON-LD généré en JavaScript, mais il prévient lui-même que pour les produits, ça peut rendre les crawls Shopping moins fréquents et moins fiables. Le mapping de availability doit couvrir tous les états réels : en stock, rupture, précommande, arrêté. Un produit en rupture balisé InStock, c'est une fiche marchand rejetée et une infraction aux règles.

CMS : une seule source par type

Le doublon est l'erreur la plus fréquente sur les sites sous CMS. Sur WordPress, le plugin SEOSearch Engine Optimization. Ensemble des techniques visant à améliorer le positionnement d'un site web dans les résultats naturels des moteurs de recherche. sort un graphe JSON-LD complet pendant que le thème ajoute ses propres microdonnées. Sur Shopify, le thème intègre un Product et l'application d'avis en ajoute un second. Sur Prestashop, le module dédié cohabite avec le balisage natif du thème. Choisis un seul générateur par type et coupe les autres. Le test est simple : une fiche produit contient exactement un nœud Product. S'il y en a deux, tu as un doublon à traiter.

Tester le balisage : la validation Google ne suffit pas

Le test des résultats enrichis qui affiche « valide » sur une URL ne te dit rien sur les 4 000 autres, ni sur la correspondance entre le prix déclaré et le prix affiché. Passer la validation syntaxique, c'est le minimum. Le contrôle qualité commence après.

Trois outils, trois angles morts

Le test des résultats enrichis de Google rend la page et ne vérifie que les types que Google prend en charge, une URL à la fois. Le Schema Markup Validator (validator.schema.org) contrôle la syntaxe sur tout le vocabulaire schema.org, sans rien dire de l'éligibilité. Les rapports « Améliorations » de la Search Console couvrent tout le site, mais sur un échantillon et avec plusieurs jours de retard. Les trois servent. Aucun ne vérifie la cohérence avec le contenu visible.

Le contrôle de cohérence à l'échelle

Lance un crawl avec extraction personnalisée (Screaming Frog, Sitebulb ou n'importe quel crawler sérieux le fait). Sur chaque fiche produit, extrais quatre éléments : le bloc //script[@type="application/ld+json"], le prix affiché via son sélecteur CSS, la mention de disponibilité visible et le nombre de nœuds Product dans le JSON-LD. Tu parses, tu compares, et ça donne ce type d'export :

La deuxième ligne, c'est une promo non répercutée. La troisième cumule un stock faux et un doublon. Sur le prix et la disponibilité, la tolérance est nulle : un écart sur un template veut dire que le problème vient du code, donc qu'il touche toutes les pages dans le même cas.

Erreur, avertissement, rien du tout

• Une erreur critique rend l'élément inéligible. Corrige au niveau du template, en priorité absolue si c'est la fiche produit.
• Un avertissement signale une propriété recommandée manquante. Ajoute-la si la donnée existe. Si elle n'existe pas, laisse l'avertissement : inventer un GTIN ou un nombre d'avis pour faire passer l'indicateur au vert, c'est du spamTechniques manipulatrices visant à tromper les moteurs de recherche..
• Un balisage valide mais jamais affiché dépend de Google, qui tient compte de la qualité de la page et de la confiance qu'il accorde au site. Retoucher le JSON-LD n'y changera rien.
• Une chute brutale des éléments valides dans la Search Console signale presque toujours une mise en production qui a cassé un template. Compare le code avant et après la release.

Les erreurs qui coûtent plus cher qu'une absence de balisage

Un balisage trompeur peut te valoir une action manuelle pour données structurées non conformes, et tu perds alors tous les résultats enrichis du site. Les déclencheurs sont connus : avis inventés ou importés sans être visibles sur la page, notes auto-attribuées à l'entreprise, contenu balisé qui n'apparaît nulle part, événements fictifs pour occuper la SERP.

D'autres erreurs ne déclenchent rien de spectaculaire, mais brouillent ton entité. Trois Organization aux noms légèrement différents selon le plugin. Un dateModified qui se met à jour à chaque déploiement alors que le contenu n'a pas bougé. Des sameAs vers des profils abandonnés. À chaque fois, le moteur reçoit des versions contradictoires de la même entité et doit deviner laquelle croire.

Aucune donnée structurée ne rattrapera une page faible, un maillage interne bancal ou une offre moins chère ailleurs. Le balisage rend lisible ce qui existe déjà. Sur beaucoup de sites, le chantier le plus rentable de la semaine consiste à supprimer du balisage, pas à en ajouter.

Questions fréquentes