Faut-il vraiment implémenter à la fois le flux Merchant Center ET le structured data produit ?

Pourquoi Google impose-t-il deux systèmes distincts pour les données produits ?

La distinction entre flux Merchant Center et structured data repose sur deux environnements d'affichage différents. Le flux Merchant Center alimente l'onglet Shopping, les annonces Google Shopping (payantes et gratuites), et l'ensemble des surfaces shopping de Google. Ce flux est structuré selon un format XML ou TXT spécifique, hébergé sur vos serveurs ou via une plateforme tierce.

Le structured data Product, lui, est un balisage schema.org intégré directement dans le HTML de vos pages. Il permet à Google de générer des rich snippets produits dans les résultats de recherche classiques : prix, disponibilité, avis, étoiles. Ces deux systèmes ne partagent pas d'API commune et fonctionnent en silos — d'où la nécessité de maintenir les deux en parallèle.

Que se passe-t-il si on n'utilise qu'un seul des deux formats ?

Si vous ne déployez que le flux Merchant Center, vos produits apparaîtront dans l'onglet Shopping et les annonces gratuites, mais vos pages ne bénéficieront d'aucun rich snippet dans les résultats organiques classiques. Vous perdez donc de la visibilité et du CTR sur les requêtes informationnelles ou transactionnelles qui ne déclenchent pas l'interface Shopping.

À l'inverse, si vous n'implémentez que le structured data sans flux Merchant Center, vos produits ne seront pas éligibles aux surfaces Shopping gratuites. Vous passez à côté d'un canal d'acquisition majeur, surtout sur mobile où l'onglet Shopping capte une part significative du trafic e-commerce.

Cette double saisie est-elle vraiment nécessaire à long terme ?

Mueller évoque une potentielle simplification future, sans donner de calendrier ni de détail technique. L'idée serait de permettre à Google de réconcilier automatiquement les données issues du flux et du balisage, voire de n'exiger qu'un seul format. Mais cette déclaration reste floue et conditionnelle — aucune roadmap officielle n'a été publiée.

En attendant, la redondance est assumée par Google et présentée comme un mal nécessaire. Les e-commerçants doivent donc maintenir deux systèmes de données produits, avec les coûts de développement, de synchronisation et de maintenance que cela implique.

• Flux Merchant Center : obligatoire pour les surfaces Shopping (onglet, listings gratuits, Google Lens, YouTube Shopping).
• Structured data Product : obligatoire pour les rich snippets dans les résultats organiques classiques.
• Double maintenance : actuellement incontournable si vous visez une visibilité maximale.
• Simplification annoncée : hypothétique, aucun engagement ni calendrier.

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Oui, la complémentarité entre flux et structured data est une réalité observée depuis l'ouverture des listings gratuits dans l'onglet Shopping. Les sites qui n'ont déployé que l'un des deux formats constatent systématiquement une perte de visibilité partielle : soit dans les rich snippets organiques, soit dans les surfaces Shopping. Cette redondance est documentée depuis des années dans les guidelines officielles de Google.

En revanche, la promesse de simplification est beaucoup plus discutable. Google évoque régulièrement des « rationalisations à venir » sans jamais les concrétiser. Le cas le plus emblématique est celui du markup AggregateRating, qui reste distinct du flux Merchant Center malgré des années de demandes terrain. Rien n'indique qu'une fusion soit techniquement triviale ou prioritaire pour Google.

Quelles nuances faut-il apporter à cette recommandation ?

Mueller parle de « structured data produit », mais ne précise pas si cela inclut uniquement le type Product ou également les types Offer, AggregateOffer, Review. Dans la pratique, un balisage Product complet doit inclure des entités imbriquées (Offer pour le prix, AggregateRating pour les avis, ImageObject pour les visuels). Ce niveau de granularité n'est pas explicité dans la déclaration.

Par ailleurs, le flux Merchant Center exige des attributs spécifiques non couverts par schema.org : GTIN, MPN, brand (obligatoires pour certaines catégories), shipping, tax, age_group, gender, color, size. Ces champs ne figurent pas dans le vocabulaire Product de schema.org, ce qui rend la « simplification » techniquement complexe. [A vérifier] : aucune source officielle ne détaille comment Google compte réconcilier ces deux schémas de données aux structures différentes.

Dans quels cas cette règle ne s'applique-t-elle pas ou nécessite-t-elle des adaptations ?

Si vous vendez des produits numériques, services ou contenus non physiques, le flux Merchant Center n'est généralement pas pertinent (sauf cas d'usage spécifiques comme les abonnements ou licences). Le structured data Product reste alors suffisant pour générer les rich snippets. Attention toutefois : Google peut interpréter ces produits comme non éligibles aux rich results s'ils ne respectent pas les guidelines (pas de prix fictif, disponibilité vérifiable).

Pour les sites multilingues ou multi-devises, la synchronisation entre flux et structured data devient un casse-tête : le flux Merchant Center exige un flux par pays/langue, tandis que le balisage on-page doit refléter la devise et la langue de la page affichée. Une désynchronisation peut entraîner des rejets de produits dans Merchant Center ou des rich snippets incohérents. Ce point n'est jamais abordé dans les communications officielles.

Que faut-il faire concrètement pour aligner flux et structured data ?

La première étape consiste à auditer les disparités entre vos données Merchant Center et votre balisage on-page. Exportez votre flux actuel et comparez les champs price, name, availability, image, brand avec le contenu de vos balises schema.org Product. Les écarts les plus fréquents concernent les variations de prix dynamiques (promos, remises géolocalisées) et les stocks en temps réel.

Ensuite, implémentez un système de synchronisation automatisé : idéalement, vos données produits doivent provenir d'une source unique (PIM, ERP, CMS) qui alimente à la fois le flux XML et le JSON-LD injecté dans vos pages. Les solutions headless e-commerce (Shopify, WooCommerce, Magento) proposent des plugins qui génèrent les deux formats simultanément, mais vérifiez toujours la cohérence post-déploiement.

Quelles erreurs éviter lors de l'implémentation ?

Ne jamais dupliquer les données manuellement entre flux et balisage : cela génère inévitablement des désynchronisations (prix obsolètes, produits en rupture affichés disponibles). Utilisez des variables dynamiques et des templates pour garantir que les deux sources se mettent à jour en même temps. Attention également aux erreurs de syntaxe JSON-LD qui invalident le structured data sans déclencher d'alerte visible côté utilisateur.

Évitez aussi de surcharger le balisage Product avec des données non pertinentes. Google pénalise le markup « spammy » : ne renseignez pas de champs fictifs (avis inventés, prix factices, disponibilité trompeuse) pour forcer l'affichage de rich snippets. Les validations manuelles de Google peuvent entraîner des actions manuelles sur l'ensemble du site.

Comment vérifier que votre implémentation est conforme et efficace ?

Utilisez le Rich Results Test de Google pour valider le structured data de vos pages produits. Testez plusieurs pages (produit en stock, en rupture, en promo) pour vérifier que le balisage s'adapte dynamiquement. Côté Merchant Center, consultez les rapports de diagnostic : rejets de produits, avertissements sur les champs manquants, disparités de prix.

Enfin, surveillez vos performances dans Google Search Console : le rapport « Performances » filtré sur les pages produits permet de mesurer l'impact des rich snippets sur le CTR. Comparez les impressions et clics avant/après déploiement du balisage. Pour les surfaces Shopping, analysez les données dans l'onglet « Shopping » de GSC (si activé) ou directement dans le tableau de bord Merchant Center.

• Auditer les écarts entre flux Merchant Center et structured data Product
• Automatiser la synchronisation via PIM, API ou plugin CMS
• Valider le JSON-LD avec le Rich Results Test de Google
• Vérifier les rapports de diagnostic Merchant Center (rejets, avertissements)
• Surveiller le CTR des pages produits dans Search Console
• Tester plusieurs scénarios (stock, promo, multi-devises) pour garantir la cohérence dynamique