IA & catalogue Guide
Données structurées produit et flux Merchant Center : comment les articuler
Les données structurées Product balisent les fiches produit, le flux Google Merchant Center alimente les fiches marchandes et Shopping. Les deux mécanismes se complètent : ce guide explique lequel mettre en place, dans quel ordre, et ce que chacun exige.

Deux mécanismes distincts permettent à un produit d’apparaître de façon enrichie dans Google Search : les données structurées posées directement sur les pages du site, et le flux transmis à Google Merchant Center. Beaucoup de boutiques n’en activent qu’un seul, parfois sans le savoir, et se privent d’une partie de la visibilité gratuite que Google propose sur les fiches produit. Comprendre ce que fait chacun, et dans quel ordre les mettre en place, évite de payer pour de la visibilité qui pourrait être obtenue sans enchère.
Deux mécanismes, un même objectif
Le premier mécanisme, les données structurées « Product », est un balisage ajouté dans le code de chaque page produit. Il informe Google du nom, du prix, de la disponibilité et de la note du produit affiché sur cette page précise. Le second, le flux Google Merchant Center, est un fichier envoyé périodiquement à Google, listant l’intégralité du catalogue avec ses attributs commerciaux. Google le précise explicitement dans sa documentation sur les données structurées Product : fournir à la fois des données structurées sur les pages et un flux Merchant Center maximise l’éligibilité aux différentes expériences de recherche, et aide Google à vérifier la cohérence des informations. Les deux mécanismes ne sont donc pas concurrents, ils se recoupent et se renforcent.
Cette distinction recoupe deux formats d’affichage différents dans les résultats. Les extraits produit (product snippets) concernent des pages où l’achat n’est pas forcément possible directement, comme une page éditoriale de comparatif : ils autorisent un prix à zéro et mettent en avant les avis. Les fiches marchandes (merchant listings) concernent uniquement les pages où un client peut réellement acheter le produit : elles exigent un prix strictement supérieur à zéro et ouvrent droit à des informations plus détaillées, comme les tailles disponibles, les frais de port ou la politique de retour.
Ce que les données structurées doivent contenir
Pour qu’une page produit soit éligible aux fiches marchandes, Google impose un socle minimal de propriétés. Sur l’objet Product : le name (le titre du produit) et l’image (une ou plusieurs photos en haute résolution). Sur l’objet Offer imbriqué : le price, qui doit être strictement supérieur à zéro pour une fiche marchande, et le priceCurrency, exprimé selon le code ISO 4217 à trois lettres (EUR, par exemple).
Au-delà de ce socle obligatoire, une série de propriétés recommandées conditionne la richesse réelle de l’affichage : la note moyenne (aggregateRating), la marque (brand.name), la description, la référence produit (sku) ou le code international (gtin) côté Product ; la disponibilité (availability), l’état du produit (itemCondition), les détails de livraison (shippingDetails) et la politique de retour (hasMerchantReturnPolicy) côté Offer. Un catalogue qui vend le même modèle en plusieurs tailles ou coloris doit en plus structurer ces variantes avec les types ProductGroup et Product, pour que Google comprenne qu’il s’agit d’un seul produit décliné plutôt que de plusieurs fiches concurrentes.
Sur WooCommerce comme sur PrestaShop, ce balisage est généralement généré automatiquement par le thème ou par une extension dédiée au référencement, à condition que les champs correspondants (prix, image, marque, stock, code EAN ou GTIN) soient effectivement renseignés dans les fiches produit. C’est souvent là que le bât blesse : le balisage technique fonctionne, mais les champs sources sont vides ou incomplets.
Le flux Merchant Center, complément indispensable
Le flux Merchant Center reprend une bonne partie des mêmes attributs, mais dans un fichier séparé, mis à jour à intervalle régulier plutôt qu’à chaque chargement de page. Il ouvre l’accès aux fiches gratuites de l’onglet Shopping et sert de source de référence quand les données structurées d’une page sont absentes ou incomplètes. Google indique par exemple que certaines expériences peuvent combiner les deux sources, en récupérant le prix depuis le flux si les données structurées de la page n’en fournissent pas.
Pour une boutique qui gère un catalogue déjà traduit ou construit pour le flux Merchant Center, l’ajout des données structurées sur les pages est la suite logique plutôt qu’un chantier séparé : les deux exports partagent en grande partie les mêmes champs (nom, prix, image, GTIN, disponibilité), et les fiabiliser une fois profite aux deux canaux.
Par où commencer, dans quel ordre
Le chantier se mène par étapes, en commençant par fiabiliser les données à la source plutôt que par le balisage technique lui-même.
- Auditer les champs produits. Vérifier que chaque fiche possède un prix, une image en haute résolution, un code GTIN ou EAN et un statut de stock à jour ; ce sont les champs qui alimenteront à la fois le balisage et le flux.
- Activer ou configurer le balisage Product. Sur WooCommerce comme sur PrestaShop, ce rôle est le plus souvent tenu par le thème ou par une extension SEO ; il s’agit de vérifier qu’elle expose bien price, priceCurrency, availability et, pour les articles déclinés, ProductGroup.
- Corriger d’abord les fiches marchandes. Prioriser les pages où l’achat est possible : ce sont elles qui donnent accès aux informations enrichies de livraison et de retour, et qui pèsent le plus sur le taux de clic.
- Construire ou mettre à jour le flux Merchant Center avec les mêmes champs que ceux du balisage, pour que les deux sources se recoupent sans se contredire.
- Contrôler dans Search Console que les pages sont bien détectées comme éligibles, et corriger les avertissements avant qu’ils n’affectent l’ensemble du catalogue.
Un point mérite une vigilance particulière : les deux sources doivent raconter la même histoire. Un prix différent entre la page et le flux, une disponibilité qui ne correspond pas au stock réel, ou des descriptions générées automatiquement qui s’écartent trop du produit réel affaiblissent la confiance que Google accorde aux deux canaux à la fois, pas seulement à celui qui est fautif.
Ce qu’il faut retenir
- Les données structurées Product (posées sur chaque page) et le flux Google Merchant Center sont complémentaires, pas concurrents : Google recommande explicitement les deux.
- Une fiche marchande exige un prix supérieur à zéro, une devise au format ISO 4217, et gagne en richesse avec la marque, le GTIN, la disponibilité et la politique de retour.
- Les catalogues avec variantes (taille, coloris) doivent structurer leurs déclinaisons avec ProductGroup et Product pour éviter les fiches concurrentes.
- La priorité va à la fiabilité des champs sources : un balisage techniquement correct sur des données incomplètes n’apporte rien.
Sur la plupart des boutiques que j’audite, le balisage technique est déjà en place via le thème ou une extension : le vrai chantier est presque toujours de compléter les champs produits eux-mêmes, en particulier le GTIN et la politique de retour, souvent laissés vides depuis la mise en ligne. — Simon Janvier
Vos fiches produit sont-elles réellement éligibles aux résultats enrichis de Google ? L’audit offert vérifie le balisage des données structurées et la cohérence du flux Merchant Center sur un échantillon de votre catalogue. Demander l’audit e-commerce