Après la saison 1, on sait pourquoi les données structurées comptent, ce qu’est Schema.org, et pourquoi il faut distinguer la norme des Rich Results Google.
On peut maintenant passer à WordPress.
La bonne nouvelle, c’est que beaucoup de sites WordPress ont déjà des données structurées sans le savoir. Yoast SEO, Rank Math, SEOPress, WooCommerce ou certaines extensions spécialisées génèrent déjà du JSON-LD.
La mauvaise nouvelle, c’est que cette base peut être valide sans être suffisante.
Un plugin standard peut déclarer un site, une page, un article, un fil d’Ariane, un produit ou une FAQ. Mais il ne connaît pas toujours les relations métier, les vrais producteurs, les succursales, les services locaux, les pages de collection, les auteurs crédibles, les cas d’usage produit ou les champs spécifiques du site.
Avant d’ajouter plus de Schema.org, il faut donc comprendre ce qui existe déjà.
À 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. WordPress peut déjà produire des données structurées sans développement custom
Sur WordPress, les données structurées viennent souvent de plusieurs endroits.
Le thème peut parfois générer des microdonnées ou des balises liées au fil d’Ariane. Un plugin SEO peut ajouter un graphe JSON-LD pour le site, l’organisation, les articles, les pages, les auteurs et la navigation.
WooCommerce peut ajouter des informations produit de base. Un plugin de FAQ, d’événement, de recette, d’offre d’emploi, de vidéo ou de local SEO peut aussi ajouter sa propre couche.
Le problème n’est donc pas seulement : “faut-il ajouter des données structurées ?” La première question est : “qu’est-ce qui est déjà présent, et qui le génère ?”
2. Les plugins SEO construisent une base utile, mais souvent standardisée
Les plugins SEO modernes ne se contentent plus toujours d’ajouter un petit bloc isolé.
Yoast, Rank Math ou SEOPress peuvent construire un ensemble d’entités séparées : le site, la page, l’article, l’auteur, l’organisation, le fil d’Ariane, parfois l’image principale ou la page de profil.
Cette logique se rapproche de ce que l’on a vu avec @graph : plusieurs objets sont déclarés séparément, puis reliés entre eux. C’est une bonne base. Mais cette construction reste standardisée.
Les entités déclarées viennent de ce que le plugin peut déduire
Le plugin déduit les entités à partir de ce qu’il connaît : les réglages du site, le titre de la page, le type de contenu WordPress, l’auteur WordPress, l’image mise en avant, les taxonomies, le fil d’Ariane ou certains champs WooCommerce.
Il ne peut pas deviner toute la logique métier.
Plusieurs blocs JSON-LD peuvent cohabiter sur une même page
Un point important : sur un site WordPress, toutes les données structurées ne viennent pas forcément du même endroit.
La FAQ peut être générée par un bloc ou un module séparé. WooCommerce peut générer des données produit. Yoast ou Rank Math peuvent ajouter leur propre graphe principal. Un plugin de cache, un thème ou une extension de page builder peut aussi modifier la sortie HTML.
Ce n’est pas forcément mauvais. Mais il faut vérifier la cohérence de l’ensemble.
- Les entités sont-elles cohérentes entre elles ?
- La même organisation est-elle déclarée plusieurs fois ?
- L’auteur est-il le même dans le contenu visible et le JSON-LD ?
- La FAQ balisée est-elle bien visible sur la page ?
- Le produit WooCommerce est-il balisé une seule fois ou plusieurs fois ?
- Le fil d’Ariane du plugin correspond-il vraiment au silo du site ?
Une base automatique peut être propre. Une accumulation automatique peut devenir confuse.
3. WooCommerce et Yoast WooCommerce SEO améliorent les produits, mais ne décrivent pas tout le catalogue
WooCommerce peut produire des données structurées produit de base.
Sur une fiche produit simple, cela peut déjà donner des informations utiles : nom du produit, image, description, prix, disponibilité, avis ou note selon les données disponibles.
Mais cette base dépend fortement de ce qui est renseigné dans WooCommerce. Si le prix, la devise, le stock, les avis, la marque, les identifiants produit, les variantes, les attributs ou la livraison sont absents ou mal renseignés, le balisage restera limité.
WooCommerce ne peut pas inventer les données manquantes.
Yoast WooCommerce SEO corrige des champs, mais ne modélise pas tout
Une extension comme Yoast WooCommerce SEO peut améliorer cette couche produit. Elle peut corriger ou compléter certains champs attendus par Google, notamment autour du prix, de la disponibilité, de la devise, des informations marchandes, des identifiants ou des données nécessaires aux rapports produit.
Dans certains cas, cela suffit à supprimer des avertissements dans Search Console. C’est utile. Mais cela ne veut pas dire que tout est réglé.
Le plugin corrige souvent les bases attendues par Google. Il ne crée pas forcément une modélisation avancée du catalogue.
- Baliser les listes de produits.
- Relier une page de catégorie à ses produits.
- Mettre en valeur un producteur avec une page liée au produit.
- Relier un produit à des guides d’achat internes.
- Déclarer des cas d’usage métier.
- Distinguer finement les gammes, collections ou familles.
- Exploiter des champs personnalisés propres au site.
- Construire un graphe cohérent entre marque, producteur, produit, catégorie et contenu éditorial.
Les listes de produits sont souvent le grand angle mort
Dans beaucoup de sites e-commerce, l’utilisateur ne commence pas par une fiche produit isolée. Il arrive sur une catégorie, une sous-catégorie, une page de collection, une page de sélection, un guide d’achat, une liste de produits recommandés ou un comparatif.
Ces pages structurent le catalogue. Elles expliquent les gammes. Elles relient les produits à des usages. Elles aident l’utilisateur à choisir. Et elles peuvent être très utiles aux moteurs ou aux IA qui cherchent à comparer plusieurs options.
La page catégorie peut pourtant rester balisée comme une simple page web, sans décrire clairement la liste de produits qu’elle contient, la logique de collection, le public visé ou les relations entre les produits.
Les producteurs, fabricants ou partenaires ne sont pas toujours reliés aux produits
Même problème avec les producteurs, fabricants ou partenaires.
Une boutique peut vendre des produits fabriqués par un producteur identifié. Le site peut avoir une page producteur avec son histoire, son lieu, son savoir-faire, ses engagements, ses photos, ses produits et peut-être des liens vers ses profils publics.
Pour un humain, cette page apporte de la confiance. Pour une IA ou un moteur, elle peut aussi aider à comprendre qui fabrique, qui vend, quelle marque est associée, quels produits sont concernés, et pourquoi ces produits sont crédibles.
Mais un plugin standard ne va pas forcément relier proprement la fiche produit, le producteur, la marque, la page producteur, les produits du même producteur, les articles qui parlent de ce producteur et les avis ou preuves associées.
On peut donc avoir un balisage produit valide, sans avoir un catalogue vraiment explicite.
4. Les plugins premium restent généralistes, même quand ils coûtent cher
Il ne faut pas caricaturer les plugins SEO. Yoast, Rank Math, SEOPress et d’autres extensions rendent service.
Ils apportent une base maintenue, pratique, compatible avec beaucoup de sites, et suffisante pour de nombreux cas. Le problème n’est pas qu’ils seraient “mauvais”. Le problème est qu’ils doivent fonctionner pour des milliers de configurations différentes.
Ils ne peuvent pas connaître en détail le modèle économique de chaque site, les champs personnalisés, les vraies relations entre contenus, les subtilités d’un catalogue, les établissements locaux, les producteurs, les auteurs experts, les cas d’usage, les pages stratégiques, les preuves externes ou les choix éditoriaux.
Un plugin généraliste doit rester généraliste. C’est sa force. Et c’est aussi sa limite.
Les prix Yoast donnent un ordre d’idée
Les prix donnent aussi une idée de cette logique par niveau.
Au moment de la rédaction, la boutique officielle Yoast affiche des prix en dollars. Voici une conversion approximative en euros HT, arrondie, à la date du 11 mai 2026.
Ces prix donnent seulement un ordre d’idée. Ils peuvent changer selon la devise, le taux de change, les promotions, la TVA ou les offres groupées.
- Yoast SEO : gratuit.
- Yoast SEO Premium : environ 110 € HT / an.
- Yoast WooCommerce SEO : environ 165 € HT / an.
- Yoast SEO AI+ : environ 330 € HT / an.
- Yoast SEO Google Docs Add-on : environ 55 € HT / an.
- Yoast SEO for Shopify : environ 215 € HT / an.
- Yoast Duplicate Post : gratuit.
Yoast Local SEO, Yoast News SEO et Yoast Video SEO apparaissent désormais comme inclus dans certaines offres Yoast, notamment Premium, WooCommerce SEO et AI+. Ils ne sont donc pas à traiter uniquement comme de petits plugins séparés ajoutés un par un.
À partir d’un certain niveau, le custom peut devenir plus rentable
Cette logique de pack confirme l’idée de fond : Yoast ajoute des couches spécialisées utiles, mais dans un cadre standardisé.
Ces plugins se situent aussi dans la fourchette haute des prix habituels de plugins WordPress. Pour un site simple, cela peut rester très pertinent : on paie une solution maintenue, documentée, compatible avec beaucoup de cas, et rapide à mettre en place.
Mais dès que l’on additionne plusieurs licences, ou que le site demande une modélisation plus fine, un développement custom peut devenir beaucoup plus rentable. Surtout, il peut être plus utile : au lieu d’ajouter une couche générique, il peut exploiter directement les champs, les contenus, les relations et les entités réelles du site.
5. Le custom devient utile quand le site possède des données métier exploitables
Un plugin custom n’est pas utile parce qu’il est “custom”. Il devient utile quand le site possède des données que les plugins standards ne savent pas exploiter correctement.
La question à poser n’est donc pas : “peut-on générer du JSON-LD ?” La vraie question est : “quelles informations importantes existent déjà dans le site, mais ne sont pas déclarées clairement aux machines ?”
Les sites WordPress contiennent souvent déjà la matière nécessaire
Un site WordPress contient souvent plus de données qu’on ne l’imagine.
Il peut avoir des champs ACF, des taxonomies personnalisées, des types de contenus spécifiques, des relations entre contenus, des auteurs identifiés, des produits reliés à des marques, des agences, des zones d’intervention, des FAQ visibles, des pages de services, des pages de contact par établissement ou des pages de catégories très travaillées.
Ces données sont parfois visibles pour l’utilisateur. Mais elles ne sont pas forcément structurées pour les moteurs. Un développement custom peut alors servir à transformer cette matière en graphe cohérent.
Exemple : relier une entreprise, ses succursales et ses services
Une entreprise de services possède trois succursales, chacune avec sa page, son adresse, son téléphone, sa fiche Google Business Profile, ses avis, ses services et ses zones desservies.
Un plugin SEO peut déclarer l’organisation générale. Un balisage custom peut relier plus précisément l’organisation principale, les établissements, les pages locales, les services concernés, les profils publics et les informations de contact.
Exemple : relier une boutique, ses produits et ses producteurs
Une boutique WooCommerce vend des produits fabriqués par plusieurs producteurs. WooCommerce peut déclarer la fiche produit. Yoast WooCommerce SEO peut améliorer certains champs attendus par Google.
Un balisage custom peut relier le produit à sa marque, à son producteur, à la page du producteur, à une collection, à une page catégorie, à un guide d’achat ou à un comparatif interne.
Exemple : relier les auteurs à leur expertise
Un blog d’expertise publie des articles signés par plusieurs auteurs. Un plugin SEO peut déclarer l’auteur WordPress.
Un balisage custom peut relier l’auteur à une page profil, à son rôle, à son organisation, à ses profils publics, à ses interventions, à ses articles et aux sujets sur lesquels il est légitime.
Dans ces cas, le développement ne consiste pas à “ajouter du schema pour ajouter du schema”. Il consiste à exposer proprement ce que le site sait déjà.
Le custom n’est utile que si la donnée existe vraiment
Le custom devient particulièrement intéressant quand les champs importants existent déjà dans WordPress, que les contenus sont réellement visibles pour l’utilisateur, que les entités ont une valeur SEO, GEO ou métier, et que les relations entre contenus ne sont pas triviales.
À l’inverse, si le site ne possède pas de données propres, pas de structure claire, pas de contenus fiables ou pas d’informations métier réelles, un plugin custom ne fera pas de miracle.
Il ne sert pas à inventer une réalité. Il sert à clarifier une réalité déjà présente.
6. Avant d’ajouter, il faut auditer l’existant
La mauvaise approche serait d’installer encore un plugin ou d’ajouter un bloc JSON-LD custom sans regarder ce qui existe déjà.
Avant toute intervention, il faut auditer les scripts JSON-LD présents sur les pages, les entités déjà déclarées, les doublons, les erreurs dans le Rich Results Test, les alertes Search Console, les sorties WooCommerce, les sorties Yoast, Rank Math ou SEOPress, les FAQ visibles et balisées, les pages catégories, les pages auteurs, les pages de services, les pages locales et les fiches produits stratégiques.
L’objectif n’est pas de produire plus de données. L’objectif est de produire de meilleures données.
7. La priorité reste la cohérence avec le contenu visible
Même avec un plugin custom, les données structurées ne doivent pas raconter une réalité parallèle.
Si une page déclare un producteur, il faut que ce producteur soit visible ou compréhensible sur la page. Si une FAQ est balisée, elle doit être affichée. Si une fiche produit déclare un prix ou une disponibilité, ces informations doivent être cohérentes avec ce que voit l’utilisateur.
Si une page de service déclare une zone d’intervention, le contenu doit le confirmer. Si un auteur est mis en avant, il doit exister comme personne identifiable.
Les données structurées ne servent pas à maquiller un site. Elles servent à clarifier ce que le site montre déjà.
8. Le bon objectif : passer d’un balisage valide à un balisage pertinent
La différence est importante. Un balisage valide respecte le format. Un balisage pertinent décrit réellement les entités importantes du site et leurs relations.
Un plugin SEO peut suffire pour avoir une base valide. Mais si l’objectif est de rendre un site plus clair pour Google, les moteurs de réponse et les IA, il faut parfois aller plus loin.
Un plugin SEO généraliste déclare ce qu’il peut déduire. Un plugin custom déclare ce que le site sait vraiment.
La saison 2 va justement servir à passer de cette base WordPress aux choix concrets : quelles entités baliser, dans quel ordre, avec quelles priorités, et comment éviter de tout baliser n’importe comment.
Ce qu’il faut retenir sur les plugins SEO pour les données structurées
Les plugins SEO WordPress posent une base utile.
Yoast, Rank Math, SEOPress ou WooCommerce peuvent déclarer des entités importantes, corriger certains champs, améliorer l’éligibilité aux Rich Results et supprimer des alertes Google quand les données existent déjà.
Mais ils restent dans une logique standardisée. Ils ne savent pas toujours modéliser les vraies relations métier : producteurs, listes de produits, pages de catégories, succursales, services, auteurs, profils publics ou cas d’usage.
La question n’est donc pas “plugin ou custom ?” La vraie question est : “quelles données le site possède-t-il, et lesquelles méritent d’être déclarées plus clairement ?”
Besoin d’un balisage WordPress plus précis ?
Un audit permet d’identifier ce que les plugins déclarent déjà, ce qui manque, ce qui se répète, et ce qui mérite une couche custom vraiment utile.
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 ;
- S2E1 – Ce que les plugins SEO font déjà, et ce qu’il faut vérifier
- S2E2 – Quelles entités baliser sur un site WordPress
- S2E3 – Piloter des données structurées avancées avec un plugin custom
- Saison 3 : développer les cas stratégiques. SEO local, auteurs et WooCommerce.
Les épisodes peuvent etre publiés progressivement, avec d’autres articles intercalés entre deux épisodes.
