Données structurées d'une fiche produit : baliser Product et Offer

Deux fiches produits peuvent contenir exactement les mêmes informations et s’afficher très différemment dans Google : l’une avec son prix, sa note en étoiles et un « en stock » sous le lien, l’autre avec un simple titre bleu. Ce qui les sépare, ce sont les données structurées de la fiche produit : les types Product et Offer. Ce guide traite ce cas précis, celui d’un site marchand. Le balisage en général, les formats et la façon de le vérifier sont ailleurs, dans les données structurées expliquées simplement.

Ce que Product et Offer déclenchent, et ce qu’ils ne déclenchent pas

Deux effets réels, et deux confusions à lever tout de suite.

Les résultats enrichis marchands

Sous votre lien, Google peut afficher le prix, la disponibilité, la note en étoiles et parfois la promotion en cours. Votre ligne prend de la place dans la page de résultats et donne l’essentiel avant le clic, ce qui compte particulièrement sur une requête où l’internaute compare plusieurs marchands du même article.

La reprise par les assistants

Effet plus récent : quand quelqu’un demande à une IA où trouver tel produit, une fiche dont le prix et le stock sont déclarés proprement se reprend sans contresens, là où un prix noyé dans une image ne se lit pas. Le balisage est le seul endroit de la page où ces informations existent sous une forme non ambiguë.

Classer, et remplacer un flux : les deux choses qu’il ne fait pas

Première confusion : ce balisage ne vous fait pas mieux classer, il rend votre fiche plus reprise à position égale. Seconde confusion, plus coûteuse : il ne remplace pas un flux produits. Google Shopping s’alimente d’un flux envoyé au Merchant Center, avec ses propres champs et ses propres validations, sujet traité dans Google Ads pour un e-commerce. Les deux se ressemblent, ils ne se substituent pas : le balisage travaille pour la recherche classique et pour les assistants, le flux travaille pour Shopping. Une boutique sérieuse tient les deux, et les tient cohérents.

Les données structurées d’une fiche produit, champ par champ

Tous les champs ne pèsent pas pareil. Voici ceux qui décident.

Côté Product : le nom, l’image, la marque et l’identifiant

Le name doit porter le nom commercial complet, celui que le client tape, pas une référence interne. L’image doit être la photo réelle du produit, celle qui est affichée. La brand pèse plus que sa discrétion ne le laisse croire sur les produits de marque. L’identifiant ensuite : le gtin (le code-barres) s’il existe, sinon le mpn du fabricant, sinon votre sku. Sur un produit revendu par vingt boutiques, c’est lui qui permet à Google de savoir que vous vendez le même article que les autres, et c’est le grand absent des balisages livrés par défaut.

Côté Offer : prix, devise, disponibilité

Trois champs sont obligatoires en pratique, plus l’adresse de la fiche. Le prix et la devise d’abord, sans lesquels aucun résultat enrichi marchand n’est possible. La disponibilité ensuite, qui prend une valeur normalisée : InStock, OutOfStock, PreOrder ou BackOrder. Ces trois valeurs doivent venir du catalogue, jamais d’une saisie parallèle.

Les avis : la seule balise qui se pose ou ne se pose pas

Les avis, aggregateRating et review, ne se balisent que s’ils sont réellement affichés sur la page. Aucun avis visible, aucune balise d’avis : c’est la règle qui évite une pénalité, et elle n’a pas d’exception. Une note moyenne déclarée sur une fiche qui n’en montre aucune est traitée comme une donnée fabriquée, et c’est le type d’écart qui fait passer un site de la simple perte d’affichage enrichi à l’action manuelle. Nous appliquons la même règle sur nos propres pages, et elle nous coûte des étoiles : nous n’émettons aucune note agrégée.

Le balisage minimal d’une fiche, et ce qu’il ne contient pas

Voici la forme la plus courante, en JSON-LD, pour un produit simple et disponible. Le produit, la marque et le domaine sont fictifs : ce sont des valeurs d’illustration, pas un tarif.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Gourde isotherme inox 50 cl, coloris ardoise",
  "image": "https://exemple.fr/img/gourde-inox-50cl.jpg",
  "sku": "GRD-INX-50",
  "brand": { "@type": "Brand", "name": "Marque Exemple" },
  "offers": {
    "@type": "Offer",
    "url": "https://exemple.fr/bouteilles/gourde-inox-50cl",
    "price": "24.90",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}

Ce que cet exemple contient volontairement

Le prix est écrit en nombre décimal avec un point, sans symbole ni espace, et la devise est portée par son propre champ. La disponibilité est une adresse normalisée de schema.org, pas un texte libre comme « en stock ». L’url de l’offre est celle de la fiche elle-même. Ce sont les quatre erreurs de saisie les plus fréquentes, et elles se voient immédiatement dans un outil de test.

Ce qu’il ne contient pas, et pourquoi

Aucun aggregateRating, aucun review. Cette page ne montre aucun avis produit : le balisage ne peut donc pas en déclarer. Ajoutez ces deux champs uniquement le jour où de vrais avis sont visibles sur la fiche, avec le même nombre d’avis et la même note que ceux affichés.

Les déclinaisons : là où la plupart des boutiques se trompent

C’est le point que les guides généraux ne traitent jamais, et c’est pourtant le cas le plus fréquent en boutique : un même produit décliné en tailles, en contenances, en coloris, avec des prix différents.

Une seule page pour toutes les déclinaisons

Si les variantes vivent sur la même adresse, la page décrit un groupe. L’usage est de déclarer un ProductGroup qui contient chaque variante avec son identifiant et son prix propre, ou à défaut une fourchette via AggregateOffer. Le groupe porte ce qui est commun, chaque variante porte ce qui la distingue.

Une adresse par déclinaison

Si chaque déclinaison a sa propre adresse, chacune porte son Product et son Offer, avec le prix et le stock de cette variante-là. C’est la structure la plus simple à baliser correctement, et la plus exigeante côté référencement, parce qu’elle multiplie des pages très proches les unes des autres.

Le prix d’appel, l’erreur qui coûte l’affichage

Ce qui ne marche dans aucun des deux cas, c’est de baliser le prix le plus bas pour une page qui en affiche un autre. Une huilerie de Clermont-l’Hérault dont nous avons construit la boutique vend ses huiles déclinées par variété d’olive, avec un sélecteur de variétés : baliser la moins chère sur une page qui laisse choisir, c’est promettre un prix qui n’existe pas au moment du clic.

Le balisage qui ment coûte plus cher que le balisage absent

Le prix qui a bougé, le stock qui n’a pas suivi

Sur les boutiques que nous suivons dans la région, le problème rencontré le plus souvent n’est presque jamais un balisage absent : c’est un balisage désynchronisé du prix ou du stock réel. La cause est presque toujours la même, une valeur saisie une fois quelque part au lieu d’être lue dans le catalogue, et elle se révèle à la première promotion.

Le balisage recopié à côté du catalogue

Un module qui laisse remplir les champs à la main, un bloc collé dans le thème, une valeur figée dans un gabarit : tout balisage qui n’est pas alimenté par la fiche produit finit par mentir, parce que personne ne pense à le mettre à jour en même temps que le prix. La règle tient en une phrase : si vous pouvez modifier le prix affiché sans que le balisage change, votre balisage est déjà faux.

Poser et surveiller le balisage sur PrestaShop ou WooCommerce

1. Repérez qui pose le balisage

   Sur PrestaShop comme sur WooCommerce, c’est le thème ou le module de référencement. Vous vérifiez sa présence et sa qualité, vous ne le tapez pas à la main.

2. Branchez chaque champ sur le catalogue

   Le prix balisé doit venir du champ prix du produit, la disponibilité du stock réel. Une valeur écrite en dur est une valeur fausse à la prochaine mise à jour.

3. Complétez ce qui manque

   Les identifiants (gtin, mpn, sku) et la brand sont les grands absents des balisages livrés par défaut. Ils se remplissent dans la fiche produit, pas dans le code.

4. Testez un exemplaire de chaque gabarit

   Produit simple, déclinaisons, pack, rupture, promotion, dans l’outil de test des résultats enrichis de Google. Corrigez les erreurs avant les avertissements.

5. Surveillez dans la durée

   Le rapport « Fiches produits » de la Search Console signale les fiches qui décrochent, souvent après une mise à jour de thème ou de module. C’est le contrôle qui rattrape les régressions silencieuses.

Tester par gabarit, pas par produit

Sur une boutique, quatre ou cinq gabarits couvrent tout le catalogue : le produit simple, le produit à déclinaisons, le pack, le produit en rupture, le produit en promotion. Un exemplaire de chacun passé dans l’outil de test, et vous avez couvert des milliers de fiches en un quart d’heure. Le gabarit oublié presque à chaque fois reste le produit en rupture, dont l’availability demeure bloquée sur « en stock » parce que personne n’a pensé à tester ce cas-là.

Compter ses gabarits avant de commencer

Certains catalogues en comptent davantage, et il vaut mieux les lister que les découvrir. Une boutique de cartes à collectionner d’Alès dont nous avons construit le site vend des cartes à l’unité, des produits scellés, des accessoires et des cartes gradées : ce sont autant de familles de fiches qui ne se remplissent pas de la même façon. Écrivez la liste de vos gabarits une fois, elle servira à chaque recette.

Le balisage est une brique parmi d’autres dans le référencement d’un catalogue : il ne remplace ni des catégories écrites ni des fiches sorties du texte fournisseur, et l’ordre des leviers est posé dans référencer une boutique en ligne. Si votre boutique n’existe pas encore, ces réglages se prévoient dès la conception : voyez créer une boutique en ligne.

Un gabarit de fiche, puis tous les autres

Sur les boutiques PrestaShop et WooCommerce que nous construisons à Vendargues pour les commerçants, les producteurs et les PME de la région de Montpellier, le balisage Product/Offer est branché sur le catalogue plutôt qu’à côté : le prix, le stock et les avis affichés dans Google sont les vrais, y compris sur les déclinaisons et les produits en rupture. Chaque balise correspond à une donnée réelle du catalogue. Nous travaillons tout inclus, sur devis. Pour confier le vôtre, découvrez notre création de site e-commerce à Montpellier, et pour les autres briques techniques, le fil d’Ariane et le sitemap XML.