Les structured data produit JSON-LD en e-commerce sont devenues un standard discret mais déterminant. Sans elles, Google peut indexer vos fiches, mais il les comprend mal : il devine le prix, suppose la disponibilité, ignore les avis. Avec un balisage propre, vous décrivez chaque champ à la machine et vous ouvrez la porte aux rich snippets qui font remonter votre CTR dans les résultats organiques.
Le problème, c'est que la documentation officielle Schema.org tient en plusieurs centaines de pages, et que les guides Google évoluent chaque trimestre. Résultat : la plupart des dirigeants e-commerce héritent d'un balisage incomplet, déployé par défaut par un thème Shopify ou un plugin WooCommerce, et personne ne sait vraiment si ce qui est en place suffit ou pas.
Dans cet article, je réponds aux sept questions qui reviennent le plus souvent lors de mes audits sur ce sujet. L'objectif n'est pas de vous transformer en développeur, mais de vous donner les bons réflexes pour piloter le sujet : ce qui doit être balisé, ce qui ne sert à rien, ce qui peut vous attirer une sanction manuelle Google, et comment vérifier en quelques minutes que votre balisage actuel est correct. Aucune promesse de gain chiffré, aucun « hack » : juste de la méthode et des références aux outils officiels.
Qu'est-ce qu'un balisage JSON-LD et pourquoi Google le privilégie ?
En résumé : un bloc JSON-LD est un dictionnaire que vous donnez à Google pour qu'il comprenne sans ambiguïté ce qui se trouve sur votre fiche produit.
JSON-LD signifie JavaScript Object Notation for Linked Data. Concrètement, il s'agit d'un bloc de code injecté dans le <head> ou en pied de page, qui décrit votre contenu dans un vocabulaire normalisé : Schema.org. Là où le HTML affiche « 49,90 € » à l'écran, le JSON-LD précise à Google qu'il s'agit d'un prix unitaire en euros, TTC, valide jusqu'à telle date, sur un produit nommé X, avec telle disponibilité.
Google a officialisé sa préférence pour JSON-LD dès 2016, dans sa documentation Search Central, au détriment des deux autres formats reconnus : microdata et RDFa. La raison est simple. JSON-LD est isolé du HTML d'affichage, donc plus facile à maintenir, à tester et à modifier sans casser la mise en page. Pour une équipe e-commerce qui change fréquemment de thème ou qui retouche ses templates, c'est un argument décisif.
En e-commerce, l'enjeu va plus loin que la simple compréhension du contenu. Depuis 2023, Google a étendu son onglet « Shopping organique » et son expérience Merchant listings, qui s'appuient quasi exclusivement sur les structured data produit JSON-LD en e-commerce pour faire remonter des fiches sans passer par Google Ads. Une fiche sans balisage complet est aujourd'hui largement invisible dans ces formats. C'est aussi pour cela que les problèmes SEO fréquents en e-commerce incluent quasi systématiquement un volet structured data dans nos audits.
Quelles propriétés Schema.org sont vraiment indispensables sur une fiche produit ?
En résumé : sept propriétés portent l'essentiel de la valeur SEO. Le reste relève du nice-to-have ou du contexte produit.
Le type Schema.org « Product » accepte des dizaines de propriétés. Mais sur une fiche standard, Google attend un noyau dur très restreint. Voici ce que je vérifie en priorité lors d'un audit :
- name : le nom du produit, tel qu'il apparaît dans le H1.
- image : au moins une URL d'image haute résolution, idéalement déclinée en plusieurs ratios (1:1, 4:3, 16:9).
- description : un résumé textuel distinct du nom, et idéalement aligné avec la meta description.
- sku et/ou gtin (EAN, UPC) : identifiants uniques. Le GTIN est de plus en plus poussé par Google pour les produits de marque distribués via plusieurs canaux.
- brand : la marque, sous forme d'objet imbriqué (type Brand, name).
- offers : prix, devise, disponibilité (in stock, out of stock, preorder), URL canonique et date de validité du prix via
priceValidUntil. - aggregateRating et review : si et seulement si vous affichez des avis réels à l'utilisateur sur la même page.
Deux écueils fréquents. Le premier : oublier la propriété priceValidUntil, ce qui fait disparaître le prix du rich snippet au bout de quelques semaines. Le second : baliser un GTIN inexact ou recopié, ce qui peut déclencher un rejet Merchant Center. Sur les catalogues mode et déco, la propriété itemCondition (« NewCondition » par défaut) est aussi attendue.
Tout le reste — couleur, matière, dimensions, audience visée — relève du SEO sémantique avancé. Utile, mais à déployer après le noyau dur, et seulement si votre catalogue le justifie.
Comment Shopify, WooCommerce et PrestaShop gèrent-ils le balisage par défaut ?
En résumé : aucune des trois plateformes ne livre un balisage complet et fiable nativement. Il faut systématiquement compléter et auditer.
Sur Shopify, le thème par défaut (Dawn) inclut un balisage Product de base, généré dans le fichier product.liquid via un objet JSON-LD. La couverture des propriétés varie ensuite d'un thème payant à l'autre. Certains thèmes premium oublient les avis, d'autres oublient le GTIN, d'autres encore génèrent un balisage différent par variante sans gérer correctement le itemGroup. Sur Shopify Plus, il est fréquent d'avoir un balisage cumulé entre un thème personnalisé et une application tierce (Judge.me, Loox, Yotpo pour les avis), ce qui crée des doublons.
Sur WooCommerce, le cœur du plugin ne génère pas de JSON-LD nativement. Il faut passer par un plugin SEO (Yoast, Rank Math, SEOPress) qui prend en charge le balisage produit. Là encore, attention aux doublons : si vous activez le balisage dans Yoast et dans un plugin de gestion d'avis, vous obtenez deux blocs JSON-LD concurrents que Google peut traiter comme une incohérence.
Sur PrestaShop, la situation dépend très largement du thème et de la version. Les versions 1.7 et 8.x ont amélioré le sujet, mais la couverture native reste partielle. Il est très courant d'avoir un balisage qui oublie aggregateRating ou qui injecte les avis dans une structure non conforme.
Quel que soit votre stack, la règle est la même : ne jamais supposer que « parce qu'on est sur Shopify » le balisage est correct. Un test rapide (voir la section dédiée plus bas) suffit à lever le doute. En cas d'audit complet, c'est un point que je traite systématiquement — voir ce que contient l'audit.
Quelles erreurs déclenchent une sanction manuelle pour balisage trompeur ?
En résumé : tout balisage qui décrit une réalité différente de ce que voit l'utilisateur est passible d'une action manuelle Google, et c'est sanctionné durement.
Google publie depuis plusieurs années une catégorie d'actions manuelles dédiée aux « données structurées trompeuses ». Sur Search Console, elle apparaît dans la section « Actions manuelles » ou « Problèmes de balisage structuré ». Les motifs récurrents que je rencontre en audit :
- Avis déclarés en JSON-LD mais invisibles sur la page (notes copiées d'une autre source, ou avis non rendus côté front).
- Prix balisé différent du prix affiché (cas fréquent quand un prix promotionnel s'affiche côté HTML mais que le JSON-LD remonte encore le prix barré).
- Disponibilité « in stock » alors que la fiche affiche « rupture de stock » ou un délai de livraison long.
- Balisage Product posé sur une page catégorie ou sur une page d'accueil : Schema Product doit être posé sur une fiche produit unique.
- Balisage Review avec des avis générés par le marchand pour lui-même, sans rendu côté utilisateur.
La conséquence d'une action manuelle, c'est la perte de tous les rich snippets de la propriété concernée pendant plusieurs mois, parfois plus selon la documentation officielle Google. Sur un catalogue de plusieurs milliers de fiches, l'impact business est immédiat, en particulier sur les requêtes longue traîne où le CTR organique top 3 se situe autour de 18 à 30 % selon les études Backlinko publiées en 2024.
La règle d'or, à répéter à votre équipe technique et à vos prestataires : tout ce qui est balisé doit être visible côté utilisateur sur la même page. C'est non négociable.
Comment vérifier soi-même que son balisage est interprété correctement ?
En résumé : trois outils gratuits suffisent, et chaque vérification prend moins de cinq minutes.
Voici la procédure que je recommande pour un contrôle mensuel, sans dépendre d'une agence :
- Rich Results Test (Google). Tapez l'URL d'une fiche produit dans search.google.com/test/rich-results. L'outil indique le type détecté (Product, Offer, AggregateRating…), les erreurs bloquantes, et les avertissements. C'est la source officielle pour valider l'éligibilité aux rich snippets.
- Schema Markup Validator (Schema.org). Disponible sur validator.schema.org. Plus permissif que l'outil Google, il sert à valider un balisage avancé qui ne déclenche pas forcément de rich snippet (par exemple les propriétés AdditionalProperty pour fiches techniques).
- Search Console — section Améliorations. Dans la section « Améliorations », Google liste les types détectés sur l'ensemble du site, le nombre de pages valides, en avertissement ou en erreur. C'est la vue agrégée la plus utile pour piloter le sujet à l'échelle d'un catalogue.
Pour aller plus loin sur un gros catalogue, un crawler comme Screaming Frog (gratuit jusqu'à 500 URLs) ou Sitebulb / Oncrawl (payants) permet d'extraire les blocs JSON-LD page par page et de croiser les écarts avec votre référentiel produits.
Mon conseil : ouvrir Search Console une fois par mois, vérifier l'évolution du nombre de pages avec balisage Product valide, et investiguer dès qu'une chute brutale apparaît. Un audit ponctuel ne suffit pas, le sujet est vivant : un changement de thème, une mise à jour de plugin avis ou un déploiement de nouvelle gamme peuvent tout casser. Si vous voulez un état des lieux complet, le processus d'audit SEO AuditFacile couvre ce point parmi une trentaine d'autres dimensions techniques.
Quel impact attendre sur le CTR et faut-il baliser les avis ?
En résumé : un rich snippet bien posé améliore le CTR de manière significative, mais l'effet dépend fortement de la requête, du secteur et de la position de départ.
Les études disponibles convergent sur un point : la présence d'étoiles d'avis dans un résultat organique augmente le CTR. Selon les études Backlinko et Sistrix publiées entre 2022 et 2024, l'effet se situe dans une fourchette de l'ordre de 10 à 35 % d'amélioration relative du taux de clics, selon la requête, le secteur et la concurrence sur la SERP. Les chiffres exacts varient : méfiez-vous des promesses trop précises type « +47 % garantis », c'est toujours du marketing.
Ce qui est plus solide, c'est l'effet de ré-équilibrage concurrentiel. Sur une SERP où vos concurrents ont des étoiles et pas vous, vous perdez mécaniquement des clics. À l'inverse, sur une SERP où personne n'a d'étoiles, votre rich snippet vous différencie. L'enjeu n'est donc pas « est-ce que ça fait gagner X % » mais « est-ce que je peux me permettre de ne pas l'avoir si tous mes concurrents l'ont ».
Concernant les avis, deux règles à respecter strictement :
- Ne baliser que les avis collectés directement par votre boutique, ou via une plateforme tierce (Trustpilot, Avis Vérifiés, Judge.me) intégrée et affichée à l'utilisateur sur la fiche.
- Éviter de baliser un AggregateRating basé sur moins de cinq avis : Google peut décider de ne pas afficher l'étoile, et le ratio bénéfice-risque devient mauvais en cas de note basse.
Côté stock, balisez la disponibilité réelle, en temps réel si possible. Côté variantes (taille, couleur), l'usage actuel recommande un balisage ProductGroup avec les variantes en sous-objets — un sujet émergent qu'il vaut mieux traiter une fois le noyau dur en place. Si vous voulez un diagnostic complet sur l'ensemble de votre catalogue, un audit SEO à 49 € couvre ce point et une trentaine d'autres dimensions, paiement unique et satisfait ou remboursé.
En conclusion
Les structured data produit JSON-LD en e-commerce ne sont pas un gadget SEO : elles sont devenues un prérequis pour exister dans les rich snippets, le Shopping organique et, demain, les expériences IA de recherche. C'est aussi un terrain miné : un balisage mal posé peut vous valoir une action manuelle Google qui annule plusieurs mois de travail éditorial.
Trois priorités à actionner cette semaine. D'abord, ouvrez Search Console, section « Améliorations », et notez le nombre de pages Product valides versus en erreur. Ensuite, prenez trois fiches produits emblématiques et passez-les dans le Rich Results Test : c'est le baromètre rapide de la santé de votre balisage. Enfin, vérifiez avec votre équipe technique ou votre prestataire que le prix, la disponibilité et les avis affichés à l'utilisateur correspondent exactement à ce qui est remonté en JSON-LD. C'est la cause numéro un de sanctions manuelles, et c'est aussi la plus facile à corriger une fois identifiée.