Schema Product E-commerce 2026 : la Stack JSON-LD Minimale

La plupart des fiches produit que j’audite ont le même défaut : trop de schemas, pas assez de signal. Un Product, un Review, un FAQPage collé à la FAQ du menu, un HowTo importé d’un template, un BreadcrumbList en double. Résultat côté Search Console : Merchant listings avec warnings, Product snippets invalides, AggregateRating fantôme.

La question en 2026 n’est pas combien de propriétés on empile. C’est lesquelles Google lit vraiment, lesquelles les LLMs parsent, et lesquelles sont vérifiables dans le DOM visible. Selon Aleyda Solis (State of Ecommerce SEO 2025), 18 % des sites e-commerce ne sont toujours pas intégrés à Google Merchant Center. Et chez ceux qui le sont, l’incohérence entre le feed et le JSON-LD du site reste une cause majeure de disqualification.

Le code qui suit, c’est la stack Product + Offer + AggregateRating qu’on pose chez nos clients : ça passe les validateurs, ça colle au feed Merchant Center, et ça se fait lire par ChatGPT Search, Perplexity et Google AI Overviews.

Pourquoi la stack Schema minimale bat la stack maximaliste en 2026

La stack qui déclenche rich results et citations LLM tient en 8 propriétés Product, 5 propriétés Offer et un AggregateRating vérifiable. Empiler FAQPage, HowTo générique et BreadcrumbList dupliqué n’apporte ni CTR ni bénéfice LLM. Pire : ça augmente le risque de structured data manual action dès qu’un validateur détecte un mismatch.

La règle Google qui tranche vient des General Structured Data Guidelines, mise à jour le 2026-01-06 :

“Don’t mark up content that is not visible to readers of the page. Don’t mark up irrelevant or misleading content, such as fake reviews or content unrelated to the focus of a page.”

Si le DOM visible ne confirme pas le markup, la page perd son éligibilité rich result. Les manual actions structured data ne touchent pas le ranking web classique, mais elles coupent 100 % de l’affichage enrichi. Sur une fiche produit qui vit du CTR SERP, c’est sanglant.

Les mauvais réflexes qu’on voit constamment :

• Empiler FAQPage sur chaque page produit avec les mêmes questions copiées-collées. Trigger anti-spam quasi garanti.
• Dupliquer BreadcrumbList parce que le thème le génère et qu’une app (Judge.me, Yoast, peu importe) en ajoute un deuxième
• Injecter un AggregateRating orphelin avec ratingValue 4.8 alors qu’aucune review scrollable n’existe à côté
• Déclarer un HowTo sur une fiche produit qui n’a aucune instruction étape par étape visible à l’œil nu

Le principe : côté feed Merchant Center, on complète avec les flux produit, et côté site on garde inline ce qui est réellement visible à l’écran. Moins, mais crédible.

Les 8 propriétés obligatoires pour Product en 2026

Les 8 propriétés minimales d’un Product JSON-LD conforme 2026 : name, image, description, brand, au moins un identifiant parmi (gtin, mpn, sku), offers, aggregateRating (uniquement si reviews réelles), sameAs. Google exige strictement name, image, offers pour être éligible merchant listing. Les autres conditionnent l’éligibilité aux rich results shopping et l’extraction par ChatGPT Search ou Perplexity.

La doc Google Merchant Listing est explicite sur le découpage : name, image, offers sont required ; description, brand.name, gtin/mpn/sku, aggregateRating, review, color, material, pattern, size sont recommended. Sans les recommandés, la plupart des features SERP shopping ne déclenchent tout simplement pas.

Identifiants produit : gtin, mpn, sku

Règle Google : “Use the most specific GTIN that applies”. Ordre de préférence :

1. gtin : Global Trade Item Number (gtin8 / gtin12 / gtin13 / gtin14 selon le packaging). Meilleur matching cross-marchand.
2. mpn : Manufacturer Part Number. Obligatoire pour les marques propres sans GTIN attribué.
3. sku : identifiant interne du marchand. En complément des deux autres, jamais comme remplacement seul.

Les trois ne sont pas mutuellement exclusifs. Sur une fiche Shopify, il est normal d’avoir les trois côte à côte. Pour Apparel, Google recommande fortement size, color, pattern et material pour apparaître correctement dans les expériences Apparel. Attention à un piège classique : gender et ageGroup ne sont pas des propriétés directes de Product. Elles se déclarent via audience : audience.suggestedGender, audience.suggestedMinAge, audience.suggestedMaxAge.

Offer : price, priceCurrency, priceValidUntil, availability, itemCondition

Cinq propriétés Offer à ne pas manquer :

• price : obligatoire. “Merchant listing experiences require a price greater than zero” (Google). Prix à 0, page inéligible, point final.
• priceCurrency : ISO 4217 (EUR, USD…). Requis pour merchant listing, recommandé pour un product snippet simple.
• priceValidUntil : non requis, mais très fortement recommandé sur les promos. Sans date de fin, Google peut considérer le prix comme stale.
• availability : URL schema.org (InStock, OutOfStock, PreOrder). Toute désynchro avec le stock réel génère un warning Search Console.
• itemCondition : NewCondition par défaut. Critique pour les marketplaces et le reconditionné.

Un mot sur les enhancements récents. Google recommande d’utiliser hasCertification plutôt que l’ancienne hasEnergyConsumptionDetails pour déclarer les certifications énergie. Et pour les promos, priceType (sale price) et validForMemberTier (member price, encore marqué recommended/beta) sont mutuellement exclusifs dans une même spécification Offer. Si vous avez une promo publique et un prix membre, il faut deux Offer séparés ou alterner selon la logique business. Jamais combiner les deux dans le même bloc.

Brand en objet, pas en string

L’erreur la plus fréquente qu’on corrige : "brand": "Acme". Ça passe le validateur schema.org pur, mais Google préfère nettement l’objet typé :

"brand": {
  "@type": "Brand",
  "name": "Acme",
  "url": "https://acme.example.com"
}

La forme objet rattache Brand à un site officiel, ce que les LLMs utilisent pour désambiguïser les marques homonymes. Un string brut sans URL, et ChatGPT Search doit deviner de quelle Acme on parle.

sameAs : l’ancrage entité pour les LLMs

Propriété sous-utilisée, gros ROI en 2026. Schema.org : “URL of a reference Web page that unambiguously indicates the item’s identity.” En clair : les URLs externes qui certifient l’identité du produit ou de la marque.

"brand": {
  "@type": "Brand",
  "name": "Acme",
  "sameAs": [
    "https://fr.wikipedia.org/wiki/Acme",
    "https://www.wikidata.org/wiki/Q12345",
    "https://www.linkedin.com/company/acme"
  ]
}

Aleyda Solis résume le sujet : “Schema markup helps AI systems understand your entity”, avec comme requirement explicite pour les marques qui gagnent en AI search : “Organization schema and sameAs links to major profiles”. Sans ancrage sameAs, le produit reste parseable par Google mais opaque pour le layer entité que ChatGPT Search et Perplexity se construisent en parallèle.

AggregateRating en 2026 : les 4 règles anti-spam à respecter

Quatre règles Google s’appliquent en 2026, sourcées dans sd-policies et la doc Review Snippet. Les reviews doivent être visibles dans le DOM côté utilisateur final. Pas d’agrégation cross-site : on n’agrège pas des ratings venant de sites tiers sans autorisation. Pas de self-serving rating pour Organization ou LocalBusiness (uniquement produits, œuvres et services). Les reviews doivent être sourcées directement des utilisateurs, pas curated éditorialement et certainement pas inventées. Violation de l’une des quatre, et c’est la perte d’éligibilité review snippet. Pas de pénalité ranking, mais arrêt sec des étoiles SERP.

Verbatim Google :

“Make sure the review content you mark up are readily available to users from the marked-up page. It must be immediately obvious to users that the page has review content.”

SSR : conséquence pratique de la règle visibilité DOM

La première règle impose que les reviews soient visibles dans le DOM au moment du crawl. En pratique, ça pousse vers un rendu côté serveur ou un HTML initial qui contient déjà les avis. Un widget qui hydrate les reviews après un scroll ou un onclick peut passer complètement sous le radar du crawler. Ce n’est pas une 5e règle en plus, c’est juste la condition pour respecter la première.

Sur une boutique de cosmétique qu’on a auditée en mars, AggregateRating ratingValue 4.9 sur 3 avis affichés en JS après scroll : étoiles disparues en 11 jours après crawl, -14 % de CTR SERP sur les fiches concernées. Le fix tenait en une ligne de template Liquid : rendre les avis dans le HTML initial plutôt qu’après interaction.

Un seuil pratique, pas une règle officielle

Aucun texte Google ne fixe officiellement de minimum de reviews. Schema.org exige seulement ratingValue plus ratingCount ou reviewCount. Mais dans la pratique observée sur plusieurs comptes clients : en dessous de quelques avis réels et datés, Google peut ignorer les étoiles SERP même si le markup est techniquement valide. Les filtres qualité semblent plus sévères sur les AggregateRating anémiques.

Conséquence directe : pas d’AggregateRating sur une fiche à 1 ou 2 avis. Mieux vaut pas d’étoile qu’une étoile fantôme qui saute au premier recrawl.

Review imbriqué : author, datePublished, reviewRating

Un AggregateRating sans Review nested = rating orphelin, chiffre sans preuve. La structure qui passe :

"aggregateRating": {
  "@type": "AggregateRating",
  "ratingValue": "4.6",
  "reviewCount": "127",
  "bestRating": "5",
  "worstRating": "1"
},
"review": [
  {
    "@type": "Review",
    "author": { "@type": "Person", "name": "Claire D." },
    "datePublished": "2026-03-14",
    "reviewRating": {
      "@type": "Rating",
      "ratingValue": "5",
      "bestRating": "5"
    },
    "reviewBody": "Livraison en 48h, produit conforme à la description."
  }
]

Trois champs obligatoires par Review : author (Person ou Organization), datePublished en ISO, reviewRating avec ratingValue. Et un reviewBody visible à l’écran pour fermer la boucle.

Source externe vérifiable vs reviews internes

Widget Trustpilot, Avis Vérifiés, ou reviews internes stockées en base de données ? Les deux marchent, mais sous conditions :

• Reviews internes : persistance HTML obligatoire, auteur et date vérifiables, pas de modération cachée des avis négatifs
• Widget externe : rendu DOM côté serveur, pas d’iframe JavaScript qui charge après

Règle Google : “If the entity that’s being reviewed controls the reviews about itself […] are ineligible for star review feature.” Elle cible surtout les pages About et Service. Pour une fiche Produit c’est plus souple, mais toujours pas d’agrégation cross-site : interdiction de scraper les notes Amazon pour les afficher chez soi. Pour comprendre pourquoi le SEO e-commerce joue par ses propres règles sur ce genre de détails de confiance et d’éligibilité, voir l’article dédié.

Quand ne PAS mettre d’AggregateRating

Les cas où ne pas déclarer d’AggregateRating est la bonne décision :

• Fiche produit neuve sans historique d’avis réel
• Page catégorie (AggregateRating s’applique à un produit unique, pas à un ItemList)
• Homepage de la boutique
• Produit configurable avec des variantes aux notes très différentes
• Pages About / Services où l’entité contrôle ses propres reviews

Un AggregateRating sans reviews visibles dans le DOM, c’est une manual action en attente.

Le code complet : page produit + page catégorie (ItemList)

Sur une page produit, un seul <script type="application/ld+json"> avec Product + Offer + AggregateRating nested dedans. Sur une page catégorie, un ItemList dont chaque item pointe vers une fiche via URL. Pas deux blocs Product sur la même page. Pas de Breadcrumb dupliqué.

JSON-LD Product simple : le code commenté

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Sac à dos urbain Vanguard 20L",
  "image": [
    "https://example.com/img/sac-vanguard-1x1.jpg",
    "https://example.com/img/sac-vanguard-4x3.jpg",
    "https://example.com/img/sac-vanguard-16x9.jpg"
  ],
  "description": "Sac à dos urbain 20 litres en polyester recyclé, compartiment ordinateur 15 pouces, garantie 5 ans.",
  "sku": "VNG-BKP-20-BLK",
  "mpn": "VNG20BLK",
  "gtin13": "3456789012345",
  "brand": {
    "@type": "Brand",
    "name": "Vanguard Gear",
    "url": "https://example.com",
    "sameAs": [
      "https://fr.wikipedia.org/wiki/Vanguard_Gear"
    ]
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/sacs/vanguard-20l",
    "priceCurrency": "EUR",
    "price": "89.00",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "seller": {
      "@type": "Organization",
      "name": "Vanguard Gear"
    }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "127",
    "bestRating": "5",
    "worstRating": "1"
  }
}

Huit propriétés Product, cinq Offer nested, un AggregateRating vérifiable. Le bloc passe Rich Results Test sans warning, à condition que les images soient crawlables et le prix supérieur à 0.

JSON-LD Product avec variantes : ProductGroup

Pour les produits déclinés (tailles, couleurs), Google a rollout ProductGroup depuis février 2024 :

{
  "@context": "https://schema.org/",
  "@type": "ProductGroup",
  "name": "Sac à dos urbain Vanguard 20L",
  "description": "Sac à dos 20 litres en polyester recyclé.",
  "productGroupID": "VNG-BKP-20",
  "variesBy": [
    "https://schema.org/color",
    "https://schema.org/size"
  ],
  "brand": { "@type": "Brand", "name": "Vanguard Gear" },
  "hasVariant": [
    {
      "@type": "Product",
      "sku": "VNG-BKP-20-BLK",
      "color": "Noir",
      "offers": {
        "@type": "Offer",
        "price": "89.00",
        "priceCurrency": "EUR",
        "availability": "https://schema.org/InStock"
      }
    },
    {
      "@type": "Product",
      "sku": "VNG-BKP-20-GRN",
      "color": "Vert forêt",
      "offers": {
        "@type": "Offer",
        "price": "89.00",
        "priceCurrency": "EUR",
        "availability": "https://schema.org/OutOfStock"
      }
    }
  ]
}

Anti-bloat : name, brand et description apparaissent une seule fois dans le parent. Les variants ne répètent que ce qui diffère vraiment (sku, color, offers). variesBy pointe vers les URLs schema.org complètes, pas des strings.

JSON-LD page catégorie : ItemList

Une page catégorie ne doit pas contenir de schema Product. Elle contient un ItemList, rien d’autre :

{
  "@context": "https://schema.org/",
  "@type": "ItemList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "url": "https://example.com/sacs/vanguard-20l"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "url": "https://example.com/sacs/nomad-15l"
    }
  ]
}

Chaque ListItem porte seulement une position et une URL. Les détails (prix, image, nom) restent sur la fiche cible. Ça évite les warnings de duplication et ça garde la fiche comme source unique de vérité.

Validation multi-outils : ce que chaque validateur détecte (et manque)

Un markup valide dans Rich Results Test peut très bien être rejeté par Search Console deux semaines plus tard. Les quatre outils à combiner en 2026 : Rich Results Test pour la structure et l’éligibilité feature, Schema.org Validator pour la conformité spec pure, Search Console Merchant listings / Product snippets pour la réalité post-crawl, et les logs serveur pour confirmer que Googlebot a bien vu le JSON-LD. Les trois premiers ne remplacent pas les logs, même si on aimerait bien.

Cas typique vécu chez un client Shopify en février : Rich Results Test affichait Éligible merchant listing, Schema.org Validator passait au vert, mais Search Console remontait 80 % des pages produit en “Invalid price” deux semaines plus tard. Coupable habituel : un rendu JavaScript qui injecte le prix après hydration, que Googlebot n’a tout simplement pas attendu.

SSR vs client-side : le JSON-LD au premier crawl

Googlebot rend le JavaScript, mais en deux passes : un crawl HTML initial, puis un rendu JS ultérieur. Entre les deux, l’écart peut aller jusqu’à plusieurs jours selon la complexité du rendu (observation terrain, non chiffrée publiquement par Google). Si le JSON-LD est injecté côté client après hydratation, il est absent du premier snapshot d’indexation. Règle 2026 : JSON-LD obligatoire dans le HTML initial. Soit SSR (Next.js, Remix, Hydrogen), soit static generation (Astro, Nuxt static), soit pré-rendu au build.

Aleyda Solis est explicite :

“Something also important is to avoid structured data implementation with CSR JS. Not only reviews, but also descriptions or images end up over-relying on CSR JS, making it challenging for Google to index at scale.”

Par CMS :

• Shopify : éditer theme.liquid ou product.liquid pour injecter le script dans le <head>. Vérifier que les apps rendent bien côté serveur (Judge.me, Stamped, à surveiller). Hydrogen SSR gère nativement.
• WooCommerce : hook wp_head ou filter woocommerce_structured_data_product. À éviter absolument : les plugins qui injectent en footer JS.
• Headless (Next.js, Remix) : next/script avec strategy="beforeInteractive" ou injection directe dans <Head>. Jamais dans un useEffect, c’est la pire option.

Le test qui tranche en 10 secondes :

curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://votre-boutique.com/sacs/vanguard-20l \
  | grep -o 'application/ld+json'

Si grep ne retourne rien, votre JSON-LD n’est pas dans le HTML initial. Prix et stock mettront plusieurs jours à s’indexer correctement. Et d’ici là, Google peut déjà avoir servi l’ancien prix en SERP.

Hiérarchie de lecture : Google, ChatGPT Search, Perplexity

À lire comme hypothèse de travail, pas comme vérité mesurée (aucun des trois moteurs ne publie sa hiérarchie de lecture). Mais sur la base des travaux d’Aleyda Solis et de nos propres tests manuels en prompt, les LLMs ne priorisent clairement pas les mêmes champs que le crawler Google classique. ChatGPT Search semble extraire en priorité name, brand, offers.price, aggregateRating, image et sameAs. Perplexity s’appuie davantage sur description et les champs d’offers. Google AI Overviews ajoute hasMerchantReturnPolicy et shippingDetails sur les requêtes transactionnelles.

Aleyda verbatim dans AI Search Winning Brands : les LLMs retrieve “in chunks”. Conséquence directe : chaque propriété doit être autonome, valide et cohérente avec le HTML visible. Un champ isolé doit pouvoir être cité sans contexte.

Implications concrètes :

• name et brand sont la porte d’entrée. Toujours en forme objet avec url et sameAs renseignés
• sameAs sur Brand et Product reste le levier le plus sous-exploité pour être cité nommément par ChatGPT Search
• description doit inclure les entités et les termes du marché cible (Perplexity est le plus description-dependent des trois)
• hasMerchantReturnPolicy et shippingDetails jouent le rôle de bonus côté Google AI Overviews, surtout sur les requêtes transactionnelles

Pour creuser ce que les LLMs extraient vraiment d’une page produit, l’article complémentaire détaille la priorisation par moteur. Le JSON-LD reste une brique parmi d’autres, voir la stack GEO complète pour être cité par ChatGPT.

Checklist d’implémentation step-by-step

Onze points actionnables avec validation objective. Chaque étape bloque la suivante tant qu’elle n’est pas validée.

1. Audit existant : Rich Results Test sur 5 URLs produit représentatives. Lister les warnings et erreurs.
2. Inventaire identifiants : exporter gtin, mpn et sku pour tous les SKU actifs.
3. Template JSON-LD : un par type de page (fiche simple, variantes, catégorie). Valeurs plausibles testées.
4. Injection côté serveur : theme Liquid pour Shopify, wp_head pour WooCommerce, <Head> natif pour Next.js ou Astro. Jamais de plugin qui injecte en footer JS.
5. Test curl -A Googlebot : application/ld+json apparaît dans le HTML récupéré sans exécuter une ligne de JavaScript.
6. Rich Results Test : zéro erreur. Warnings uniquement s’ils sont justifiés.
7. Schema.org Validator : zéro erreur de syntaxe pure.
8. Staging puis production : pas de déploiement direct en prod sans re-test staging.
9. Monitoring Search Console : 14 jours de surveillance sur les rapports Merchant listings et Product snippets. Pic d’Invalid = rollback immédiat.
10. Alignement feed Merchant Center : gtin, brand, availability et price en priorité. C’est la règle de parité d’Aleyda Solis.
11. Test LLM : prompt ChatGPT Search et Perplexity avec “Peux-tu me citer la fiche produit X sur le site Y ?” Observer si le prix, la brand et la disponibilité ressortent correctement.

Conclusion

Huit propriétés Product, cinq Offer, un AggregateRating vérifiable. Le tout rendu côté serveur et aligné avec votre feed Merchant Center. FAQPage dupliqué, HowTo orphelin, Breadcrumb en double : c’est du bloat qui fait perdre des rich results, pas en gagner.

Sur les 40+ boutiques qu’on a accompagnées ces trois dernières années, celles qui tenaient une stack minimale stable ramassaient les Popular Products et les citations ChatGPT Search. Celles qui empilaient les schemas « au cas où » récoltaient surtout des warnings Search Console et des étoiles qui sautaient au recrawl.

Vous voulez savoir où en est votre boutique sur cette stack ? Le pré-audit est gratuit : audit.vanguard-edge-consulting.com. 100+ points de contrôle. Et ce n’est pas un PDF de 80 pages.

La vidéo explicative

6 min 06