Dans l’épisode précédent, on a vu que Schema.org est une norme large. Elle permet de décrire des pages, des contenus, des organisations, des personnes, des produits, des lieux, des événements et beaucoup d’autres éléments.
Mais Google ne transforme pas toute la norme Schema.org en affichages enrichis. C’est là que beaucoup de confusions commencent.
Une donnée structurée peut être correcte techniquement. Elle peut aider Google à comprendre une page. Elle peut même être utile pour une logique GEO ou pour des IA qui cherchent des sources claires. Et pourtant, elle peut ne jamais produire d’étoile, de FAQ, de fil d’Ariane visible, de fiche produit enrichie ou d’affichage particulier dans les résultats.
Cet épisode sert à poser une séparation nette : Schema.org n’est pas Google Rich Results.
À 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. Un Rich Result est un affichage enrichi dans Google, pas toute la donnée structurée
Google appelle Rich Results les résultats qui dépassent le simple lien bleu avec titre, URL et description.
Un résultat enrichi peut afficher un fil d’Ariane, une note, un prix, une disponibilité, une image plus visible, un événement, une offre d’emploi, une vidéo, une recette, une information d’organisation ou d’autres éléments selon les cas.
Les données structurées servent alors à fournir à Google des informations dans un format normalisé. Mais elles rendent surtout une page éligible à certains affichages. Elles ne commandent pas l’affichage.
Google peut lire un balisage, le juger techniquement valide, et décider malgré tout qu’un résultat texte classique est plus adapté.
2. Il faut séparer trois niveaux : la norme, la prise en charge Google et l’affichage réel
Pour éviter les malentendus, on peut raisonner en trois niveaux.
Premier niveau : Schema.org existe. La norme propose beaucoup de types et de propriétés. On peut décrire une organisation, une personne, un article, un produit, une vidéo, un événement, un lieu, une offre, une image, une liste, une relation entre contenus, et bien plus encore.
Deuxième niveau : Google prend en charge certaines fonctionnalités. Google maintient une galerie officielle des données structurées compatibles avec la recherche Google.
Troisième niveau : Google affiche ou non un Rich Result. Même si la page utilise un type reconnu, même si le test ne remonte pas d’erreur, Google peut ne pas afficher l’enrichissement.
3. La galerie officielle Google est la référence pour savoir ce qui est pris en charge
Pour Google, la source à consulter est la galerie officielle Google Search Central des données structurées compatibles.
Elle liste les fonctionnalités de recherche liées aux données structurées et donne, pour chacune, les consignes spécifiques à respecter.
On y trouve notamment des fonctionnalités liées aux contenus éditoriaux, à la navigation, aux produits, aux avis, aux entreprises locales, aux organisations, aux événements, aux emplois, aux vidéos, aux images, aux recettes, à l’éducation, aux locations de vacances ou aux contenus payants.
Cette liste évolue. C’est pour cela qu’il faut éviter de raisonner uniquement avec de vieux souvenirs SEO. Une fonctionnalité peut être ajoutée, modifiée, limitée, moins visible qu’avant ou conditionnée à des critères plus stricts.
4. Les types les plus utiles pour un site WordPress classique ne sont pas forcément les plus spectaculaires
Pour un site WordPress d’entreprise, tous les Rich Results Google ne sont pas pertinents. Un site vitrine n’a probablement pas besoin de baliser des recettes, des films ou des exercices scolaires.
En revanche, certains balisages reviennent souvent : fil d’Ariane, article, organisation, établissement local, produit, vidéo, événement, offre d’emploi ou page de profil selon les cas.
Le fil d’Ariane aide Google à comprendre la position d’une page dans la hiérarchie du site. Le balisage Article peut être pertinent pour les contenus éditoriaux. Organization aide à clarifier l’entité qui publie. LocalBusiness concerne les établissements locaux. Product devient important pour WooCommerce et les sites e-commerce.
L’idée n’est pas de cocher toutes les cases. L’idée est de choisir les fonctionnalités qui correspondent vraiment au site.
5. FAQ : un bon exemple de balisage utile, mais à ne pas surestimer
Le balisage FAQ est un bon exemple de confusion fréquente. Pendant un temps, beaucoup de sites ont ajouté du balisage FAQ partout, dans l’espoir d’occuper plus d’espace dans les résultats de recherche.
Mais une FAQ balisée n’est pas automatiquement affichée dans Google. Et surtout, elle doit correspondre à une vraie section visible et utile pour l’utilisateur.
La question importante n’est donc pas : “peut-on ajouter du JSON-LD FAQ ?” La vraie question est : “cette page contient-elle une FAQ utile, visible, cohérente avec le contenu principal, et pertinente pour l’utilisateur ?”
Si oui, le balisage peut avoir du sens. Si non, il devient décoratif, voire trompeur.
6. Le fil d’Ariane mérite une attention particulière
Le fil d’Ariane est parfois perçu comme un détail. Il ne l’est pas.
Il indique la position de la page dans l’architecture du site. Pour l’utilisateur, il facilite le retour vers une rubrique ou une catégorie. Pour Google, il clarifie la hiérarchie. Pour une IA qui analyse un site, il peut aussi aider à comprendre le contexte d’une page.
Exemple : Accueil > Blog > SEO & Performance > Données structurées.
Ce chemin montre que l’article appartient à un univers éditorial. Il confirme le silo. Il donne une relation entre la page, sa catégorie, le blog et le site. Dans une logique GEO, c’est aussi une façon de rendre le site moins ambigu.
7. Les produits sont un cas stratégique, surtout pour WooCommerce
Pour un site e-commerce, les données structurées produit ne sont pas seulement un sujet d’affichage.
Elles peuvent remonter dans Search Console, avec des erreurs ou des avertissements sur les champs manquants. Ces alertes indiquent souvent que Google n’a pas toutes les informations nécessaires pour exploiter correctement une fiche produit dans ses expériences enrichies ou marchandes.
Selon les cas, il faut surveiller le prix, la devise, la disponibilité, la marque, l’image, les avis, la note moyenne, les identifiants produit, la livraison, les retours et les variantes.
Une extension comme Yoast WooCommerce SEO peut corriger une partie de ces manques si les données existent déjà dans WooCommerce. Un développement custom peut aussi le faire, parfois avec plus de précision, en allant chercher les vrais champs du site.
Si des IA construisent des comparatifs à partir de sources marchandes, d’index produits, de Google Shopping, de marketplaces ou de comparateurs, une fiche mal structurée part avec un handicap. Rien ne garantit qu’une IA utilisera ces données, mais un produit absent des écosystèmes exploitables a moins de chances d’être compris, comparé ou recommandé.
8. Google Shopping ne doit pas être ignoré sous prétexte qu’il sert aussi la publicité
Beaucoup de marchands se méfient de Google Shopping. Ils se disent parfois : “je vais être perdu dans des millions de produits”, “Google va surtout me pousser vers les Ads”, ou “mes produits ne remonteront jamais face aux gros acteurs”.
Ces réserves peuvent s’entendre. Mais dans une logique de visibilité produit, ne pas structurer ses données et ne pas rendre son catalogue exploitable peut fermer une porte.
Les utilisateurs ne comparent plus dix sites un par un, avec dix onglets ouverts et une heure de recherche devant eux. Logiquement, l’une des utilisations les plus appréciées des IA est justement la recherche et la comparaison de produits.
Ils demandent de plus en plus à une IA : quel produit choisir, quelles différences entre ces modèles, quelle option est la plus adaptée à mon budget, quelles sont les limites de ce produit.
Le sujet n’est donc pas seulement “être dans Google Shopping”. Le sujet est : rendre les produits lisibles dans les environnements où les comparaisons peuvent se construire.
9. Le test des résultats enrichis ne dit pas tout
Le test des résultats enrichis de Google est indispensable. Il permet de vérifier si une page peut générer certains Rich Results Google à partir des données structurées présentes.
Mais il ne faut pas lui demander ce qu’il ne promet pas. Un test valide ne garantit pas l’affichage dans Google. Un test sans erreur ne veut pas dire que le balisage est stratégiquement bon.
Un test Google ne valide pas toute la richesse possible de Schema.org. Il se concentre sur les fonctionnalités prises en charge par Google. Pour vérifier un balisage Schema.org plus large, il faut utiliser un validateur Schema.org, comme Schema Markup Validator.
- Rich Results Test : vérifier l’éligibilité aux résultats enrichis Google.
- Schema Markup Validator : vérifier un balisage Schema.org plus général.
- Search Console : surveiller après indexation les erreurs, avertissements, pages valides et performances.
10. Search Console sert à surveiller le réel après déploiement
Un balisage peut être correct au moment du développement et se casser plus tard. Un thème change. Un plugin est mis à jour. Un champ WooCommerce disparaît. Une page modèle est modifiée. Une condition d’affichage masque une donnée.
C’est pour cela que Search Console est importante. Après déploiement, elle permet de surveiller les rapports liés aux données structurées disponibles pour le site.
Pour les sites e-commerce, c’est particulièrement utile. Les rapports produit peuvent révéler des champs manquants, des incohérences ou des données insuffisantes. Ce n’est pas glamour, mais c’est souvent très concret : un champ absent peut empêcher une exploitation correcte du produit.
11. Les données structurées doivent rester visibles, vraies et cohérentes
Google insiste sur un point essentiel : les données structurées doivent correspondre au contenu visible par l’utilisateur.
Il ne faut pas baliser une information qui n’est pas réellement présente sur la page, inventer des avis, marquer une note qui n’existe pas, déclarer un produit disponible si la page ne le montre pas, ajouter une FAQ invisible ou utiliser les données structurées pour tromper l’utilisateur ou le moteur.
Cette règle est aussi saine pour le GEO. Une IA qui recoupe les sources a besoin de cohérence. Si le site, les données structurées, les avis, les profils publics, les pages produits et les fiches locales racontent des choses différentes, l’entité devient plus difficile à interpréter.
12. Une donnée structurée peut être utile même sans Rich Result
C’est le point le plus important de cet épisode. Il ne faut pas réduire les données structurées à la question : “est-ce que Google affiche quelque chose ?”
Un balisage peut ne pas produire de Rich Result visible et rester utile. Il peut clarifier l’auteur d’un article, relier une page à une organisation, confirmer l’architecture du site, décrire une page de profil, rendre un produit plus lisible ou aider à distinguer une succursale d’un siège social.
Dans une logique SEO, cela aide à comprendre le site. Dans une logique GEO, cela aide à rendre les sources plus exploitables. Dans une logique IA, cela réduit l’ambiguïté.
13. Comment prioriser sur un site WordPress
Pour un site WordPress classique, on peut prioriser simplement. D’abord, vérifier la base : site, organisation, pages, articles, auteurs et fil d’Ariane.
Ensuite, vérifier les cas métier : produits pour WooCommerce, établissements pour une entreprise locale, événements si le site en publie, offres d’emploi si le site recrute, vidéos si elles sont importantes, FAQ si elles sont utiles et visibles, pages de profil si les auteurs ou experts comptent vraiment.
Enfin, contrôler la cohérence : les données existent-elles vraiment, sont-elles visibles, les pages importantes sont-elles indexables, les prix sont-ils à jour, le fil d’Ariane reflète-t-il vraiment le silo, les auteurs ont-ils un profil crédible, et les informations locales concordent-elles avec les fiches Google Business Profile ?
La bonne stratégie n’est pas “tout baliser”. La bonne stratégie est “baliser ce qui aide vraiment à comprendre”.
Ce qu’il faut retenir sur les Google Rich Results
Google Rich Results n’est pas un synonyme de Schema.org. Schema.org est une norme large. Google ne prend en charge qu’une partie des possibilités pour ses affichages enrichis. Et même quand un balisage est reconnu, valide et testé, l’affichage dans les résultats n’est jamais garanti.
Cela ne rend pas les données structurées secondaires. Au contraire : elles restent utiles pour rendre un site plus clair, plus cohérent et plus exploitable. Simplement, il faut les traiter comme un outil de compréhension, pas comme une promesse d’affichage.
La saison 1 se termine ici : on a posé le pourquoi, le fonctionnement des sources IA, la logique Schema.org et la différence avec les Rich Results Google.
La saison 2 pourra passer à la mise en place : WordPress, plugins SEO, balisage custom, fil d’Ariane, auteurs, produits, services et cohérence réelle du site.
Besoin d’un site mieux structuré pour Google et les IA ?
Un audit SEO permet de vérifier la structure, les données visibles, les données structurées, les erreurs Search Console et les priorités d’amélioration.
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.
Sources
- Google Search Central : balisage de données structurées compatible avec la recherche Google
- Google Search Central : présentation du fonctionnement du balisage de données structurées
- Google Search Central : consignes générales relatives aux données structurées
- Google : test des résultats enrichis
- Schema.org : Schema Markup Validator
