Comprendre et utiliser les données structurées sur WordPress

Les données structurées restent invisibles pour la majorité des visiteurs. Elles apparaissent dans le code de la page afin de décrire explicitement ce qu’elle contient : un article, une organisation, un produit, un événement, une vidéo ou encore un fil d’Ariane.

Ce balisage aide les moteurs de recherche à identifier la nature des informations et les relations entre elles. Il peut également rendre une page éligible à certaines présentations enrichies dans les résultats Google. Le terme « données structurées » désigne ainsi un format standardisé utilisé pour fournir des indications précises sur le contenu d’une page.

Concernant les données structurées WordPress, la principale difficulté ne réside pourtant pas dans l’ajout du premier schéma. Le thème, l’extension SEO, un plugin métier ou un développement spécifique peuvent déjà produire leurs propres blocs JSON-LD. Une nouvelle configuration ajoutée sans inventaire préalable risque alors de dupliquer une organisation, de déclarer deux types principaux différents ou de publier des valeurs contradictoires.

Notre méthode commence donc par l’observation de ce qui existe réellement. Nous identifions d’abord les données structurées présentes dans le code public, leur origine et leur rôle. L’ajout d’un nouveau balisage intervient uniquement lorsqu’il complète cette structure sans la rendre plus difficile à comprendre ou à maintenir.

Ce que les données structurées apportent réellement

Les moteurs analysent déjà le texte, les images, les liens et la structure HTML d’une page. Les données structurées ajoutent une couche d’explication plus formelle. Elles attribuent un type à une entité et associent cette entité à des propriétés précises.

Une page consacrée à un événement peut ainsi déclarer son nom, sa date, son lieu et son organisateur. Un article peut indiquer son titre, son auteur, ses dates de publication et de modification. Cette précision réduit une partie de l’ambiguïté que produirait une lecture fondée uniquement sur le contenu visible.

Un vocabulaire explicite pour décrire le contenu

Prenons une page qui mentionne Evolyon, Lyon, une adresse et un numéro de téléphone. Sans balisage, le moteur doit déduire les relations entre ces informations. Avec un type Organization ou un sous-type adapté, il devient possible de déclarer explicitement qu’Evolyon est une organisation, que l’adresse correspond à son implantation et que le numéro constitue un moyen de contact.

Le même principe s’applique à un article. Le type BlogPosting indique que la page présente une publication éditoriale. Les propriétés headline, author, datePublished ou dateModified précisent ensuite ses principales caractéristiques.

Les données structurées ne remplacent donc pas le contenu visible. Elles en proposent une représentation organisée, destinée aux systèmes capables d’interpréter ce vocabulaire.

Des résultats enrichis sans promesse d’affichage

Certaines données structurées ouvrent l’accès à des résultats enrichis. Un produit peut afficher son prix ou sa disponibilité, un événement sa date, une recette son temps de préparation et une vidéo une miniature spécifique.

Cette éligibilité ne garantit toutefois aucun affichage particulier. Google choisit la présentation qu’il juge la plus adaptée selon la requête, le contexte, l’appareil et d’autres signaux. Une page parfaitement valide dans le test des résultats enrichis peut donc conserver une apparence classique dans la recherche. Les règles générales de Google sur les données structurées précisent clairement cette absence de garantie.

Cette distinction évite une attente fréquente : ajouter un schéma n’entraîne pas automatiquement l’apparition d’étoiles, d’images supplémentaires ou d’un bloc enrichi. Le balisage constitue une condition technique pour certaines fonctionnalités, pas une commande adressée à Google.

Aucun raccourci vers de meilleures positions

Les données structurées ne remplacent ni la qualité du contenu, ni l’autorité du site, ni l’architecture éditoriale. Elles n’améliorent pas artificiellement une page dont la réponse reste faible, imprécise ou déconnectée de l’intention de recherche.

Nous ne traitons jamais le balisage Schema comme une couche SEO autonome. Il vient préciser une page déjà pertinente, bien structurée et intégrée à un véritable travail de référencement WordPress. Lorsqu’un contenu manque de profondeur ou qu’une architecture reste confuse, l’ajout de JSON-LD ne résout pas le problème.

La même prudence s’applique aux discours qui présentent les données structurées comme un levier direct de visibilité dans les moteurs génératifs. Elles aident les systèmes à interpréter des entités, mais elles ne remplacent pas les fondamentaux communs au SEO et GEO : contenu distinctif, sources crédibles, organisation lisible et réputation de marque.

Distinguer Schema.org, JSON-LD et résultats enrichis

Les expressions Schema.org, JSON-LD et résultats enrichis apparaissent souvent dans les mêmes explications. Elles désignent pourtant trois niveaux différents.

Schema.org fournit le vocabulaire. JSON-LD représente le format d’intégration utilisé pour inscrire ce vocabulaire dans une page. Les résultats enrichis correspondent enfin à certaines présentations proposées par Google à partir de types qu’il prend officiellement en charge.

Schema.org fournit le vocabulaire

Schema.org rassemble des types et des propriétés destinés à décrire des entités. Organization, Person, Article, Product, Event, Service ou BreadcrumbList font partie de ce vocabulaire.

Chaque type hérite également de propriétés plus générales. Un service possède par exemple un nom, une description, un prestataire, une zone desservie ou des offres. Schema.org définit ainsi Service comme une prestation fournie par une organisation ou une personne.

Le choix du type demande une lecture attentive de la page. Le but n’est pas de sélectionner le mot qui semble le plus avantageux, mais celui qui représente réellement l’entité principale.

JSON-LD organise ces informations dans la page

Google accepte trois formats principaux : JSON-LD, Microdata et RDFa. JSON-LD reste généralement recommandé, notamment parce qu’il sépare le balisage du contenu HTML et facilite la représentation de relations imbriquées.

Un bloc simplifié peut prendre cette forme :

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Comprendre et utiliser les données structurées sur WordPress",
  "datePublished": "2026-09-01",
  "publisher": {
    "@id": "https://www.evolyon.fr/#organization"
  }
}
</script>

Cet exemple illustre la logique du format, mais il ne constitue pas un modèle complet à copier tel quel. Les propriétés utiles varient selon le type choisi, le contenu visible et les recommandations du moteur concerné.

L’attribut @id joue un rôle particulièrement intéressant. Il attribue une identité stable à une entité et facilite les relations entre plusieurs blocs. Un article peut ainsi désigner comme éditeur la même organisation déjà définie ailleurs dans le graphe.

Google ne reprend qu’une partie du vocabulaire

Un type valide dans Schema.org ne bénéficie pas nécessairement d’une fonctionnalité spécifique dans Google. La documentation Schema.org décrit un vocabulaire beaucoup plus large que la galerie des données structurées officiellement exploitées dans les résultats enrichis.

La galerie Google des fonctionnalités de données structurées répertorie notamment Article, Breadcrumb, Event, Local Business, Organization, Product, Review snippet et Video. Google recommande donc d’utiliser sa propre documentation comme référence pour le comportement dans ses résultats, même lorsqu’un autre type reste parfaitement valide dans Schema.org.

Le type Service offre un bon exemple. Schema.org le reconnaît et lui associe de nombreuses propriétés utiles, mais Google ne le présente pas comme une fonctionnalité autonome dans sa galerie des résultats enrichis. Un balisage Service peut donc décrire précisément une prestation sans produire de présentation spéciale dans la SERP.

Cette nuance évite de confondre trois états différents :

• un balisage syntaxiquement valide ;
• une entité correctement décrite selon Schema.org ;
• une page éligible à un résultat enrichi précis dans Google.

Choisir un balisage adapté au rôle de chaque page

Le bon schéma dépend avant tout de la fonction éditoriale de la page. Une page d’accueil, un article, une fiche produit et une page de service ne décrivent pas le même objet principal.

L’erreur fréquente consiste à raisonner à partir des options disponibles dans un plugin. Un générateur propose de nombreux types, mais leur présence dans l’interface ne signifie pas qu’ils conviennent tous au contenu.

Organization, LocalBusiness et Service

Le balisage Organization rassemble les informations liées à l’identité de l’entreprise : nom officiel, logo, adresse, coordonnées, URL ou profils de référence. Google recommande de le placer sur la page d’accueil ou sur une page unique consacrée à l’organisation, plutôt que de répéter un bloc complet et autonome sur chaque URL. La documentation consacrée au balisage Organization détaille les propriétés attendues.

LocalBusiness correspond à une organisation disposant d’une présence locale pertinente pour son activité. Schema.org propose plusieurs sous-types plus précis. Une entreprise implantée physiquement ne choisit pas automatiquement le type le plus générique : la description gagne en exactitude lorsqu’elle reflète réellement la nature de l’établissement.

Service décrit quant à lui la prestation elle-même. Il peut identifier son prestataire, la zone couverte, le type de service et les offres associées. Ce type ne remplace ni Organization ni LocalBusiness : l’organisation représente l’entreprise, tandis que Service représente ce qu’elle propose.

Pour une agence comme Evolyon, cette distinction facilite la lecture du graphe. L’agence conserve une identité unique et stable, puis ses pages commerciales décrivent les prestations qui lui sont rattachées.

Article, BlogPosting et NewsArticle

Google accepte Article, BlogPosting et NewsArticle pour les contenus éditoriaux. Les trois types appartiennent à la même famille, mais leur niveau de précision diffère.

BlogPosting convient naturellement à une publication de blog. NewsArticle s’adresse davantage aux contenus d’actualité. Article reste un type plus générique lorsqu’aucun sous-type ne correspond mieux à la publication. Google recommande notamment les propriétés liées à l’auteur, aux dates, au titre et à l’image représentative dans sa documentation sur les données structurées Article.

Le choix ne repose pas sur le résultat enrichi espéré, mais sur la nature du contenu. Qualifier un article de conseil en NewsArticle uniquement pour lui donner une apparence plus importante créerait une information trompeuse.

Les dates méritent également une attention particulière. datePublished correspond à la première publication, tandis que dateModified décrit une mise à jour réelle. Une modification automatique ou un simple changement technique ne devrait pas transformer artificiellement l’ancienneté éditoriale de la page.

Product, Event, Video et BreadcrumbList

Le type Product convient à une page qui présente réellement un produit, avec les informations attendues sur l’offre, le prix ou la disponibilité. Une page commerciale décrivant une prestation ne devient pas un produit uniquement parce qu’elle affiche un tarif.

Event s’applique aux événements accessibles au public et décrits par des informations concrètes. VideoObject qualifie une vidéo qui occupe une place réelle dans la page et fournit les données nécessaires à son identification. Ces types restent soumis à leurs consignes spécifiques, qui évoluent au fil des changements apportés aux fonctionnalités de recherche.

BreadcrumbList possède une fonction différente. Il décrit la position de la page dans la hiérarchie du site, et non son sujet principal. Il coexiste donc naturellement avec un article, un produit ou une page d’événement.

Google accepte d’ailleurs plusieurs entités sur une même page lorsque chacune correspond au contenu visible. Elles peuvent être imbriquées ou déclarées séparément, puis reliées par leurs identifiants lorsque leur relation mérite d’être explicitée.

Le cas révélateur du balisage FAQ

Pendant plusieurs années, de nombreuses extensions SEO ont encouragé l’ajout de FAQPage afin d’obtenir des questions et réponses directement visibles dans Google. Cette pratique a conduit à baliser automatiquement des blocs FAQ sur un grand nombre de sites.

La situation a changé. Google a cessé d’afficher les résultats enrichis FAQ à partir du 7 mai 2026, puis a retiré la documentation correspondante en juin. FAQPage reste un type Schema.org, mais son ajout ne génère plus de fonctionnalité FAQ dans Google Search.

Ce changement illustre un principe essentiel : une configuration pertinente à un instant donné ne reste pas nécessairement utile indéfiniment. Les fonctionnalités prises en charge évoluent, et certaines disparaissent entièrement.

Nous ne conservons donc pas un balisage uniquement parce qu’il a autrefois amélioré un score d’extension ou déclenché un résultat enrichi. Lorsqu’une fonctionnalité disparaît, nous réévaluons sa valeur réelle, sa maintenance et son intérêt pour les autres systèmes susceptibles de l’interpréter.

WordPress génère souvent déjà des données structurées

L’administration WordPress ne montre pas toujours l’ensemble du balisage publié sur une page. Une extension SEO peut générer un graphe JSON-LD global, tandis qu’un plugin métier ajoute un second bloc pour un produit, une recette ou un événement.

Le thème lui-même peut également intégrer du Microdata ou du JSON-LD. Une fonctionnalité développée sur mesure complète parfois cette structure. Le résultat final provient alors de plusieurs couches qui ne partagent ni la même interface ni la même logique.

Plusieurs outils peuvent publier du JSON-LD

Rank Math gère les schémas généraux du site, les types associés aux contenus et des modèles réutilisables. Sa version Pro inclut également un générateur personnalisé, des variables dynamiques et des conditions d’affichage destinées à appliquer un modèle à plusieurs contenus. La documentation du générateur Schema de Rank Math présente ces différentes possibilités.

Une extension métier ajoute parfois son propre balisage. Un plugin d’événement connaît les dates et lieux, une solution e-commerce connaît les prix et la disponibilité, tandis qu’un outil vidéo dispose des miniatures et durées.

Cette spécialisation n’est pas un problème en soi. Le risque apparaît lorsque plusieurs outils décrivent la même entité sans coordination. Deux blocs Organization avec des adresses différentes ou deux Product associés à des prix divergents rendent l’ensemble plus difficile à interpréter et à maintenir.

Les doublons ne déclenchent pas toujours une erreur visible

Deux blocs similaires ne produisent pas systématiquement une erreur rouge dans les outils de validation. Ils peuvent respecter la syntaxe tout en publiant des informations redondantes ou contradictoires.

Le problème devient alors sémantique plutôt que syntaxique. Quel bloc représente l’organisation principale ? Quelle URL identifie l’article ? Quel prix correspond réellement à l’offre ? Le validateur ne tranche pas toujours ces questions, car chacune des déclarations reste techniquement correcte prise isolément.

Il faut également distinguer un doublon inutile de plusieurs entités légitimes. Un article associé à une vidéo et à un fil d’Ariane contient plusieurs objets différents, sans répétition anormale. Google accepte explicitement cette coexistence lorsque les éléments décrivent fidèlement la page.

Le code rendu reste la seule preuve

Avant d’ajouter un schéma sur WordPress, nous examinons toujours le code réellement servi au visiteur et aux moteurs. Une option cochée dans Rank Math ou dans un plugin décrit une intention de configuration. Elle ne confirme pas à elle seule le JSON-LD présent sur la page publique.

Notre contrôle suit généralement trois niveaux. Nous identifions d’abord les blocs structurés et leurs types. Nous vérifions ensuite les relations entre les entités, notamment les @id. Nous comparons enfin les valeurs déclarées avec le contenu visible et les informations réelles de l’entreprise.

Cette méthode révèle des situations que l’interface masque facilement : un ancien plugin continue à publier un balisage, un modèle s’applique à une catégorie imprévue ou une valeur dynamique reste vide sur certains contenus.

L’objectif n’est pas de produire le graphe le plus volumineux. Il consiste à obtenir une représentation fidèle, compréhensible et stable.

Ajouter le balisage sans multiplier les sources

Une fois l’inventaire terminé, la mise en œuvre repose sur un principe simple : utiliser la source la plus adaptée, puis éviter de reproduire la même responsabilité ailleurs.

Une extension SEO couvre généralement les besoins courants d’un site vitrine ou d’un blog. Un développement personnalisé devient pertinent lorsque le modèle de données réel dépasse les options disponibles ou nécessite des relations spécifiques.

Centraliser la gestion dans Rank Math lorsque le modèle suffit

Rank Math propose des types courants, des modèles et des variables capables de reprendre les informations déjà présentes dans WordPress. Cette centralisation simplifie les changements de titre, d’auteur, d’image ou de date, puisque le balisage évolue avec le contenu.

Sur Evolyon, nous privilégions cette logique dès que le modèle correspond au besoin. Le choix ne repose pas sur la volonté d’utiliser toutes les fonctions de l’extension, mais sur la recherche d’une source de vérité identifiable.

Une configuration par type de contenu reste généralement préférable à des réglages manuels dispersés sur chaque page. Elle réduit les écarts et facilite les contrôles lorsqu’un modèle évolue.

Cette automatisation demande néanmoins des vérifications. Une variable vide, une image absente ou une condition d’affichage trop large peut affecter un ensemble entier de pages.

Réserver le JSON-LD personnalisé aux besoins spécifiques

Le balisage personnalisé trouve son intérêt lorsqu’une page présente une structure métier qui n’entre pas dans un modèle standard.

Une offre comprenant plusieurs prestations, zones géographiques et modalités tarifaires peut par exemple nécessiter une organisation plus détaillée. Un site utilisant des champs ACF peut également construire son JSON-LD à partir de données administrées directement dans WordPress.

Cette liberté implique une responsabilité plus forte. Le code personnalisé doit reprendre les informations réelles, gérer les valeurs absentes et rester compatible avec les évolutions du contenu.

Un schéma écrit une fois puis oublié devient rapidement un « boulet » technique. Une modification de l’offre, une nouvelle adresse ou un changement d’auteur risque alors de laisser dans le code une information obsolète.

Relier les entités plutôt que les empiler

Un graphe utile ne juxtapose pas seulement plusieurs types. Il exprime leurs relations.

L’article est publié par une organisation. La vidéo illustre l’article. Le service est fourni par l’entreprise. Le fil d’Ariane situe la page dans l’architecture du site.

Les identifiants @id servent à relier ces objets sans répéter leur définition complète. Cette structure évite par exemple de recréer une nouvelle organisation à chaque fois qu’un article mentionne son éditeur.

Google indique que des éléments distincts peuvent être imbriqués ou déclarés séparément. Lorsque la relation apporte du sens, un identifiant commun aide le moteur à comprendre qu’ils appartiennent au même ensemble.

Notre préférence va à un graphe relativement sobre, mais correctement relié. Une succession de blocs indépendants peut contenir davantage de propriétés tout en décrivant moins bien la réalité du site.

Décrire uniquement le contenu visible

Le balisage doit représenter ce que le visiteur trouve réellement sur la page. Google exclut notamment les informations cachées, trompeuses ou sans rapport avec le sujet principal.

Une page ne devrait pas déclarer une note moyenne si aucun avis correspondant n’est visible. Un prix indiqué dans le JSON-LD doit refléter l’offre présentée. Un événement marqué comme disponible nécessite des informations actuelles et accessibles.

Cette règle concerne également les propriétés recommandées. Ajouter toutes les options disponibles n’améliore pas forcément le balisage. Google privilégie des informations moins nombreuses mais complètes et exactes plutôt qu’un ensemble large de valeurs approximatives.

Valider et maintenir les données structurées

Une validation réussie ne marque pas la fin du travail. Elle répond à une question précise à un instant donné : le balisage analysé respecte-t-il la syntaxe et les attentes connues de l’outil ?

La qualité durable repose ensuite sur le contrôle du rendu, le suivi dans Search Console et une nouvelle vérification après les changements qui affectent WordPress.

Le test des résultats enrichis et le validateur Schema.org

Le test des résultats enrichis de Google analyse les fonctionnalités officiellement prises en charge dans Search. Il indique les éléments valides, les erreurs critiques et certaines recommandations liées à l’éligibilité.

Le validateur Schema.org poursuit un objectif plus large. Il extrait le JSON-LD, le Microdata et le RDFa, affiche le graphe détecté et identifie notamment les erreurs de syntaxe dans le vocabulaire Schema.org.

Les deux outils répondent donc à des questions différentes :

• le balisage est-il valide selon le vocabulaire utilisé ?
• correspond-il à une fonctionnalité prise en charge par Google ?
• contient-il les propriétés nécessaires à cette fonctionnalité ?

Un schéma Service peut ainsi être correctement interprété par le validateur Schema.org sans apparaître comme un résultat enrichi éligible dans le test Google. Ce comportement ne révèle pas nécessairement une erreur.

Search Console ne montre pas l’ensemble du graphe

Les rapports de résultats enrichis de Google Search Console indiquent les éléments valides ou invalides détectés pour les types officiellement pris en charge.

Ils ne constituent pas un inventaire exhaustif de toutes les données structurées du site. Google précise que ces rapports affichent un échantillon et qu’un rapport n’apparaît que si un balisage valide correspond à un type de résultat enrichi pris en charge.

L’absence d’un rapport Service ou Organization ne signifie donc pas automatiquement que le balisage est absent. L’inspection d’URL et les outils de test apportent une lecture plus précise sur une page donnée.

À l’inverse, la présence d’un rapport valide ne garantit toujours pas que Google affichera la fonctionnalité dans ses résultats.

Contrôler après chaque changement structurel

Un changement de thème, d’extension SEO ou de plugin métier justifie une nouvelle vérification. La même vigilance s’applique après l’ajout de WooCommerce, la création d’un nouveau type de contenu ou la refonte d’un template.

Nous considérons les données structurées comme une composante technique vivante du site. Elles suivent les contenus, l’architecture et les outils qui les génèrent. Une configuration validée avant une refonte ne reste pas automatiquement pertinente après la mise en ligne.

Le contrôle doit porter sur plusieurs pages représentatives, pas seulement sur l’accueil. Un article, une page de service, une archive, une fiche produit et un contenu atypique peuvent recevoir des schémas différents.

Cette sélection révèle plus facilement une condition mal configurée ou un modèle appliqué au mauvais type de page.

Mesurer l’impact sans surinterpréter

Google recommande d’évaluer l’effet du balisage sur un groupe de pages disposant déjà d’un historique suffisant. La comparaison avant et après doit tenir compte de la saisonnalité et des autres modifications réalisées pendant la période.

Cette mesure reste délicate. Une hausse du CTR peut venir d’une présentation enrichie, d’un changement de position ou d’une évolution de la demande. À l’inverse, un balisage utile ne produit pas nécessairement un résultat visible sur toutes les requêtes.

Nous évitons donc d’attribuer trop rapidement une variation à Schema.org. Search Console fournit des indices, mais l’analyse nécessite de replacer ces données dans l’évolution générale de la page.

Des données structurées utiles restent simples à maintenir

Les données structurées WordPress apportent une lecture explicite du contenu, de ses entités et de leurs relations. Elles rendent certaines pages éligibles à des résultats enrichis et facilitent l’interprétation de l’organisation générale du site.

Leur efficacité repose moins sur le nombre de types ajoutés que sur la qualité de la représentation. Une organisation définie une seule fois, un article correctement relié à son éditeur et un service décrit avec des informations exactes forment une base plus solide qu’une accumulation de blocs indépendants.

La bonne démarche commence donc par un inventaire du rendu actuel. Elle se poursuit par le choix du type adapté, la désignation d’une source principale, la validation dans plusieurs outils et le contrôle régulier des pages publiques.

Cette méthode correspond à notre manière d’aborder le référencement WordPress : comprendre avant d’ajouter, simplifier lorsque plusieurs outils se chevauchent et maintenir uniquement ce qui apporte une information réelle.

Les données structurées atteignent alors leur véritable objectif. Elles ne cherchent pas à influencer artificiellement les moteurs, mais à leur transmettre une représentation fidèle, précise et durable du contenu publié.