Faut-il déployer le markup de politique de retour au niveau organisation plutôt que produit ?

Quelle est la différence entre markup produit et markup organisation ?

Jusqu'ici, pour afficher une politique de retour dans les résultats enrichis, il fallait l'associer à chaque fiche produit individuellement. Le markup MerchantReturnPolicy devait être imbriqué dans chaque Product ou Offer. Pour un catalogue de 10 000 références, ça signifiait dupliquer l'information 10 000 fois.

Avec le markup au niveau organisation, vous déclarez une seule fois votre politique de retour globale sur une page dédiée (type "/politique-de-retour"). Google peut alors appliquer cette information à l'ensemble de vos produits sans que vous ayez à la répéter partout.

Pourquoi Google introduit cette option maintenant ?

La réponse tient en deux mots : scalabilité et cohérence. Les gros sites e-commerce gèrent des catalogues qui évoluent quotidiennement. Maintenir un markup identique sur des milliers de pages produit représente une charge technique non négligeable, surtout quand la politique de retour change — extension de 14 à 30 jours, modifications des frais de retour, etc.

En centralisant l'information, Google facilite la vie aux webmasters tout en s'assurant que les données affichées restent cohérentes. Moins de risques d'incohérences entre pages, moins d'erreurs de déploiement.

Est-ce que ça remplace complètement le markup produit ?

Non. Les deux approches coexistent et sont complémentaires. Si vous avez des produits avec des politiques de retour spécifiques — par exemple des articles personnalisés non reprenables ou des catégories avec des conditions différentes — vous pouvez toujours utiliser le markup au niveau produit pour ces exceptions.

Le markup organisation sert de politique par défaut. Le markup produit l'écrase quand il existe. C'est une logique de cascading similaire au CSS.

• Le markup organisation déclare une politique globale applicable par défaut
• Le markup produit peut surcharger cette politique pour des cas particuliers
• Google priorise toujours le markup le plus spécifique (produit > organisation)
• Les deux peuvent fonctionner simultanément sur un même site
• Cette évolution réduit drastiquement la maintenance pour les catalogues uniformes

Cette simplification cache-t-elle des pièges d'implémentation ?

Le concept est séduisant sur le papier, mais l'exécution technique peut coincer. Première question : où placer exactement ce markup organisation ? Google reste flou sur les prérequis de la page qui héberge le schema. Doit-elle être indexée ? Accessible depuis la home ? Liée depuis chaque fiche produit ?

Deuxième point — et c'est là que ça devient intéressant — comment Google associe-t-il cette politique aux produits si elle n'est pas explicitement liée dans le markup ? On peut supposer qu'il utilise le même domaine ou une détection de l'entité Organisation, mais aucune doc officielle ne le confirme. [A vérifier]

Quelle est la robustesse de l'affichage en résultats enrichis ?

Soyons honnêtes : les rich snippets e-commerce restent volatils et imprévisibles. Même avec un markup parfait validé par le Rich Results Test, rien ne garantit que Google affichera vos infos de retour. La concurrence sur la requête, le CTR historique, la qualité globale du site — tout ça joue.

J'ai vu des sites avec un markup organisation impeccable ne jamais déclencher l'affichage, tandis que d'autres avec du markup produit bancal y arrivaient. La documentation officielle ne fournit aucun seuil de déclenchement clair. Frustrant, mais c'est la réalité du jeu.

Est-ce que tous les e-commerces devraient migrer vers ce système ?

Ça dépend. Si vous avez une politique de retour unique et uniforme sur 95% de votre catalogue, alors oui, le markup organisation simplifie la vie. Moins de code dupliqué, maintenance centralisée, déploiement plus rapide des changements.

Par contre, si votre modèle repose sur des politiques différenciées par catégorie — mode avec 60 jours, électronique 14 jours, produits frais non reprenables — alors le markup produit reste plus adapté. Vous conservez la granularité nécessaire sans créer une usine à gaz au niveau organisation.

Comment implémenter concrètement le markup organisation ?

Créez une page dédiée (type /politique-de-retour) qui détaille clairement vos conditions de retour pour l'humain ET pour Google. Cette page doit être indexable, accessible depuis votre footer ou vos mentions légales.

Intégrez ensuite le schema MerchantReturnPolicy au niveau Organization, pas Product. Voici la structure minimale à respecter : type Organization, name de votre entreprise, url de votre site, puis l'objet MerchantReturnPolicy avec returnPolicyCategory, merchantReturnDays, returnMethod, returnFees.

Validez votre markup avec le Rich Results Test de Google. Vérifiez que toutes les propriétés requises sont présentes et correctement typées. Surveillez ensuite la Search Console pour détecter d'éventuelles erreurs de parsing.

Quels sont les risques à éviter lors de la migration ?

Ne créez pas de conflit entre markup organisation et markup produit. Si les deux coexistent avec des informations contradictoires (30 jours au niveau organisation vs 14 jours sur certains produits), Google peut ignorer les deux ou afficher n'importe quoi.

Évitez aussi de placer le markup organisation sur une page bloquée en robots.txt ou en noindex. Même si Google prétend crawler certains contenus bloqués pour le contexte, autant ne pas tenter le diable. Rendez cette page parfaitement accessible.

Enfin, ne supprimez pas l'ancien markup produit du jour au lendemain. Gardez une période de transition de 2-3 mois où les deux systèmes fonctionnent en parallèle, le temps de valider que Google comprend et affiche correctement la nouvelle structure.

Comment vérifier que le déploiement fonctionne ?

• Valider le markup organisation avec le Rich Results Test de Google
• Vérifier l'indexation de la page politique de retour dans la Search Console
• Surveiller les rapports d'amélioration "Produits" pour détecter erreurs ou warnings
• Tester l'affichage en résultats enrichis sur quelques requêtes produit clés
• Monitorer les impressions et CTR sur 30 jours pour détecter toute variation anormale
• Comparer les taux d'affichage rich snippets avant/après migration