Données structurées e-commerce : Product, Offer et Merchant Listings en 2026

Voici le problème que je rencontre chez 80 % des sites e-commerce que j'audite : ils ont du balisage Product. Ils l'ont même souvent bien implémenté. Et pourtant, leurs produits n'apparaissent ni dans les rich results shopping, ni dans le carrousel marchands, ni dans le knowledge panel produit. Pourquoi ? Parce qu'en 2026, le balisage Product seul ne suffit plus. Google attend un triptyque complet : Product, Offer et Merchant Listings.

Le balisage Product décrit ce que vous vendez. Le balisage Offer décrit à quelles conditions. Ça a l'air simple ; en pratique, c'est le champ de mines favori des développeurs e-commerce.

La plupart des implémentations que je croise en audit se limitent à ça :

{
	"@type": "Product",
	"name": "Casque Audio XZ-200",
	"offers": {
		"@type": "Offer",
		"price": "89.99",
		"priceCurrency": "EUR"
	}
}

C'est techniquement valide. Google Search Console ne vous affichera pas d'erreur. Mais c'est insuffisant pour déclencher les rich results marchands en 2026. Il manque l'availability, le priceValidUntil, le url de l'offre, le seller, et les propriétés recommandées qui font la différence entre "valide" et "éligible aux expériences enrichies".

Ce que Google attend réellement pour l'éligibilité Merchant Listings :

• availability : InStock, OutOfStock, PreOrder. Techniquement recommandé par Google (pas obligatoire au sens strict), mais dans la pratique, sans ce champ, vos chances d'apparaître dans le carousel marchand sont quasi nulles.
• priceValidUntil : la date de fin de validité du prix. Surtout utile pour les promotions.
• shippingDetails : les informations de livraison (coût, délai, zone). Google accorde un poids croissant à ce champ pour les résultats shopping.
• returnPolicy : conditions de retour (durée, type). Google veut vos conditions de retour dans le balisage, pas juste sur votre page CGV.
• hasMerchantReturnPolicy : lien entre l'offre et votre politique de retour structurée.

J'ai travaillé sur un site de matériel photo le mois dernier. 1 400 produits, tous balisés avec Product et Offer basiques. Après avoir ajouté availability, shippingDetails et returnPolicy sur les 200 produits les plus populaires, le taux d'apparition en rich results est passé de 3 % à 18 % en quatre semaines. Ce n'est pas marginal.

Voilà où ça devient intéressant. Google distingue deux types de résultats enrichis pour les produits :

• Product snippets : pour les pages non-transactionnelles (tests, comparatifs, avis). Ils mettent en avant les notes et les avis.
• Merchant Listings : pour les pages transactionnelles. Ils mettent en avant le prix, la disponibilité, la livraison.

La majorité des sites e-commerce ne balisent que Product snippet alors qu'ils devraient baliser en Merchant Listing. La différence technique ? Le Merchant Listing est une extension du Product snippet avec des propriétés supplémentaires obligatoires : prix, disponibilité, et la possibilité d'achat direct sur la page.

Les critères d'éligibilité sont stricts :

1. La page doit permettre l'achat du produit (pas un lien vers un autre site)
2. Le balisage doit inclure au minimum : name, image, offers avec price et priceCurrency (l'availability est techniquement recommandée, mais considérez-la comme indispensable en pratique)
3. Les données doivent être cohérentes avec le contenu visible de la page (pas de prix dans le balisage qui diffère du prix affiché)

Ce troisième point est celui qui pose le plus de problèmes. Sur les sites avec des prix dynamiques (promotions flash, prix par quantité, prix personnalisés), le balisage est souvent désynchronisé du contenu affiché. Google détecte ces incohérences et refuse simplement l'éligibilité au rich result, sans forcément vous avertir.

C'est là que beaucoup de e-commerçants se trompent de stratégie. Ils pensent que le balisage schema et le feed Google Merchant Center sont deux choses séparées. En 2026, Google les traite comme des sources complémentaires qui se valident mutuellement.

Quand vous fournissez à la fois du balisage structuré sur vos pages et un feed Merchant Center, Google :

• Croise les données : si le prix dans votre balisage et le prix dans votre feed correspondent, le signal de confiance augmente
• Comble les lacunes : les données manquantes dans le balisage peuvent être complétées par le feed, et inversement
• Valide la cohérence : toute incohérence entre les deux sources déclenche un avertissement dans Merchant Center

Mon conseil : si vous avez un feed Merchant Center actif, assurez-vous que votre balisage schema est aligné à 100 %. Même les champs optionnels. Parce que Google utilisera la source la plus complète, et si votre balisage contredit votre feed, c'est le feed qui gagne (c'est vous qui l'avez soumis volontairement).

Un truc qui m'a surpris en travaillant sur l'intégration SEO et Merchant Center d'un client : les produits avec balisage schema complet ET feed Merchant Center affichaient un taux de clic 40 % supérieur sur les rich results par rapport à ceux avec le feed seul. Google semble accorder un bonus de visibilité quand les deux sources convergent.

En auditant des dizaines de sites e-commerce, les mêmes erreurs reviennent :

Le balisage en dur avec des prix figés. Votre CMS affiche le prix dynamiquement via JavaScript, mais le balisage JSON-LD est généré côté serveur avec le prix catalogue. Résultat : incohérence permanente en période de soldes.

Les variantes produit mal gérées. Un t-shirt en 5 couleurs et 4 tailles, c'est 20 variantes. Faut-il 20 balisages Offer distincts ou un seul avec une fourchette de prix ? Depuis 2024, Google recommande d'utiliser ProductGroup avec hasVariant et variesBy pour regrouper les variantes d'un même produit parent. L'AggregateOffer reste utilisable pour afficher une fourchette de prix, mais elle est plutôt pensée pour les marketplaces (plusieurs vendeurs), et elle pose des problèmes de correspondance de prix avec Google Merchant Center.

L'absence de gtin ou mpn. Ces identifiants produit ne sont pas obligatoires au sens strict, mais sans eux, Google peine à relier votre produit aux résultats shopping. Sur les produits de marque, l'absence de GTIN est un frein que j'observe systématiquement.

Le review auto-généré. Certains plugins ajoutent automatiquement un balisage Review avec une note parfaite quand il n'y a pas encore d'avis client. Google détecte ce pattern et peut suspendre l'éligibilité rich results pour l'ensemble du site, pas juste la page concernée.

Honnêtement, la gestion des variantes est le sujet sur lequel j'ai le plus de mal à donner un conseil universel. Ça dépend tellement de la structure du catalogue, du CMS et de la manière dont les URL sont organisées que chaque cas est un peu différent. Le seul principe qui tient partout : une offre balisée doit correspondre exactement à ce que le visiteur peut acheter sur cette page précise.

Pour les e-commerçants qui veulent commencer sans tout refondre, voici le balisage minimal que je recommande sur chaque page produit en 2026 :

{
	"@context": "https://schema.org",
	"@type": "Product",
	"name": "Nom du produit",
	"image": ["url-image-1.jpg", "url-image-2.jpg"],
	"description": "Description unique du produit",
	"brand": {
		"@type": "Brand",
		"name": "Nom de la marque"
	},
	"gtin13": "1234567890123",
	"offers": {
		"@type": "Offer",
		"url": "https://votre-site.com/produit",
		"priceCurrency": "EUR",
		"price": "89.99",
		"availability": "https://schema.org/InStock",
		"priceValidUntil": "2026-12-31",
		"seller": {
			"@type": "Organization",
			"name": "Votre Boutique"
		},
		"shippingDetails": {
			"@type": "OfferShippingDetails",
			"shippingRate": {
				"@type": "MonetaryAmount",
				"value": "4.99",
				"currency": "EUR"
			},
			"deliveryTime": {
				"@type": "ShippingDeliveryTime",
				"handlingTime": {
					"@type": "QuantitativeValue",
					"minValue": 0,
					"maxValue": 1,
					"unitCode": "DAY"
				},
				"transitTime": {
					"@type": "QuantitativeValue",
					"minValue": 2,
					"maxValue": 5,
					"unitCode": "DAY"
				}
			},
			"shippingDestination": {
				"@type": "DefinedRegion",
				"addressCountry": "FR"
			}
		},
		"hasMerchantReturnPolicy": {
			"@type": "MerchantReturnPolicy",
			"returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
			"merchantReturnDays": 30,
			"returnMethod": "https://schema.org/ReturnByMail"
		}
	}
}

C'est plus verbeux que ce à quoi vous êtes habitués. Mais c'est ce niveau de détail qui sépare les sites qui obtiennent les rich results marchands de ceux qui attendent indéfiniment dans le rapport d'éligibilité de la Search Console. Et rappelons-le, un contenu e-commerce riche et détaillé, c'est d'abord un contenu utile au sens de Google.

• How To Add Merchant Listing Structured Data
• Intro to Product Structured Data on Google
• Product Variant Structured Data (ProductGroup, Product)
• E-commerce Schema Markup: Complete Guide and Examples 2026