Données structurées pour l'e-commerce : guide Schema.org pour vos fiches produit

Rich snippets avec étoiles, prix et disponibilité dans Google : les données structurées Schema.org qui comptent pour vos fiches produit, les erreurs fréquentes, et ce que PurpleScan valide.

Données structurées pour l'e-commerce : guide Schema.org pour vos fiches produit

Vous avez sûrement déjà vu des résultats Google avec des étoiles, des prix et des labels "En stock" sous le titre. Ce sont des rich snippets, alimentés par des données structurées : du vocabulaire Schema.org embarqué dans le HTML de votre page.

Selon une analyse de Search Engine Journal, les pages avec des rich results voient leur taux de clic augmenter de 20 à 30% par rapport aux liens classiques. Pour un site e-commerce, c'est du chiffre d'affaires qui passe à côté quand vos données structurées sont absentes ou cassées.

Ce que font concrètement les données structurées

Les moteurs de recherche sont bons pour comprendre le texte, mais mauvais pour comprendre le contexte. "49,99", c'est un prix ou une note ? "Bleu", c'est une option de couleur ou un nom de marque ? Les données structurées éliminent l'ambiguïté. Elles disent à Google exactement ce que représente chaque information sur votre page.

Google utilise ces données pour deux choses :

  1. Les rich results : étoiles, prix, badges de disponibilité dans les résultats de recherche
  2. Une meilleure compréhension de votre page pour le classement et la correspondance avec l'intention de recherche

Une fiche produit qui affiche "4,5 étoiles, 230 avis, 49,99 €, En stock" dans les résultats de recherche communique de la confiance et de la disponibilité avant même que l'utilisateur clique. Ce pré-filtrage signifie un trafic de meilleure qualité.

Les 5 types Schema.org indispensables pour vos fiches produit

1. Product

La base. Chaque fiche produit doit avoir un schéma Product.

Propriétés requises (pour les rich results Google) :

  • name : le nom du produit
  • image : au moins une image produit. Google recommande plusieurs images sous différents angles.
  • offers : les informations de prix (voir Offer ci-dessous)

Propriétés recommandées :

  • description, sku, brand (en tant qu'objet Brand)
  • gtin / gtin13 / gtin14 : codes-barres. Google favorise les produits qui ont un GTIN.
  • aggregateRating et review : données d'avis

2. Offer

Imbriqué dans Product, Offer décrit le prix et la disponibilité.

Requis :

  • price : valeur numérique
  • priceCurrency : code ISO 4217 ("USD", "EUR"). L'une des erreurs les plus fréquentes qu'on voit : utiliser "€" au lieu de "EUR".
  • availability : une URL Schema.org comme https://schema.org/InStock, pas juste la chaîne "En stock"

Recommandé :

  • url, priceValidUntil (important pour les prix soldés), itemCondition, seller

3. AggregateRating

AggregateRating alimente les étoiles dans les résultats de recherche.

Requis : ratingValue (note moyenne) et reviewCount ou ratingCount.

Erreur classique : mettre ratingValue à "4.5/5" au lieu de "4.5" avec un bestRating séparé à "5". Google a besoin de valeurs numériques propres.

4. BreadcrumbList

BreadcrumbList indique à Google la hiérarchie de votre site et affiche un fil d'Ariane dans les résultats de recherche au lieu d'URLs brutes.

Pour un site e-commerce, c'est en général : Accueil > Catégorie > Sous-catégorie > Produit. Chaque élément a besoin d'une position (à partir de 1), d'un name et d'un item (URL).

Schéma simple, grosse différence visuelle. Comparez :

  • Sans : www.example.com/products/casque-audio-pro
  • Avec : Example Store › Audio › Casque Audio Pro

5. Organization

Organization va sur votre homepage. Il établit votre marque dans le Knowledge Graph de Google.

Propriétés clés : name, url, logo, sameAs (liens vers vos profils sociaux), contactPoint (service client).

JSON-LD : le format que Google préfère

Il existe trois façons d'ajouter des données structurées : JSON-LD, Microdata et RDFa. Google recommande JSON-LD depuis des années. C'est un bloc <script> autonome qui ne se mélange pas avec votre markup HTML, ce qui le rend plus facile à maintenir.

Un exemple minimal pour un produit :

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Casque Audio Pro",
  "image": "https://example.com/photos/casque.jpg",
  "description": "Casque audio sans fil à réduction de bruit",
  "brand": {
    "@type": "Brand",
    "name": "AudioTech"
  },
  "offers": {
    "@type": "Offer",
    "price": "89.99",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}
</script>

Ce que PurpleScan valide

Avoir des données structurées sur votre page, c'est une chose. Avoir des données structurées correctes, c'en est une autre. La plupart des sites échouent sur le deuxième point.

Validation syntaxique

  • JSON malformé : virgules en trop, clés sans guillemets, guillemets simples. Les navigateurs sont tolérants ; le parser de Google non.
  • @context manquant : sans "@context": "https://schema.org", le bloc entier est inutile.
  • @type invalide : fautes de frappe comme "Products" au lieu de "Product", ou des types inventés.

Vérification des propriétés requises

  • Product sans image : Google exige au moins une image pour les rich results produit. C'est la propriété manquante qu'on voit le plus souvent.
  • Offer sans priceCurrency : des prix sans code devise sont invalides.
  • Offer avec un mauvais format availability : "En stock" au lieu de https://schema.org/InStock.

Correspondance avec le type de page

PurpleScan détecte le type de page (produit, catégorie, homepage, article de blog) via des signaux spécifiques à chaque plateforme. Ensuite il vérifie que les données structurées correspondent :

  • Page produit sans schéma Product ? Warning.
  • Homepage avec un schéma Product ? Suspect.
  • Page catégorie avec un seul Product au lieu d'un ItemList ? Opportunité ratée.

Implémentation par plateforme

Shopify

Les thèmes Shopify incluent des données structurées de base par défaut, mais elles sont souvent incomplètes. Le thème Dawn produit Product et Offer mais oublie fréquemment brand, sku et aggregateRating. Pour un contrôle complet, éditez le template product.liquid ou product.json, ou utilisez une app comme JSON-LD for SEO.

Magento / Adobe Commerce

Magento 2 a un support intégré des données structurées, mais il est minimal. Le thème Luma produit un markup Product basique. La plupart des boutiques utilisent des extensions pour une couverture Schema.org correcte. Vérifiez que votre extension produit du JSON-LD valide (certaines anciennes extensions utilisent encore Microdata) et inclut toutes les propriétés requises par Google.

PrestaShop

PrestaShop 8 inclut du JSON-LD basique pour les produits. Comme Magento, les valeurs par défaut manquent les propriétés recommandées qui déclenchent les rich results. Des modules comme "SEO Expert" ou "Google Rich Snippets" comblent les lacunes. Vérifiez quand même le résultat. On a vu des modules qui génèrent du JSON-LD syntaxiquement invalide.

WooCommerce

WooCommerce s'appuie sur les plugins SEO WordPress pour les données structurées. Yoast SEO et Rank Math génèrent tous les deux du schéma Product, mais la complétude dépend de votre configuration et de la rigueur avec laquelle vous avez rempli les données produit. Les plugins ne peuvent pas générer du Schema.org à partir de champs vides.

Tests et monitoring

Google propose un test de résultats enrichis pour vérifier des URLs individuelles. Sur un site avec des centaines de fiches produit, ça ne passe pas à l'échelle.

PurpleScan valide les données structurées sur chaque page crawlée. Un JSON-LD cassé sur un template produit signifie en général qu'il est cassé sur toutes les fiches produit qui utilisent ce template. Le détecter sur une page, c'est le détecter sur toutes.

Retour au blog