Un schéma Product qui passe le Rich Results Test sans erreur n’est pas forcément un schéma correct. L’outil de Google vérifie que la syntaxe est valide et que les propriétés attendues sont présentes ; il ne vérifie jamais que les valeurs qu’il lit correspondent à ce que voit réellement un visiteur sur la page, ni à ce que reçoit Google Merchant Center. C’est cet écart, invisible dans l’outil de test, qui explique la plupart des rich results qui disparaissent sans erreur apparente.
Sommaire
Le contrôle en trois couches que l’outil de test ne fait pas
Une fiche produit Shopify existe, en réalité, sur trois couches distinctes qui devraient toujours raconter la même histoire : le contenu visible par le visiteur (prix affiché, mention « en stock »), le balisage JSON-LD lu par les robots, et le flux envoyé à Google Merchant Center si la boutique y est connectée. Pour une vue d’ensemble des schémas à prioriser avant d’entrer dans cette vérification, notre guide complet des données structurées Shopify pose le cadre général. Le Rich Results Test ne contrôle que la deuxième couche, isolément. Un décalage entre les trois, même syntaxiquement valide sur chaque couche prise séparément, produit une incohérence que Google finit par sanctionner en abaissant la confiance accordée à l’ensemble du flux produit.
Vérifier le balisage existant en cinq minutes
Ouvrez le code source
Sur la fiche produit, clic droit puis « Afficher le code source », pas l’inspecteur qui montre le DOM après modification JavaScript.
Cherchez application/ld+json
Ctrl+F sur cette chaîne exacte : chaque bloc trouvé correspond à un schéma distinct sur la page.
Comparez les trois couches
Le prix et la disponibilité du JSON-LD doivent correspondre exactement à ce qui s’affiche sur la page, et au flux Merchant Center si la boutique l’utilise.
Passez l’URL au Rich Results Test
Confirmez l’absence d’erreur bloquante, puis notez les avertissements sur les champs recommandés absents.
Les erreurs qui passent le test mais cassent le résultat
Trois cas reviennent régulièrement en audit, et aucun ne déclenche d’erreur dans le Rich Results Test parce qu’ils restent syntaxiquement corrects.
Disponibilité figée après une rupture de stock
Le champ availability reste sur « InStock » alors que le produit est épuisé sur la page, parce qu’il a été codé en dur dans le fichier Liquid au lieu d’être lié dynamiquement à la variable de stock réel du produit. Le test de Google valide la syntaxe, pas la véracité de la valeur.
Le deuxième cas touche les boutiques qui installent une application d’avis en plus du schéma natif du thème : les deux génèrent chacun un bloc Product, avec des valeurs parfois différentes (note moyenne calculée différemment, nombre d’avis désynchronisé). Deux blocs valides individuellement, mais contradictoires entre eux, sont pires qu’un seul bloc incomplet. Le troisième cas concerne les prix soumis à une promotion temporaire : le JSON-LD affiche le prix réduit sans jamais définir priceValidUntil, ce qui laisse Google avec un prix potentiellement obsolète une fois la promotion terminée si personne ne repasse sur la fiche pour le retirer.
Corriger dans le thème sans casser le reste
La correction se fait presque toujours dans le fichier de section du produit (main-product.liquid ou équivalent selon le thème). Deux principes réduisent le risque d’erreur : ne jamais dupliquer un bloc déjà généré par le thème (identifier d’abord ce qui existe, cf. l’étape de vérification), et ne jamais coder une valeur en dur pour un champ qui varie dans le temps (prix, disponibilité), toujours la lier à la variable Liquid correspondante du produit.
Dupliquez systématiquement le thème avant toute modification de ce fichier : une erreur de syntaxe JSON dans ce bloc peut invalider l’intégralité du balisage de la page, pas seulement le champ que vous cherchiez à corriger.
Surveiller dans la durée
Une correction ponctuelle ne suffit pas si rien ne surveille sa persistance. Le rapport « Améliorations » de Search Console, consulté mensuellement, signale les erreurs qui réapparaissent après une mise à jour de thème ou de catalogue. C’est aussi la seule façon de détecter une régression introduite par une nouvelle application installée sans lien apparent avec les données structurées, un cas plus fréquent qu’il n’y paraît sur les boutiques qui accumulent les extensions au fil du temps.
Checklist de correction
- Identifiez les blocs dupliquésRecherchez plusieurs occurrences de « @type »: « Product » sur la même page : c’est le signal le plus fréquent d’un conflit thème/application.
- Reliez availability à la variable de stock réelleJamais une valeur codée en dur, toujours une condition sur le stock disponible du produit.
- Ajoutez priceValidUntil sur les promotionsAvec une date de fin claire, pour éviter qu’un prix promotionnel ne persiste dans le balisage après son expiration.
- Comparez les trois couches sur un échantillonPage visible, JSON-LD et flux Merchant Center : un contrôle mensuel sur les meilleures ventes suffit à détecter une dérive avant qu’elle ne s’étende.
Foire aux questions
Le Rich Results Test suffit-il à garantir un balisage correct ?
Non, il vérifie la syntaxe et la présence des champs attendus, pas la véracité des valeurs par rapport au contenu réel de la page ou au flux Merchant Center.
Que faire si le thème et l’application d’avis génèrent chacun un schéma Product ?
Fusionnez en un seul bloc plutôt que de laisser les deux coexister : deux schémas contradictoires sur la même page sont traités comme un signal négatif par Google.
Faut-il vérifier le balisage après chaque mise à jour de thème ?
Oui, une mise à jour de thème peut réintroduire un schéma par défaut qui entre en conflit avec les corrections déjà appliquées. Un contrôle rapide sur une page témoin après chaque mise à jour évite la régression.
Comment savoir si une incohérence entre les trois couches a un impact réel ?
Le rapport Améliorations de Search Console reste l’indicateur le plus fiable dans la durée : une baisse du nombre de pages éligibles à un résultat enrichi, sans erreur explicite, signale souvent ce type d’incohérence.
Conclusion : le test de Google n’est qu’une des trois vérifications nécessaires
Vérifier un schéma Product sur Shopify ne se limite pas à obtenir un résultat vert dans l’outil de test de Google. Le contrôle qui compte vraiment est la cohérence entre ce que voit le visiteur, ce que lit le robot, et ce que reçoit Google Merchant Center : trois couches qui doivent raconter la même histoire, et qu’aucun outil automatique ne compare pour vous.
À propos de l’auteur
Aymeric Maingé
Consultant SEO senior avec plus de 10 ans d’expérience, côté agence et annonceur. J’accompagne des boutiques Shopify et des sites e-commerce sur des problématiques de SEO technique, de performance web, de Core Web Vitals et d’expérience utilisateur. Mon approche croise audit terrain, priorisation métier et recommandations actionnables pour les équipes marketing et IT. Pour un audit de cohérence de vos données structurées, faites appel à un expert SEO Shopify.
À lire aussi
Les autres articles sur le sujet
Product ou ProductGroup pour les variantes Shopify : la règle de Google appliquée à l’architecture d’URL réelle de la plateforme,…
Lire l’article
