Après avoir vu ce que les plugins SEO font déjà, il reste une question pratique : que faut-il vraiment baliser sur un site WordPress ?
La tentation est grande de répondre par une liste : organisation, article, auteur, fil d’Ariane, produit, avis, événement, offre d’emploi, service, contact, page de profil, liste, catégorie, établissement local.
Cette liste existe. Elle est utile. Mais elle ne suffit pas.
Une première réponse consiste à traiter les entités liées aux Rich Results Google : fil d’Ariane, produit, avis, événement, offre d’emploi, vidéo, et autres fonctionnalités officiellement prises en charge. C’est une application minimale, utile pour la recherche classique.
Mais un site ne se résume pas à ce que Google peut afficher dans ses résultats enrichis. Schema.org permet de décrire une organisation plus globale : l’entreprise, ses établissements, ses auteurs, ses pages, ses listes, ses services, ses produits, ses profils publics et les relations entre tous ces éléments.
Le bon raisonnement n’est pas : “quelles balises peut-on ajouter ?” Le bon raisonnement est : “quelles entités le site doit-il rendre plus claires ?”
Une entreprise, un auteur, une succursale, une fiche produit, une catégorie WooCommerce, une page de service, ou une page de contact ne se balisent pas pour décorer le code. Elles se balisent parce qu’elles représentent quelque chose que les moteurs, les crawlers et les IA doivent comprendre correctement.
À garder en tête
Les données structurées ne sont pas une recette magique. Elles ne garantissent ni position, ni Rich Result, ni citation par une IA.
Dans cette série, elles sont traitées comme une couche de clarification : elles aident à déclarer et relier des preuves qui doivent déjà exister dans le contenu visible, les avis, les profils, les produits, la fiche locale et les sources externes.
1. On ne commence pas par Schema.org, on commence par la carte réelle du site
Avant d’écrire du JSON-LD, il faut regarder le site comme un système.
Qui publie ? Qui écrit ? Quels services sont proposés ? Où l’entreprise intervient-elle ? Existe-t-il plusieurs établissements ? Quels produits sont vendus ? Les produits appartiennent-ils à des catégories, à des marques, à des gammes, à des producteurs ? Les pages de blog sont-elles liées à des auteurs crédibles ? Les avis concernent-ils l’entreprise entière, un établissement précis ou un produit ?
Les données structurées ne doivent pas inventer cette organisation. Elles doivent la rendre plus explicite.
Elles s’adaptent au site. On part des vraies données disponibles, on les interprète, puis on les range dans les types et propriétés Schema.org les plus adaptés.
Cette étape demande parfois un choix. Une page peut être une page de service, une page locale, une page de collection ou une page éditoriale selon son rôle réel. Une entreprise peut être décrite comme une organisation globale, un établissement local, ou une organisation avec plusieurs établissements. Une page auteur peut être une simple archive WordPress ou devenir une vraie page de profil.
Il n’y a donc pas toujours une seule réponse mécanique. Il faut comprendre la fonction de la page avant de choisir le balisage.
- pages visibles ;
- types de contenus WordPress ;
- catégories et taxonomies ;
- auteurs ;
- services ;
- établissements ;
- produits ;
- avis ;
- profils publics ;
- fiches Google Business Profile ;
- relations entre les pages.
Ensuite seulement, on choisit les types Schema.org utiles.
2. La base commune doit clarifier le site, l’organisation et la navigation
Sur presque tous les sites, une base revient : le site lui-même, l’entité qui le porte, les pages principales et le chemin de navigation.
Un site WordPress n’est pas seulement une collection de pages. Il possède un nom, une URL principale, parfois une fonction de recherche interne, une organisation éditoriale et des contenus reliés entre eux.
Le balisage WebSite et les balisages de page aident à déclarer cette base. Ils permettent de dire : cette page appartient à ce site, ce site a ce nom, cette URL est la référence.
L’organisation doit être la même partout
Pour une entreprise, l’entité centrale est souvent l’organisation. Il faut vérifier que le nom, le logo, l’URL, les profils sociaux, les coordonnées et les informations publiques sont cohérents avec ce que le site affiche réellement.
Si le site, la page contact, le footer, les mentions légales, LinkedIn, Facebook et Google Business Profile racontent des choses différentes, le Schema.org ne va pas corriger le problème. Il risque même de rendre l’incohérence plus visible.
Le fil d’Ariane est une carte miniature du silo
Le fil d’Ariane mérite une attention particulière. Pour l’utilisateur, il répond à une question simple : “où suis-je dans le site ?”
Pour les moteurs et les IA, il donne aussi une indication de structure : la page appartient à telle rubrique, dans tel silo, avec tel chemin logique.
Exemple : Accueil > Blog > Bâtiment > Plomberie
Ce chemin ne sert pas seulement à naviguer. Il confirme une organisation éditoriale. Il relie la page à une catégorie, la catégorie au blog, et le blog au site. Le balisage BreadcrumbList devient donc une priorité sur beaucoup de sites WordPress.
3. Les contenus éditoriaux doivent relier les articles, les auteurs et les listes
Un blog WordPress ne contient pas seulement des articles isolés. Il contient des auteurs, des catégories, des pages de liste, des archives, des taxonomies, des liens internes et parfois une vraie stratégie éditoriale.
Si les données structurées ne décrivent que l’article seul, elles passent à côté d’une partie du contexte.
Un article doit être relié à son auteur et à son éditeur
Pour un article, l’enjeu n’est pas seulement de déclarer un titre et une date. Il faut aussi clarifier qui écrit, qui publie, quelle image représente l’article, à quelle page l’article appartient, et comment ce contenu s’inscrit dans le site.
Un article anonyme ou signé par “admin” n’apporte presque aucun signal humain. Un article signé par une personne identifiable, avec une page auteur, une fonction, une expérience, des profils publics et des contenus cohérents, devient plus solide.
Les profils auteurs renforcent la logique E-E-A-T
E-E-A-T signifie Experience, Expertise, Authoritativeness, Trustworthiness : expérience, expertise, autorité et fiabilité.
Les données structurées ne créent pas cette crédibilité seules. Mais elles peuvent aider à relier les preuves : articles signés, page auteur, profil LinkedIn, interventions, citations, conférences, interviews ou publications externes.
Dans un web rempli de contenus générés, anonymes ou interchangeables, cette personnification devient importante. On ne demande plus seulement : “ce site est-il fiable ?” On demande aussi : “qui parle, et pourquoi peut-on lui faire confiance ?”
Les pages de liste ne doivent pas être traitées comme de simples archives
La page du blog, une catégorie, une archive auteur, une taxonomie personnalisée ou une page de sélection ne sont pas de simples pages qui empilent des liens. Elles organisent un ensemble.
Une page “Conseils plomberie” peut regrouper les contenus liés à l’entretien, aux fuites, aux installations sanitaires ou au chauffage. Une page “Guides rénovation” peut lister des ressources pratiques pour préparer des travaux. Une page “Réalisations salle de bain” peut regrouper des chantiers terminés, avec photos, contexte et zone d’intervention.
Dans ces cas, des types comme CollectionPage ou ItemList peuvent aider à déclarer qu’il s’agit d’un ensemble organisé, pas seulement d’une page HTML avec des cartes.
4. Les pages métier doivent décrire les services, les contacts et les preuves utiles
Un site vitrine ne vend pas toujours des produits. Il vend souvent une compétence, un service, une zone d’intervention, une méthode ou une expertise.
Ces éléments doivent rester visibles pour les humains, mais ils peuvent aussi être clarifiés dans les données structurées.
Les services doivent correspondre aux vraies pages du site
Si le site possède une page “Services” et une page dédiée par service, le balisage doit respecter cette architecture.
La page générale peut présenter l’ensemble des offres. Chaque page de service peut ensuite détailler une prestation précise : dépannage fuite d’eau, rénovation de salle de bain, installation de chauffe-eau, remplacement de robinetterie, entretien de chaudière ou recherche de fuite.
Il faut éviter de déclarer une liste de services trop large si les pages ne les expliquent pas réellement. Les données structurées doivent aider à comprendre l’offre, pas gonfler artificiellement le périmètre de l’entreprise.
Les événements et offres d’emploi ne sont utiles que s’ils existent vraiment
Un événement peut être pertinent si l’entreprise organise réellement une conférence, une formation, un webinaire ou une rencontre. Une offre d’emploi doit correspondre à une annonce réelle, à jour, avec les informations nécessaires.
À l’inverse, ajouter un événement fictif ou une annonce expirée crée de la confusion. Et cette confusion peut abîmer la confiance.
Les points de contact doivent être cohérents avec le parcours utilisateur
Les informations de contact peuvent aussi être structurées : téléphone, adresse, service client, support, contact commercial, établissement concerné. Mais elles doivent rester cohérentes avec le parcours réel.
Si la page contact permet de choisir une succursale, le balisage doit tenir compte de cette réalité. Il ne faut pas tout ramener à une adresse unique si l’entreprise possède plusieurs points de contact.
5. Les entreprises locales doivent aligner le site, les établissements et Google Business Profile
Le SEO local devient encore plus important avec les recherches conversationnelles et les moteurs de réponse.
Une IA peut aider à organiser un voyage, choisir un restaurant, trouver un hôtel, recommander un artisan, comparer des agences, ou sélectionner un prestataire proche. Ces usages se rapprochent du terrain historiquement dominé par Google Maps et Google Business Profile.
Une entreprise locale n’est pas toujours une seule adresse
Prenons une entreprise implantée depuis 20 ans. Elle possède un siège à Caen, dans le Calvados, puis deux succursales : Saint-Lô dans la Manche et Paris. Chaque succursale compte environ 15 personnes. L’entreprise a une clientèle fidèle, des réseaux sociaux, une page LinkedIn, une page Facebook, et des fiches Google Business Profile avec des avis pour chaque établissement.
Dans ce cas, il ne suffit pas de déclarer une organisation globale.
- l’organisation principale ;
- le siège ;
- les succursales ;
- les pages de contact ;
- les zones desservies ;
- les avis ;
- les profils publics ;
- les services réellement proposés dans chaque lieu.
Un balisage trop simple risque de tout écraser. Un balisage plus fin peut aider à montrer que Caen, Saint-Lô et Paris ne sont pas trois mentions décoratives, mais trois implantations réelles.
Google Business Profile doit raconter la même histoire que le site
Pour une entreprise locale, la cohérence avec Google Business Profile est centrale : nom, adresse, téléphone, horaires, catégories, services, zones desservies, avis, photos et liens vers le site doivent raconter la même histoire.
Si la fiche Google met en avant un service, mais que le site ne le présente pas clairement, le signal est faible. Si le site décrit trois succursales, mais qu’une seule fiche locale existe ou que les informations divergent, la compréhension devient fragile.
Les avis ne sont pas seulement des étoiles. Ils prouvent qu’il y a des personnes, des clients, des expériences réelles, des services rendus et une réputation qui se construit. La saison 3 reviendra plus précisément sur ce lien entre SEO local, Google Business Profile, avis et données structurées.
6. WooCommerce demande de baliser les produits, mais aussi les catégories et les relations
Sur un site WooCommerce, la fiche produit attire naturellement l’attention. Elle doit contenir les informations essentielles : nom, image, description, prix, devise, disponibilité, marque, avis, note, identifiants produit, attributs, variantes, livraison ou retours selon les cas.
Mais l’enjeu ne s’arrête pas à la fiche.
Une catégorie produit est une page de choix
Une page catégorie WooCommerce n’est pas seulement une grille. Pour l’utilisateur, c’est souvent une page de décision : il compare, filtre, regarde les prix, vérifie les avis, cherche une gamme, une marque, un usage ou une disponibilité.
Pour une IA, cette page peut aussi être une source de comparaison. Si la catégorie est structurée comme une simple archive, elle dit peu de choses. Si elle contient une introduction utile, des critères de choix, un fil d’Ariane clair, des produits bien renseignés et une logique de liste, elle devient plus exploitable.
Les produits doivent être reliés aux bonnes entités
Un produit peut être lié à une marque, un fabricant, un producteur, une gamme, une catégorie, une page conseil, un guide d’achat ou un cas d’usage.
- le produit à une page producteur ;
- le produit à une catégorie stratégique ;
- le produit à un comparatif interne ;
- le produit à une page conseil ;
- les variantes aux attributs utiles ;
- la marque aux profils publics ou au site officiel ;
- les produits d’une même gamme entre eux.
Pour les IA, un produit bien structuré est plus facile à comparer. Mais il faut que les données restent fidèles à la réalité commerciale.
Les comparatifs IA changent la valeur des données produit
Les usages changent : beaucoup d’utilisateurs demandent désormais à une IA de comparer les produits, plutôt que de parcourir manuellement plusieurs sites.
Pour répondre, une IA peut s’appuyer sur des fiches produits, Google Shopping, Bing, Amazon, comparateurs, marketplaces, articles spécialisés, avis ou bases marchandes.
Rien ne garantit qu’un produit balisé sera repris. Mais un produit mal renseigné, absent des écosystèmes produits, sans prix, sans disponibilité, sans attributs clairs et sans cohérence entre fiche, catégorie et avis part avec un handicap.
La saison 3 développera ce point avec un épisode dédié à WooCommerce, Product, Offer et les comparatifs IA.
7. La priorité est de baliser ce qui aide vraiment à comprendre
Une fois toutes ces possibilités posées, il faut revenir à une règle simple : tout baliser n’est pas une stratégie.
La bonne stratégie consiste à prioriser en deux niveaux.
Premier niveau : les données structurées utiles pour les Rich Results Google. C’est le socle le plus visible : fil d’Ariane, produits, avis, événements, offres d’emploi, ou vidéos selon les cas. Ce niveau aide à être éligible à certains affichages, sans garantie d’affichage.
Deuxième niveau : l’organisation globale du schéma. C’est là que l’on décrit ce que le site est réellement : qui publie, qui écrit, quels établissements existent, quels services sont proposés, quelles listes organisent les contenus, quels produits appartiennent à quelles catégories, quelles preuves externes renforcent la confiance.
Réponse courte : les entités à envisager dépendent du rôle réel des pages.
| Si le site contient | Entités Schema.org à envisager | Ce que cela clarifie |
|---|---|---|
| une base WordPress classique | WebSite, WebPage, Organization, BreadcrumbList | le site, l’éditeur, les pages et leur place dans l’arborescence |
| un blog ou des ressources | Article, BlogPosting, Person, ProfilePage, ImageObject | le contenu éditorial, l’auteur, l’image principale et la responsabilité de publication |
| des catégories, archives ou sélections | CollectionPage, ItemList, ListItem | les ensembles de contenus ou de produits, au lieu de simples listes HTML |
| une entreprise locale | Organization, LocalBusiness, PostalAddress, ContactPoint, sameAs | l’identité, les établissements, les contacts et les profils publics |
| des services | Service, Offer, ContactPoint, parfois AreaServed | les prestations, les zones couvertes et le parcours de contact |
| une boutique WooCommerce | Product, Offer, AggregateRating, Review, Brand, ItemList | les fiches produits, les prix, la disponibilité, les avis, les marques et les catégories |
| des contenus spécifiques | Event, JobPosting, VideoObject | les événements réels, offres d’emploi ou vidéos importantes |
Ce tableau n’est pas une checklist à appliquer partout. C’est une grille de décision. Si l’entité existe vraiment sur le site et aide à comprendre une page, elle peut être utile. Si elle n’existe pas, elle ne doit pas être inventée.
Le critère n’est pas la quantité de JSON-LD. Le critère est la clarté obtenue.
8. Avant de déployer, il faut vérifier la cohérence et les doublons
Un site WordPress peut produire du JSON-LD depuis plusieurs endroits : thème, plugin SEO, WooCommerce, extension événementielle, page builder, développement custom.
Avant d’ajouter une couche, il faut donc auditer l’existant.
- quelles données structurées sont déjà présentes ?
- quel plugin les génère ?
- y a-t-il plusieurs organisations déclarées ?
- les auteurs correspondent-ils aux auteurs visibles ?
- le fil d’Ariane correspond-il au silo réel ?
- les produits sont-ils balisés une ou plusieurs fois ?
- les prix et disponibilités sont-ils cohérents ?
- les succursales sont-elles distinguées ?
- Google Business Profile raconte-t-il la même chose que le site ?
Ensuite seulement, on peut décider ce qui doit rester géré par le plugin, ce qui doit être corrigé, ce qui doit être désactivé, et ce qui mérite un balisage custom.
Ce n’est pas au site de se tordre pour rentrer dans la logique d’un plugin SEO. C’est au balisage custom de suivre le site : ses champs, ses contenus, ses taxonomies, ses relations, ses succursales, ses auteurs, ses produits, ses producteurs, ses services et ses cas particuliers.
Un plugin généraliste donne une base. Un plugin custom doit traduire le site réel.
Ce qu’il faut retenir sur les entités à baliser
Choisir les entités à baliser ne consiste pas à empiler des types Schema.org.
Il faut partir du site réel : son organisation, ses pages, ses auteurs, ses services, ses établissements, ses produits, ses avis, ses listes et ses relations internes.
Les Rich Results Google donnent une première liste d’entités utiles, mais ils ne couvrent pas toute la logique d’un site. Le reste de Schema.org sert à organiser plus finement les informations disponibles, à condition de respecter l’architecture réelle.
Les données structurées servent à rendre cette réalité plus lisible pour les moteurs et les IA. Elles doivent rester cohérentes avec le contenu visible, les profils publics, les fiches Google Business Profile, les avis et les pages du site.
Un bon balisage n’oblige pas le site à s’adapter à un plugin. Il interprète les vraies données du site et les traduit dans le vocabulaire disponible.
Dans l’épisode suivant, on passera à une mise en place plus concrète : comment piloter des données structurées avancées dans WordPress avec une logique de plugin custom.
Besoin de clarifier les entités de votre site ?
Un audit permet d’identifier ce que WordPress, WooCommerce et les plugins SEO déclarent déjà, puis de décider ce qui mérite une correction, une suppression ou un balisage plus précis.
Cet article fait partie de la série Données structurées, Rich Results et IA.
La série est organisée en parties : comprendre, appliquer, puis développer les cas stratégiques.
Cette série est decoupée en 3 grandes parties. Le mot « saison » sert ici a organiser la progression editoriale, pas a annoncer une publication l’année prochaine 😉 .
L’idee :
- Saison 1 : comprendre les bases ;
- Saison 2 : appliquer dans WordPress ;
- Saison 3 : développer les cas stratégiques. SEO local, auteurs et WooCommerce.
- S3E1 – GEO local : Google Business Profile, avis et assistants de decision
- S3E2 – Auteurs, E-E-A-T et profils publics : rendre l’expertise identifiable
- S3E3 – WooCommerce, Product, Offer et comparatifs IA : rendre les produits vérifiables
- S3E4 – Réassurance distribuée : quand la confiance se construit sur tout le web
- Final : du SEO classique au GEO, comprendre la lecture en réseau
Les épisodes peuvent etre publiés progressivement, avec d’autres articles intercalés entre deux épisodes.
