La moitié des boutiques en ligne rate ses rich results pour la même raison : elles ne comprennent pas la différence entre Product Snippet et Merchant Listing. Les deux exigent des propriétés différentes, et Google ne pardonne pas les approximations. Voici ce qui fonctionne en 2026.
Product Snippet vs Merchant Listing : deux chemins, deux exigences#
Le Product Snippet affiche des étoiles et un prix dans les résultats de recherche. Il cible les pages éditoriales ou de comparatif. Propriétés requises : name plus au moins un parmi review, aggregateRating ou offers. C'est le format le plus accessible. Un blog qui teste un produit peut l'obtenir.
Le Merchant Listing vise les fiches produit des boutiques. Les exigences sont plus strictes : name, image (minimum 50 000 pixels), offers.price supérieur à zéro et offers.priceCurrency en ISO 4217. Sans ces quatre propriétés, Google ignore le balisage. Point final.
Le piège classique : baliser une fiche produit comme un Product Snippet parce que c'est plus simple. Google détecte l'incohérence et n'affiche rien.
Pour un guide complet sur le balisage Product et Offer, consultez notre article sur les données structurées e-commerce : Product, Offer et Merchant.
Variantes produit : ProductGroup ou rien#
Un t-shirt existe en 5 couleurs et 3 tailles. Chaque combinaison a son prix et son stock. La bonne approche : ProductGroup avec hasVariant pour chaque déclinaison et variesBy pour déclarer les axes de variation (color, size, material, pattern).
Ce que font 90 % des sites : une seule entité Product avec le prix le plus bas. Google ne sait pas quelle variante correspond à quoi. Résultat : pas de rich result, ou pire, un prix affiché qui ne correspond à rien de disponible.
Règle simple : une URL par variante principale, un Product par variante, un ProductGroup qui les relie.
AggregateRating : les règles que personne ne lit#
Deux propriétés obligatoires : ratingValue et soit ratingCount, soit reviewCount. Les deux sont acceptés, mais il en faut au moins un.
La règle qui fait mal : pas d'agrégation multi-sites. Les avis doivent provenir de la page elle-même. Importer les notes d'Amazon ou de Trustpilot dans le balisage d'une fiche produit, c'est une violation. Google supprime les rich snippets quand il détecte cette pratique.
Si vous n'avez pas assez d'avis natifs, ne balisez pas aggregateRating. Mieux vaut pas d'étoiles que des étoiles retirées après une action manuelle.
Le piège salePrice#
salePrice n'existe pas dans schema.org. C'est un fantôme que des dizaines de plugins SEO continuent de générer. Le bon balisage pour un prix promotionnel : price avec la valeur actuelle et priceValidUntil pour indiquer la date de fin de promotion.
Si le prix affiché sur la page ne correspond pas au price dans le JSON-LD, Google supprime le rich result. Pas d'avertissement, pas de délai. Vérifiez la cohérence après chaque changement de prix.
Rupture de stock : temporaire vs définitive#
Rupture temporaire : garder la page en HTTP 200. Déplacer le produit en fin de liste dans la catégorie. Ne jamais faire de redirection 302. Le produit reviendra, l'URL doit rester indexée.
Rupture définitive : redirection 301 vers le produit le plus similaire. Si aucun équivalent n'existe, renvoyer un 410 (Gone). Dans les deux cas, supprimer les liens internes qui pointent vers cette page. Un lien vers un 301 gaspille du crawl budget.
Filtres et facettes : le gouffre d'indexation#
Couleur, taille, prix, marque, note. Chaque combinaison de filtres génère une URL. Un catalogue de 500 produits avec 6 filtres peut créer des dizaines de milliers de pages quasi identiques.
La solution : noindex sur toutes les pages filtrées, ou Disallow dans le robots.txt. Certains SEO préfèrent le noindex parce qu'il permet le crawl sans l'indexation, utile pour la découverte de liens internes. Mais sur un gros catalogue, le Disallow est plus efficace pour préserver le crawl budget.
Ne laissez jamais Google décider seul quelles facettes indexer. Il choisira mal.
JSON-LD inline, pas de markup JavaScript#
Google peut exécuter du JavaScript, mais la fréquence de crawl est réduite pour les pages qui dépendent du rendu JS. Un JSON-LD injecté directement dans le HTML est crawlé et indexé à chaque passage. Un JSON-LD généré par un framework JavaScript côté client peut attendre des semaines avant d'être pris en compte.
Pour un site e-commerce optimisé, le JSON-LD doit être dans le HTML source, pas dans un bundle JS.
Checklist rapide#
- Product Snippet :
name+reviewouaggregateRatingouoffers - Merchant Listing :
name+image(50K px min) +offers.price(supérieur à 0) +offers.priceCurrency(ISO 4217) - Variantes :
ProductGroup+hasVariant+variesBy - Avis :
ratingValue+ratingCountoureviewCount, jamais multi-sites - Prix promo :
price+priceValidUntil, jamaissalePrice - Rupture temporaire : HTTP 200, fin de liste catégorie
- Rupture définitive : 301 vers similaire ou 410
- Facettes :
noindexouDisallow - JSON-LD : inline dans le HTML, pas de rendu JS
- Bonus :
ShippingDetails+ReturnPolicypour se démarquer
