Schema.org e-commerce en 2026 : quels types déployer

Ce que le balisage change, et ce qu'il ne change pas

Schema.org est un vocabulaire partagé qui permet de déclarer dans le code d'une page ce que cette page contient : un produit, un prix, une disponibilité, un fil d'Ariane, une organisation, une vidéo. Les moteurs lisent ces déclarations au lieu de les déduire de la mise en page.

Le balisage ouvre une éligibilité, celle des affichages enrichis dans les résultats de recherche. Il ne fournit pas de position. Une page mal classée et parfaitement balisée reste mal classée, et l'affichage enrichi lui-même relève de Google, qui l'accorde ou non.

L'erreur inverse coûte plus cher que l'absence de balisage. Une déclaration engage : elle doit décrire ce que le visiteur voit à l'écran, prix compris. Les conditions à respecter pour rester éligible sont fixées par Google, et nous ne les résumons pas ici : ouvrez la galerie des résultats enrichis de Google Search Central avant de décider, et la page du type que vous posez.

Sur les fiches produit, ce qui est déclarable et ce qui donne lieu à un affichage se lisent à la source, jamais dans la synthèse d'une agence : la page Product de Google Search Central pour ce gabarit, et la galerie des résultats enrichis pour les autres. Google Search Central documente les données structurées type par type, et c'est là que se lisent les propriétés attendues, les affichages associés et les conditions à remplir pour y prétendre. Cette documentation évolue : ouvrez-la le jour où vous décidez, et tenez-vous-en à la version que vous y trouvez ce jour-là. Notre article sur les données structurées Product descend au niveau des propriétés d'une fiche. La question traitée ici porte sur le périmètre : quels types déployer sur un catalogue entier, dans quel ordre les poser, et comment vérifier le travail livré.

Les types qui portent l'essentiel sur un site marchand

Le raisonnement se fait par gabarit, jamais page par page. Un site marchand en compte rarement plus d'une dizaine, et chaque gabarit reçoit son jeu de types.

La liste qui suit décrit ce que nous posons, gabarit par gabarit, et non ce que Schema.org définit. Chaque type dispose de sa propre page sur schema.org : la définition, les propriétés attendues et les rattachements entre types s'y vérifient, page ouverte, et pas dans notre liste.

Fiche produit. Product et Offer. C'est le gabarit qui porte l'enjeu marchand, et celui dont les valeurs changent tous les jours.

Déclinaisons. ProductGroup. Sur un catalogue textile ou mobilier, nous le posons pour rattacher entre elles les déclinaisons d'un même modèle, tailles ou coloris, plutôt que de publier chaque taille comme un produit isolé.

Livraison et retours. Les frais de livraison et les conditions de retour forment un sujet à part. Ce qui est déclarable, et sous quelles conditions, s'établit dans la documentation Google consacrée aux données structurées marchandes, à ouvrir avant de décider, pas d'après un devis ni d'après cet article. Google documente à part les product snippets : deux familles d'affichages, deux pages de documentation, et les conditions propres à chacune se lisent sur la sienne. Les mêmes informations circulent en général ailleurs chez vous, dans le flux produit et dans le back office, et deux déclarations qui divergent produisent un affichage incohérent : tranchez laquelle fait foi avant d'écrire la moindre ligne. Notre article sur le paramétrage de Merchant Center pose ce cadrage du côté du flux.

Navigation. BreadcrumbList, sur tous les gabarits. Peu coûteux, nous le posons sur le chemin de navigation de la page, qui doit correspondre à votre arborescence réelle.

Identité du site. Organization, une seule fois, pour l'identité de l'entreprise. Rien de spectaculaire en résultat de recherche, mais c'est ce qui rattache vos pages à une entité identifiée. Notre article sur le GEO situe ce que les données structurées font du côté des moteurs génératifs, et ce qu'elles n'y font pas.

Points de vente. LocalBusiness ou Store, une déclaration par magasin, sur la page de ce magasin.

Pages de catégorie. ItemList, sur les éléments listés. Nous n'y promettons aucun affichage : nous le posons pour que la liste soit décrite explicitement plutôt que déduite de la mise en page.

Contenus. Article pour les pages de blog, VideoObject pour les vidéos hébergées sur vos fiches produit.

Avis. AggregateRating et Review, traités propriété par propriété dans l'article cité plus haut.

Le type à sortir du plan

Un type revient encore sur les devis, avec un affichage promis dans la foulée : FAQPage. Nous ne le posons plus par défaut sur un catalogue. Cette position en révise une antérieure : notre grille de priorisation d'un audit SEO e-commerce range encore FAQ parmi les chantiers à programmer après Product sur les pages de catégorie, et cette section n'a pas été reprise depuis. C'est le présent article qui fait foi sur ce type. Nous n'écrivons pas non plus ici la règle du moment sans l'avoir relue : sa page de documentation Google est à ouvrir avant toute discussion, et c'est elle qui fait foi, pas notre mémoire. La règle à appliquer devant un devis ne dépend pas de cette lecture : aucun affichage n'est acquis tant qu'il n'a pas été montré, et la charge de la preuve appartient au prestataire, qui doit montrer l'affichage obtenu sur une URL réelle de votre site avant de la facturer. Un type dont personne ne sait montrer l'affichage sort du plan.

Le contrôle vaut au-delà de ce seul type. La documentation Google sur les résultats enrichis se relit à chaque plan de déploiement plutôt qu'une fois pour toutes, et une proposition commerciale se lit à côté d'elle, page ouverte : aucun type ne se paie sur sa seule présence dans un devis.

S'ajoute une pratique à proscrire, qui ne dépend d'aucun type : baliser des données que la page n'affiche pas.

La question à poser devant un devis qui contient un type dont vous ne voyez pas l'affichage : quel affichage précis attendez-vous, et sur quelle page de documentation vous appuyez-vous ?

L'ordre de déploiement sur un catalogue

Six étapes, dans cet ordre.

1. Inventorier l'existant, gabarit par gabarit. Thème, extension, gestionnaire de balises : le doublon est fréquent, et deux blocs Product sur une même page se repèrent avant de poser quoi que ce soit.

2. Choisir la source de vérité. Le balisage se génère depuis les données du back office ou du flux produit, rendu côté serveur. Une valeur saisie à la main dérive dès la première remise de prix.

3. Aligner prix, disponibilité et délais entre la page, le flux et le balisage. Nos consultants ont tous exercé du côté annonceur en e-commerce, et c'est l'étape où le sujet cesse d'appartenir au seul référencement naturel : un écart de prix se paie des deux côtés, sur les pages comme sur le flux qui alimente vos campagnes.

4. Tester sur un gabarit avant de généraliser, avec l'outil de test des résultats enrichis de Google, sur plusieurs URL réelles et pas seulement sur un extrait de code collé.

5. Surveiller après le déploiement, dans la Search Console de votre site, ce que Google retient de votre balisage. La prise en compte n'est jamais immédiate : elle suit le rythme d'exploration de votre site, et ce délai ne se décrète pas depuis un devis.

6. Rejouer l'inventaire après chaque changement de thème ou refonte. Un balisage correct disparaît le jour où le gabarit change, et personne ne le remarque avant la baisse des affichages.

La charge de ces six étapes dépend de l'état du catalogue bien plus que du nombre de types posés. Un catalogue déjà propre traverse le protocole sans histoire. Un site dont les prix vivent dans trois systèmes différents demande d'abord une remise à plat de ses données, et c'est ce chantier-là qui commande le calendrier.

Ce qu'une agence doit pouvoir vous montrer

Cinq livrables suffisent à juger du sérieux d'une proposition.

1. La cartographie des gabarits, avec les types posés sur chacun et l'existant déjà en place.

2. Le mode de génération retenu, avec la source de données pour chaque propriété : prix, stock, délai de livraison, note.

3. Le résultat des tests sur un échantillon d'URL par gabarit, avant et après intervention.

4. La liste des affichages visés, chacun rattaché à une page de documentation Google en vigueur, à recouper avec la galerie des résultats enrichis.

5. Le protocole de surveillance dans la Search Console : rapports suivis, fréquence de relevé, personne responsable.

Les questions à poser en rendez-vous en découlent.

1. Quels types posez-vous sur quels gabarits, et lesquels écartez-vous ?

2. D'où viennent le prix et la disponibilité du balisage, et que se passe-t-il pendant une opération commerciale ?

3. Qui reprend le balisage le jour où nous changeons de thème ?

4. Comment tranchez-vous une divergence entre le balisage de la page et les données du flux produit ?

5. Quels affichages attendez-vous, et à quelle échéance les regarde-t-on ensemble ?

La deuxième question sépare les propositions. Un prestataire qui répond par une extension à installer, sans nommer la source des valeurs, livrera un balisage juste le jour de la recette et faux la semaine suivante.

La troisième aussi. Le balisage est un actif technique qui se casse en silence lors des refontes, et rien ne le rattrape tant que sa maintenance n'appartient à personne.

Par où commencer

Commencez par l'inventaire. Il demande quelques URL représentatives de chaque gabarit et un accès à votre Search Console, et il fait ressortir en général deux choses : des types posés qui n'ouvrent plus rien, et un gabarit important laissé de côté.

Nos équipes de Lille et de Montréal instruisent ce sujet avec le flux produit et les pages dans la même main, parce que le prix et le stock alimentent les deux et se contredisent au premier écart.

Notre grille de priorisation d'un audit SEO e-commerce situe le balisage parmi les autres chantiers, sous réserve de ce qui est dit plus haut sur FAQPage, et notre page SEO e-commerce détaille la méthode complète. Pour faire évaluer ce que votre catalogue expose aujourd'hui, écrivez-nous.