SEO & Discoverability

Quels types schema.org influencent réellement les résultats de recherche

Un guide pratique des données structurées qui peuvent changer l’apparence de vos pages dans la recherche — et du balisage qui aide surtout les machines à vous comprendre.

The Wux Webtools Team The Wux Webtools Team 16 min de lecture Assisté par l'IA, revu par des humains
Structured data blocks connected to enhanced search result cards.
Table des matières
  1. La réponse courte
  2. D’abord : les données structurées donnent une admissibilité, pas un droit acquis
  3. Les types ayant l’impact le plus clair
  4. Product, Offer, AggregateRating et Review
  5. BreadcrumbList
  6. Article, NewsArticle et BlogPosting
  7. LocalBusiness et ses sous-types
  8. Event
  9. JobPosting
  10. Recipe
  11. VideoObject
  12. Organization, Logo et WebSite
  13. FAQPage : techniquement pris en charge, rarement visible pour la plupart des sites
  14. DiscussionForumPosting et ProfilePage
  15. Types utiles mais souvent surestimés
  16. JSON-LD est généralement le meilleur format d’implémentation
  17. Un modèle de priorisation pratique
  18. Erreurs courantes qui réduisent l’impact
  19. Baliser le mauvais type de page
  20. Ajouter des propriétés qui ne sont pas visibles
  21. Considérer la validation comme une réussite
  22. Implémenter le schéma une fois et l’oublier
  23. La recommandation sereine

La réponse courte

Le balisage Schema.org n’améliore pas automatiquement le classement. Il peut toutefois rendre une page admissible à des apparences de recherche enrichies : rich results, panneaux de produits, fils d’Ariane, listes d’événements, modules d’emploi, aperçus vidéo et fonctionnalités similaires.

Cette distinction est importante. Schema.org est un vaste vocabulaire pour décrire des choses sur le web. Les moteurs de recherche n’en prennent en charge qu’un sous-ensemble, et chaque fonctionnalité de recherche a ses propres règles. Vous pouvez baliser parfaitement une page avec Thing, CreativeWork ou Service sans voir de changement visible dans les résultats de recherche, parce qu’aucune fonctionnalité de recherche n’est nécessairement liée à ce type.

La bonne question n’est donc pas « Quels types de schémas existent ? » mais « Quels types de schémas les moteurs de recherche utilisent-ils pour produire des fonctionnalités visibles ou opérationnelles ? »

Voici la réponse pratique.

D’abord : les données structurées donnent une admissibilité, pas un droit acquis

Les données structurées donnent aux moteurs de recherche des indices explicites. Elles ne les forcent pas à afficher quoi que ce soit.

Une page doit généralement remplir toutes les conditions suivantes avant que les données structurées aient un effet visible :

  • Le balisage doit correspondre au contenu visible de la page.
  • Les propriétés requises et recommandées doivent être présentes.
  • La page doit être indexable et ne pas être bloquée par des règles robots.
  • Le contenu doit respecter les politiques de qualité et de lutte contre le spam.
  • Le moteur de recherche doit décider que le résultat enrichi aide l’utilisateur.

C’est pourquoi deux pages techniquement valides peuvent se comporter différemment dans la recherche. L’une peut obtenir un rich result de produit ; l’autre peut s’afficher comme un simple lien bleu. Le balisage n’est qu’un signal parmi d’autres.

C’est aussi pourquoi chercher à utiliser des types de schémas obscurs est généralement une mauvaise utilisation du temps. S’il n’existe aucune fonctionnalité de recherche prise en charge associée au type, le bénéfice est surtout sémantique plutôt que visuel.

Les types ayant l’impact le plus clair

Product, Offer, AggregateRating et Review

Pour les pages ecommerce et logiciels, le balisage produit fait partie des familles de données structurées les plus visiblement utiles.

Une page Product peut devenir admissible à des fonctionnalités de prix, disponibilité, note, livraison, retours et listes marchandes. Les types de soutien les plus importants sont généralement :

  • Offer pour le prix, la devise, la disponibilité et les informations sur le vendeur
  • AggregateRating pour les notes agrégées
  • Review pour les avis individuels, lorsque c’est pertinent
  • Brand ou Organization pour le contexte du fabricant ou du vendeur

Ce balisage est particulièrement utile lorsque la page porte réellement sur un produit précis, et non sur une catégorie ou une page de service vague. Les moteurs de recherche sont de plus en plus stricts au sujet des abus liés aux avis et aux notes, surtout les avis intéressés. Si la note n’est pas visible pour les utilisateurs sur la page, ne la balisez pas.

Le schéma Product peut influencer à la fois les extraits organiques classiques et les surfaces de type marchand. Pour les détaillants, c’est souvent l’une des implémentations de données structurées les plus rentables.

BreadcrumbList n’a rien de spectaculaire, mais il est pratique. Il peut influencer l’affichage de l’URL ou du chemin dans les résultats de recherche, en remplaçant une URL confuse par une hiérarchie plus claire.

Le balisage de fil d’Ariane est utile pour :

  • Les pages de catégories et de produits ecommerce
  • Les sites de documentation
  • Les grands blogs et publications
  • Les centres d’aide SaaS

Il crée rarement un rich result spectaculaire, mais il peut améliorer la compréhension. Les utilisateurs peuvent voir où se situe une page avant de cliquer. Les moteurs de recherche obtiennent aussi une vision plus claire de la structure du site.

Si votre site a une navigation profonde, le balisage de fil d’Ariane vaut la peine d’être fait tôt.

Article, NewsArticle et BlogPosting

Article, NewsArticle et BlogPosting peuvent aider les moteurs de recherche à comprendre le titre, l’auteur, la date, l’image et les informations sur l’éditeur. Pour les éditeurs, cela peut influencer l’admissibilité à des fonctionnalités orientées articles, surtout en combinaison avec une bonne explorabilité, de la fraîcheur et une qualité de contenu solide.

Ne vous attendez pas à ce que le schéma article transforme un billet de blog ordinaire en résultat d’actualité. Il ne compensera pas un reportage faible, des informations d’auteur manquantes ou un contenu mince.

Cela dit, le balisage article reste pertinent pour les sites éditoriaux. Utilisez-le pour rendre les faits de base sans ambiguïté :

  • Titre
  • Auteur ou organisation
  • Date de publication et date de modification
  • Image principale
  • Éditeur
  • URL canonique

Si votre équipe utilise la publication assistée par IA, les données structurées ne remplacent ni la divulgation ni la responsabilité éditoriale. Nous avons abordé le côté humain de la question dans à quoi ressemble une divulgation honnête de l’IA sur un petit site web. Les systèmes de recherche peuvent analyser votre balisage, mais les lecteurs jugent la page elle-même.

LocalBusiness et ses sous-types

Pour les organisations locales, LocalBusiness et ses sous-types — comme Restaurant, Dentist, Store ou ProfessionalService — peuvent aider à relier un site web à des faits d’entreprise : nom, adresse, numéro de téléphone, heures d’ouverture, coordonnées géographiques et profils same-as.

L’impact visible est moins prévisible que celui du balisage produit ou recette, car la recherche locale dépend fortement des fiches d’entreprise, de la proximité, de la notoriété, des avis et de l’intention utilisateur. Un balisage local cohérent reste toutefois une bonne pratique d’hygiène.

Utilisez-le sur la page qui représente l’établissement, et non au hasard sur chaque billet de blog. Si vous avez plusieurs emplacements, balisez chaque page d’emplacement avec sa propre adresse et ses propres heures d’ouverture.

Event

Le balisage Event peut rendre des pages admissibles à un affichage avec dates, lieux et informations de billetterie dans des fonctionnalités de recherche liées aux événements.

Il convient bien à :

  • Concerts
  • Conférences
  • Webinaires
  • Cours
  • Festivals
  • Événements communautaires

La clé est la précision. Une page sur « notre programme annuel de formation » n’est pas la même chose qu’une page pour un événement daté avec une heure de début, un lieu, un organisateur et un mode de participation.

Pour les événements en ligne, incluez les détails de participation virtuelle. Pour les événements physiques, incluez les informations sur le lieu. Gardez à jour les événements annulés, reportés et reprogrammés ; un balisage d’événement périmé est pire qu’une absence de balisage.

JobPosting

JobPosting est l’un des exemples les plus clairs de données structurées alimentant une expérience de recherche spécifique. Des pages d’emploi correctement balisées peuvent être admissibles à des fonctionnalités de recherche d’emploi, incluant le rôle, le lieu, le salaire, le type d’emploi et la date de publication.

Ce balisage n’est utile que sur de véritables pages d’offres d’emploi. Ne l’appliquez pas à des pages carrières génériques qui listent plusieurs rôles sans pages de détail distinctes.

Les champs importants comprennent :

  • Intitulé du poste
  • Organisation qui recrute
  • Lieu ou statut à distance
  • Date de publication
  • Date de validité
  • Type d’emploi
  • Rémunération, lorsqu’elle est disponible

Les offres expirées doivent être supprimées, redirigées de manière appropriée ou marquées comme n’étant plus valides. Les moteurs de recherche n’aiment pas envoyer les utilisateurs vers des postes fermés.

Recipe

Le balisage Recipe reste l’un des cas classiques de rich results. Il peut influencer les vignettes d’image, les notes, le temps de cuisson, les ingrédients, les informations nutritionnelles et les expériences guidées de recette.

C’est aussi l’un des domaines les plus abusés des données structurées. Si la page est surtout un essai personnel avec une recette enfouie en bas, le balisage doit tout de même décrire avec exactitude la recette visible. Les données structurées ne doivent pas prétendre à un temps de préparation de cinq minutes si les instructions disent le contraire.

Les pages de recettes sont riches en images, donc les données structurées ne sont qu’une partie du travail. De bonnes images, une compression raisonnable et un texte alt utile comptent aussi. Si vous nettoyez des images de nourriture, de produits ou éditoriales, un guide pragmatique du texte alt des images en 2026 est un complément utile au travail sur les schémas.

VideoObject

Le balisage VideoObject peut avoir un effet sur les aperçus vidéo, les moments clés, les vignettes, la durée, la date de téléversement et l’indexation vidéo. Il est utile lorsque la vidéo est une partie significative de la page, et non une intégration accessoire en bas de page.

Au minimum, fournissez :

  • Nom
  • Description
  • URL de vignette
  • Date de téléversement
  • Durée
  • URL d’intégration ou de contenu

Pour les vidéos pédagogiques ou longues, les moments clés peuvent aider les moteurs de recherche à comprendre les sections de la vidéo. Cela peut améliorer l’apparence de la vidéo dans la recherche, même si, encore une fois, cela ne garantit pas son positionnement.

Organization, Logo et WebSite

Le balisage Organization aide à définir l’entité derrière un site. WebSite peut soutenir la compréhension au niveau du site et, dans certains cas, des fonctionnalités comme la zone de recherche des sitelinks lorsque le moteur de recherche choisit de l’afficher.

Ce balisage est fondamental plutôt que spectaculaire. Il peut aider à clarifier :

  • Identité officielle du site
  • Logo
  • Profils sociaux
  • Coordonnées
  • Relations avec une société mère ou des filiales

Toute entreprise sérieuse, publication, organisation sans but lucratif et société de produit devrait disposer d’un balisage d’organisation propre quelque part de stable, généralement la page d’accueil ou une page à propos.

N’y ajoutez pas toutes les propriétés possibles. L’objectif est la clarté de l’entité, pas un déversement de base de données.

FAQPage : techniquement pris en charge, rarement visible pour la plupart des sites

FAQPage mérite une note particulière, car c’était autrefois un gain facile. Pendant des années, le balisage FAQ pouvait étendre les extraits avec des accordéons de questions-réponses. Cela le rendait attrayant et, sans surprise, surutilisé.

Google a ensuite fortement restreint les rich results FAQ, en les affichant généralement seulement pour des sites gouvernementaux et de santé reconnus et faisant autorité. D’autres moteurs de recherche peuvent encore utiliser le balisage FAQ différemment, et le balisage peut toujours aider les machines à comprendre la structure du contenu, mais la plupart des sites commerciaux et éditoriaux ne devraient pas s’attendre à des rich results FAQ visibles.

Utilisez le balisage FAQ uniquement lorsque la page contient réellement une FAQ. N’ajoutez pas de faux blocs de questions-réponses uniquement pour gagner de l’espace dans les résultats de recherche.

DiscussionForumPosting et ProfilePage

Le contenu communautaire est devenu plus présent dans les résultats de recherche, et les données structurées peuvent aider à identifier les fils de forum et les pages de profil.

DiscussionForumPosting peut être utile pour les forums, les communautés Q&R et les plateformes de discussion où le contenu principal est une discussion générée par les utilisateurs. ProfilePage peut aider à identifier les pages portant sur des personnes ou des contributeurs, surtout lorsque l’expertise, l’auteur ou l’identité communautaire comptent.

Ce n’est pas approprié pour de simples témoignages marketing ou des commentaires de blog ordinaires. Le type de page doit correspondre à l’expérience réelle.

Types utiles mais souvent surestimés

Certains types schema.org sont sémantiquement raisonnables, mais produisent rarement à eux seuls des améliorations visibles dans la recherche.

Exemples :

  • Service
  • Thing
  • CreativeWork
  • Person
  • Place
  • ImageObject
  • WebPage
  • AboutPage
  • ContactPage

Ce ne sont pas de « mauvais » types. Ils peuvent aider à décrire une page plus précisément, et ils peuvent être utiles dans des contextes plus larges de graphe de connaissances. Mais si votre objectif est un changement visible dans les résultats de recherche, ils sont généralement secondaires.

Par exemple, baliser une page de conseil comme Service ne créera pas de manière fiable un rich result spécial pour un service. Une page bien structurée avec un texte clair, des liens internes, un rendu rapide et des preuves crédibles fera davantage pour la performance de recherche qu’un balisage élaboré mais non pris en charge.

De même, ImageObject peut décrire des images, mais la performance dans la recherche d’images dépend aussi du texte environnant, des noms de fichiers, des légendes, de la qualité des images, de l’indexation et de l’accessibilité. Le schéma ne remplace pas les bases.

JSON-LD est généralement le meilleur format d’implémentation

Les moteurs de recherche peuvent lire plusieurs formats de données structurées, dont Microdata et RDFa, mais JSON-LD est généralement le choix le plus propre.

Il garde le balisage séparé de la présentation HTML, est plus facile à tester et risque moins de se casser lorsque les designers modifient les templates. Pour la plupart des équipes, JSON-LD dans le head ou le body de la page est le choix pratique par défaut.

Un exemple simple de produit ressemble à ceci :

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Acme Carbon Tripod",
  "image": "https://example.com/images/tripod.jpg",
  "description": "A lightweight carbon tripod for travel photography.",
  "brand": {
    "@type": "Brand",
    "name": "Acme"
  },
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "149.00",
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/products/carbon-tripod"
  }
}

L’exemple est volontairement simple. La plupart des données structurées devraient être banales. L’exactitude vaut mieux que l’ingéniosité.

Un modèle de priorisation pratique

Si vous décidez quoi implémenter en premier, utilisez cet ordre :

  1. Commencez par les types de pages qui correspondent à des fonctionnalités de recherche prises en charge. Les balisages produit, recette, événement, emploi, vidéo, fil d’Ariane, article et entreprise locale méritent généralement l’attention avant les types obscurs.
  2. Balisez uniquement ce que les utilisateurs peuvent voir. Les affirmations cachées sont une raison courante pour laquelle les données structurées deviennent inadmissibles ou risquées.
  3. Corrigez les templates, pas les pages individuelles. Les données structurées sont plus faciles à maintenir lorsqu’elles sont générées à partir de votre CMS ou de votre base de données produit.
  4. Validez, puis surveillez. Utilisez les outils officiels de validation des rich results et des schémas, puis suivez les rapports d’améliorations de Search Console lorsqu’ils sont disponibles.
  5. N’ignorez pas l’expérience de page. Les rich results peuvent améliorer la présentation, mais les utilisateurs arrivent tout de même sur la page. Si les rapports de performance rendent votre équipe nerveuse, lisez les rapports Lighthouse sans paniquer avant de transformer les schémas en une autre distraction.

Erreurs courantes qui réduisent l’impact

Baliser le mauvais type de page

Une page de catégorie n’est pas une page produit. Une page d’accueil carrières n’est pas une offre d’emploi. Une liste de webinaires à venir n’est pas nécessairement un seul événement.

Les fonctionnalités de recherche sont généralement conçues autour d’intentions de page précises. Faites correspondre le balisage à l’objectif dominant de la page.

Ajouter des propriétés qui ne sont pas visibles

Si la page n’affiche pas de note, n’incluez pas aggregateRating. Si la page d’emploi ne mentionne pas le salaire, évitez d’inventer un balisage de rémunération. Si un produit est en rupture de stock, ne le marquez pas comme disponible.

Les données structurées doivent rendre les faits visibles plus faciles à analyser, et non créer une version parallèle de la page.

Considérer la validation comme une réussite

Réussir un validateur signifie seulement que la syntaxe est acceptable et que les champs requis peuvent être présents. Cela ne signifie pas que la page recevra un rich result.

Considérez la validation comme le minimum, pas comme le résultat.

Implémenter le schéma une fois et l’oublier

Les prix changent. Les emplois expirent. Les événements sont reportés. Les auteurs partent. Les logos sont refaits.

Les données structurées générées à partir de champs périmés peuvent devenir discrètement inexactes. Revoyez-les chaque fois que vous modifiez des templates, des champs CMS ou des sources de données métier.

<!-- tool-cta:start -->

💡 Essayez ceci : Avant de déterminer quels types de schémas comptent vraiment, nettoyez votre JSON-LD avec le JSON Formatter afin que la structure soit facile à auditer.

<!-- tool-cta:end -->

La recommandation sereine

Pour la plupart des sites, la stratégie de schéma devrait être modeste et délibérée.

Implémentez les types qui correspondent à votre contenu réel et qui se rattachent à des fonctionnalités de recherche prises en charge. Gardez les données exactes. Générez-les à partir de sources fiables. Validez-les. Surveillez les résultats. Puis arrêtez-vous.

Vous n’avez pas besoin de baliser chaque nom commun de la page. Vous n’avez pas besoin de douze types de schémas imbriqués parce qu’une liste de vérification le dit. Et vous n’avez certainement pas besoin de données structurées qui en disent plus que la page elle-même.

Schema.org est le plus utile lorsqu’il supprime l’ambiguïté. Les résultats de recherche s’améliorent lorsque cette clarté s’aligne sur une fonctionnalité que les moteurs de recherche prennent réellement en charge.

Questions fréquemment posées

Le balisage schema.org améliore-t-il le classement ?
Pas directement. Les données structurées aident les moteurs de recherche à comprendre le contenu des pages et peuvent rendre les pages admissibles à des rich results. Ces apparences enrichies peuvent améliorer les taux de clics, mais le balisage seul n’est pas un raccourci de classement.
Quel type de schéma la plupart des sites web devraient-ils implémenter en premier ?
Commencez par le balisage qui correspond à vos types de pages principaux. Les sites ecommerce devraient prioriser Product et BreadcrumbList. Les éditeurs devraient utiliser Article ou BlogPosting. Les entreprises locales devraient utiliser LocalBusiness. Les sites avec des vidéos, des événements, des emplois ou des recettes devraient prioriser ces types précis.
Le schéma FAQ vaut-il encore la peine d’être utilisé ?
Seulement lorsque la page contient réellement une FAQ. Les rich results FAQ sont beaucoup moins visibles qu’auparavant, surtout pour les sites commerciaux ordinaires. N’ajoutez pas de sections FAQ artificielles uniquement pour viser des fonctionnalités de recherche.
Devrais-je utiliser JSON-LD, Microdata ou RDFa ?
JSON-LD est généralement le meilleur choix pour les sites web modernes. Il est plus facile à maintenir, moins entremêlé avec les templates et largement recommandé par les moteurs de recherche pour les données structurées prises en charge.
Puis-je ajouter un schéma pour du contenu que les utilisateurs ne peuvent pas voir ?
En général, non. Les données structurées doivent décrire un contenu visible et exact sur la page. Des notes cachées, des prix inventés, une fausse disponibilité ou des données d’événement trompeuses peuvent rendre les pages inadmissibles aux rich results ou enfreindre les politiques de recherche.

Sources et lectures complémentaires

  1. Google Search Central: Structured data markup that Google Search supports
  2. Google Search Central: Intro to structured data markup in Google Search
  3. Schema.org Documentation
  4. Google Search Central Blog: Changes to HowTo and FAQ rich results
À propos de l'auteur
The Wux Webtools Team

Dernière mise à jour:

Continuez à lire