Les données structurées améliorent-elles vraiment la précision du crawl Merchant Center ?

Pourquoi Google insiste-t-il sur les données structurées pour Merchant Center ?

La déclaration d'Alan Kent cible un problème très concret : Merchant Center collecte les informations produit via plusieurs canaux — flux XML/CSV, crawl du site, API. Quand le bot visite vos pages, il doit extraire prix, disponibilité, variantes, GTIN, etc. Sans balisage structuré, il se repose sur l'analyse du DOM et l'intelligence artificielle pour deviner où sont ces données.

Le résultat ? Des erreurs d'extraction fréquentes. Un prix affiché en gros sur la page mais non détecté parce qu'il est dans un élément JavaScript non crawlable. Une disponibilité en stock mal interprétée. Des variantes confondues avec des produits distincts. Les données structurées éliminent cette ambiguïté : vous dites explicitement à Google « voici le prix, voici le GTIN, voici la dispo ».

Quelle différence entre le flux Merchant Center et le crawl des pages ?

Beaucoup de marchands pensent que leur flux XML suffit. Techniquement oui, mais Google cross-check les données du flux avec ce qu'il trouve sur les pages. Si votre flux indique 49€ et que la page affiche 59€ (ou que Google ne trouve aucun prix structuré), vous créez un signal de discordance.

Merchant Center peut alors rejeter le produit, demander une révision manuelle, ou simplement dégrader sa confiance dans votre catalogue. Les données structurées servent de pont de validation : elles confirment que ce que vous déclarez dans le flux correspond à ce que l'utilisateur voit réellement.

Quels types de données structurées sont concernés ici ?

On parle principalement de Schema.org/Product et Schema.org/Offer. Les propriétés critiques : price, priceCurrency, availability, gtin, brand, sku, image, name, description. Si vous vendez des variantes (tailles, couleurs), l'implémentation se complique avec variesBy et des Offer multiples.

Google accepte JSON-LD, Microdata et RDFa, mais JSON-LD reste le standard de facto en 2024 pour sa facilité de maintenance et sa compatibilité avec les CMS. L'erreur fréquente : baliser uniquement le produit principal et oublier les offres spécifiques aux variantes, ce qui crée des orphelins dans Merchant Center.

• Schema.org/Product : structure la fiche produit complète (nom, description, images, identifiants)
• Schema.org/Offer : détaille le prix, la devise, la disponibilité, les conditions de vente
• Propriétés essentielles : price, priceCurrency, availability, gtin/mpn, sku, url
• Validation obligatoire : utiliser le Rich Results Test et l'onglet Issues de Merchant Center
• Synchronisation flux/page : les données structurées doivent matcher exactement ce que contient le flux XML

Cette recommandation change-t-elle quelque chose aux pratiques observées ?

Soyons honnêtes : les professionnels e-commerce sérieux implémentent déjà Product Schema depuis des années. Ce n'est pas une révélation. La vraie question est pourquoi Google choisit de le rappeler maintenant — et la réponse probable, c'est que trop de sites comptent uniquement sur leur flux sans baliser les pages.

Sur le terrain, on observe effectivement que les comptes Merchant Center avec un balisage structuré propre ont moins de refus produit et moins d'alertes de discordance. Mais — et c'est là que ça coince — Google ne publie aucune donnée chiffrée sur ce « significativement ». 10% d'amélioration ? 50% ? [À vérifier] car sans benchmark, c'est du déclaratif.

Quels sont les pièges réels de cette implémentation ?

Le premier piège : la duplication de données. Vous avez un flux XML qui envoie le prix à Merchant Center, et un JSON-LD sur la page qui fait pareil. Si les deux ne sont pas parfaitement synchronisés — à cause d'un délai de mise à jour, d'une promo mal propagée, d'une erreur de dev — vous créez un conflit que Merchant Center va vous reprocher.

Deuxième piège : les variantes. Beaucoup de sites implémentent un seul objet Product avec un seul Offer pour toutes les variantes. Résultat : Google ne voit qu'un prix moyen ou le prix de la variante par défaut, et rejette les autres SKU du flux qui affichent des prix différents. La bonne pratique : un Offer distinct par variante, avec aggregateRating au niveau Product et offers de type AggregateOffer.

Troisième piège sous-estimé : les données structurées ne résolvent pas les problèmes de crawl. Si vos pages produit sont en lazy loading JavaScript intégral, que le bot ne peut pas exécuter le JS dans les délais impartis, ou que votre crawl budget est saturé, avoir du JSON-LD parfait ne change rien. Google doit d'abord pouvoir accéder à la page.

Dans quels cas ce conseil est-il insuffisant ?

Pour les catalogues très dynamiques (prix qui changent plusieurs fois par jour, stocks en temps réel), le balisage structuré statique peut devenir un boulet. Si vous générez du JSON-LD côté serveur avec des données cachées 1h, et que le prix réel en base est déjà différent, vous revenez au problème de discordance.

Pour les marketplaces où plusieurs vendeurs proposent le même produit, Schema.org/Product devient ambigu : vous balisez l'offre de quel vendeur ? La moins chère ? Toutes ? Google recommande un AggregateOffer avec plusieurs sellers, mais l'implémentation est rarement faite correctement, et Merchant Center gère mal ces cas complexes.

Que faut-il auditer en priorité sur vos fiches produit ?

Première étape : vérifier la présence du balisage Product/Offer sur toutes les pages produit actives. Pas seulement les best-sellers — toutes. Un crawl Screaming Frog avec extraction du JSON-LD vous dira immédiatement quelles pages en sont dépourvues ou ont un balisage incomplet.

Deuxième étape : comparer les données structurées avec le flux Merchant Center. Exportez votre flux XML, extrayez 50-100 produits au hasard, et vérifiez manuellement que price, availability, gtin correspondent exactement entre le flux et le JSON-LD de la page. Les écarts révèlent des bugs de synchronisation qu'il faut corriger à la source.

Comment implémenter correctement sans créer de dette technique ?

La solution la plus robuste : générer le JSON-LD depuis la même source de données que le flux Merchant Center. Si votre flux XML est construit depuis votre API produit, faites en sorte que le template de page produit appelle la même API pour construire le JSON-LD. Ça garantit la cohérence par design.

Pour les variantes, ne vous contentez pas d'un Offer unique. Utilisez "offers": { "@type": "AggregateOffer", "offers": [...] } avec un Offer par SKU. Chaque Offer doit avoir son propre url (l'URL de la variante si elle existe, sinon l'URL produit avec un paramètre), son price, son availability, et son sku.

Quelles erreurs critiques faut-il éviter absolument ?

Ne balisez jamais un prix hors taxe si votre site affiche du TTC à l'utilisateur. Google attend le prix tel qu'il apparaît visuellement. Ne dupliquez pas les propriétés entre Product et Offer de manière incohérente — si vous mettez un price au niveau Product et un autre dans Offer, c'est Offer qui compte, mais ça crée de la confusion.

Ne faites pas l'impasse sur priceCurrency — c'est obligatoire. Ne mettez pas de availability générique comme « Available » si le produit est en rupture. Utilisez les valeurs Schema.org officielles : InStock, OutOfStock, PreOrder, Discontinued. Et validez systématiquement avec le Rich Results Test avant de déployer en prod.

• Auditer 100% des pages produit pour vérifier la présence de JSON-LD Product/Offer complet
• Synchroniser la génération du flux Merchant Center et du JSON-LD depuis la même source de données
• Implémenter un Offer distinct par variante avec AggregateOffer si nécessaire
• Comparer manuellement flux XML et JSON-LD sur un échantillon de 50-100 produits
• Valider chaque template avec Rich Results Test et corriger les erreurs critiques
• Monitorer les alertes Merchant Center chaque semaine pour détecter les discordances