Schéma de commerce

TL;DR — « Schéma de commerce » est mon raccourci pour les types schema.org qui servent à baliser des choses que les internautes peuvent rechercher puis utiliser : des produits à acheter et des emplois auxquels postuler. Il en existe trois : Product (un article en vente), ProductGroup (un groupe de variantes, comme un t-shirt décliné en plusieurs tailles et couleurs) et JobPosting (une offre d’emploi). Ajoutez le bon type et votre page devient éligible à un résultat de recherche plus riche : résultat produit de type Shopping ou fiche Google for Jobs. Cela ne vous fait pas mieux classer, ne garantit ni l’affichage du résultat ni davantage de clics, et ne permet pas non plus d’être cité par une IA. Ce hub vous oriente vers le bon type ; les tableaux complets de propriétés se trouvent dans l’article consacré à chacun.

Que signifie « schéma de commerce » ?

« Schéma de commerce » est un regroupement pratique, pas un type Schema.org ni une fonctionnalité Google unique. Preuve à l’appui de cette affirmation Commerce schema is an editorial grouping rather than a single Schema.org type or Google feature. Portée : This article's taxonomy; Schema.org and Google document individual types and search experiences. Niveau de confiance : élevé · Vérifié : 2026-07-14 Schema.org: Product Google documente séparément les exigences et l’éligibilité du balisage des produits, des fiches marchand et des organisations. Preuve à l’appui de cette affirmation Google documents distinct structured-data requirements for product snippets and merchant listings, and valid markup does not guarantee display. Portée : Google Product structured data and merchant-listing experiences. Niveau de confiance : élevé · Vérifié : 2026-07-14 Google: Product structured data

Quand vous consultez une page qui vend une veste, vous identifiez simplement en la lisant le prix, les couleurs proposées et la mention « en stock ». Un moteur de recherche voit du texte brut et doit deviner. Le balisage Schema est du code qui explicite « ceci est le prix », « ceci est la disponibilité » ou « ceci est l’intitulé du poste », à l’aide d’un vocabulaire commun publié sur schema.org.

« Schéma de commerce » n’est pas un terme officiel. C’est seulement mon terme générique pour les types schema.org qui décrivent des listes commerciales ou transactionnelles : des éléments individuels qu’une personne peut rechercher, filtrer et utiliser :

• Product — un article unique en vente.
• ProductGroup — un parent qui relie les variantes d’un même article (tailles, couleurs), afin que les moteurs comprennent qu’il s’agit d’options du même produit et non de produits sans rapport.
• JobPosting — une offre d’emploi sur une page carrière.

Je regroupe ces trois types parce qu’ils remplissent la même fonction en SEO : vous les ajoutez afin que Google puisse transformer votre liste en résultat de recherche spécialisé. Mais soyons clairs : Google et schema.org ne les classent pas ensemble. J’y reviens dans l’onglet Advanced, car cette précision compte.

Le rôle de ce hub en découle : c’est un aiguillage, pas un guide d’implémentation. Déterminez ci-dessous lequel des trois types correspond à votre page, puis consultez son analyse détaillée (ainsi que les enregistrements voisins Review, MerchantReturnPolicy ou OfferShippingDetails si les avis, les retours ou la livraison sont concernés) pour les véritables tableaux de propriétés.

Pourquoi s’en préoccuper : les résultats enrichis

Le bénéfice potentiel réside dans les résultats enrichis, ces résultats améliorés qui se démarquent dans la recherche :

• 🛍️ un produit avec son prix, une mention « en stock » et des étoiles d’avis ;
• 👕 un produit qui affiche ses options de taille et de couleur ;
• 💼 un emploi qui apparaît dans le bloc Google Jobs avec l’entreprise, le lieu et le salaire.

Ajoutez le schéma correspondant avec tous les détails requis, et votre page devient éligible à ce traitement. Éligible, jamais garantie : Google décide encore s’il l’affiche réellement.

L’erreur la plus fréquente

L’ajout d’un schéma de commerce ne vous fait pas mieux classer. Google l’a dit clairement et à plusieurs reprises. Le schéma rend votre page éligible à un résultat plus riche et aide les moteurs à la comprendre. Ce n’est pas la même chose qu’un meilleur classement — et l’éligibilité n’est pas non plus une garantie : un balisage valide ne promet ni l’affichage du résultat enrichi, ni plus de clics, ni une citation dans une réponse IA. Considérez chacun comme un résultat distinct.

Autre piège pour débutants : ces types ne sont pas interchangeables. Utilisez Product pour un article unique, ProductGroup lorsque cet article possède des variantes, et JobPosting pour un emploi — jamais pour une page qui regroupe plusieurs emplois. Cette dernière règle est plus stricte que beaucoup ne le pensent.

Vous voulez la version complète — leur place dans la hiérarchie schema.org, leurs liens respectifs avec Merchant Center et Google for Jobs, et l’article à lire ensuite ? Passez à l’onglet Advanced.

TL;DR — « Schéma de commerce » est mon regroupement de praticien, pas une catégorie de Google ou de schema.org, pour les types de listes qui permettent d’obtenir des résultats transactionnels enrichis : Product, ProductGroup et JobPosting. Google les sépare en réalité : Product et Variants figurent sous « Shopping », tandis que Job posting apparaît dans la liste générale des guides de fonctionnalités. schema.org ne les unifie pas non plus : Product → ProductGroup est une véritable relation parent-enfant (Thing > Product > ProductGroup), alors que JobPosting relève de la branche Intangible (Thing > Intangible > JobPosting), sans lien avec Product. Seul le cas d’usage SEO les réunit : des listes structurées que Google transforme en traitements spécialisés dans les SERP (fiches marchand, Google for Jobs). Aucun n’est un facteur de classement ; ils apportent une éligibilité, pas un affichage garanti, une hausse du CTR ou une citation par l’IA, qui sont trois résultats distincts et non garantis. L’éligibilité de Review/AggregateRating suit son propre profil, tandis que les retours et la livraison se répartissent entre une politique au niveau Organization et des exceptions au niveau Offer : deux autres contrats vers lesquels ce hub ne fait que vous orienter. Enfin, le risque lié au cycle de vie diffère : un Product périmé perd surtout son éligibilité, mais un JobPosting expiré et non retiré peut déclencher une action manuelle.

D’abord, un cadrage honnête : c’est mon regroupement, pas celui de Google

Cet article regroupe par commodité plusieurs vocabulaires et fonctionnalités de recherche liés. Preuve à l’appui de cette affirmation Commerce schema is an editorial grouping rather than a single Schema.org type or Google feature. Portée : This article's taxonomy; Schema.org and Google document individual types and search experiences. Niveau de confiance : élevé · Vérifié : 2026-07-14 Schema.org: Product Chaque expérience Google possède ses propres propriétés requises et recommandées, et un balisage valide ne garantit pas son affichage. Preuve à l’appui de cette affirmation Google documents distinct structured-data requirements for product snippets and merchant listings, and valid markup does not guarantee display. Portée : Google Product structured data and merchant-listing experiences. Niveau de confiance : élevé · Vérifié : 2026-07-14 Google: Product structured data

Je préfère être transparent dès le départ, car la plupart des contenus qui parlent de schéma « commerce » ou « ecommerce » laissent discrètement entendre que ces types forment une famille officielle. Ce n’est pas le cas.

• La documentation de Google les sépare. Dans la galerie des données structurées, « Job posting » figure dans la liste générale et plate des Feature guides, aux côtés de types sans rapport comme Article, Local business et Organization. À l’inverse, « Product snippet », « Merchant listing » et « Variants » apparaissent sous un sous-titre Shopping distinct. Deux familles documentaires différentes.
• schema.org ne les unifie pas. Sa propre hiérarchie des types possède un groupe « Product, Offer, and AggregateOffer », dans lequel JobPosting n’apparaît dans aucun regroupement de premier niveau.

Pourquoi les placer dans un seul article ? Parce qu’en pratique — dans le travail réel d’un SEO — ils représentent le même genre de problème : un contenu structuré de type liste, que vous balisez pour débloquer une expérience de recherche spécialisée. Ce cas d’usage commun est réel et utile. La taxonomie commune ne l’est pas. Je préfère le dire franchement plutôt que de prétendre que Google a dessiné cette boîte.

Les trois types en un coup d’œil

• Product (schema.org/Product) — un article vendable. Google transforme un balisage Product valide en deux expériences : les extraits de produit (étoiles d’avis et prix sur les pages sans achat) et les fiches marchand (résultats plus complets de type Shopping sur les pages où l’article peut être acheté). Le minimum pour un résultat enrichi est name accompagné d’au moins l’un des champs offers, review ou aggregateRating — mais la voie review/aggregateRating dépend des règles distinctes de Google sur les extraits d’avis (leur propre profil d’éligibilité, y compris la restriction sur les avis auto-promotionnels), et non d’une règle générale selon laquelle « toute page produit peut afficher des étoiles ». Tous les produits ou toutes les pages marchand ne sont pas automatiquement éligibles aux étoiles ; consultez l’analyse du schéma Review.
• ProductGroup (schema.org/ProductGroup) — un parent qui regroupe les variantes d’un même article conceptuel (un t-shirt en plusieurs tailles et couleurs), afin que Google comprenne qu’il s’agit d’options du même produit et non de listes sans rapport. Il relie les variantes avec hasVariant, variesBy et productGroupID. Point crucial : il ne remplace pas Product ; chaque variante reste un Product complet, avec ProductGroup au-dessus.
• JobPosting (schema.org/JobPosting) — une offre d’emploi, balisée afin d’être éligible à l’expérience Google for Jobs (la fiche ou le carrousel d’offres dans la recherche). Les propriétés requises de base sont title, description, datePosted, hiringOrganization et jobLocation (ou applicantLocationRequirements pour un poste entièrement à distance).

Ce hub reste volontairement succinct sur les tableaux de propriétés ; les analyses détaillées se trouvent dans les trois articles enfants indiqués à la fin.

Leur place dans la hiérarchie schema.org

Cette partie est rarement citée correctement, alors qu’elle distingue une supposition d’un fait :

• Product — Thing > Product.
• ProductGroup — Thing > Product > ProductGroup. C’est un véritable sous-type de Product, qui hérite de toutes ses propriétés et ajoute hasVariant, productGroupID et variesBy. « Product ou ProductGroup » n’est donc pas un vrai choix exclusif : ProductGroup est un Product spécialisé, conçu pour les variantes.
• JobPosting — Thing > Intangible > JobPosting. Une branche totalement différente. Sa définition ne fait aucune référence à Product, Offer ou à un autre type commercial.

Conclusion : Product et ProductGroup sont liés taxonomiquement (parent-enfant, vérifiable et citable) ; JobPosting ne l’est pas. Le lien entre les trois est le cas d’usage SEO, pas l’héritage de type. Présentez-le ainsi et vous serez précis.

Product ou ProductGroup : lequel utiliser ?

Règle simple :

• Une configuration achetable → Product seul. Un SKU, un prix, une page où l’achat est possible.
• Un article conceptuel avec plusieurs variantes achetables → ProductGroup autour de ses membres Product. C’est le cas du t-shirt en cinq couleurs. ProductGroup n’est pas lui-même proposé à la vente : ce sont ses membres hasVariant, chacun avec ses propres sku/gtin, prix et disponibilité.

Google documente aussi ProductGroup différemment : il figure sur la page Variants, et non comme guide de fonctionnalité autonome, ce qui confirme que Google le considère comme une extension de Product plutôt que comme un type de résultat enrichi entièrement distinct. Les tableaux complets de propriétés, le piège de l’URL schema.org complète dans variesBy et le rapprochement avec item_group_id de Merchant Center appartiennent à l’analyse ProductGroup.

JobPosting : l’intrus

JobPosting ne partage aucune taxonomie avec Product, mais le problème a la même forme, d’où sa place dans ce hub. Deux particularités le distinguent sur le plan opérationnel :

1. Toujours un emploi par page. Règle de Google : « The JobPosting markup must only be used on pages that contain a single job posting. » Jamais sur une page de liste ou de résultats de recherche. Product et ProductGroup n’ont pas de restriction équivalente ; ProductGroup existe précisément pour gérer plusieurs variantes sur une seule page.
2. Les offres expirées constituent une obligation de conformité, pas un contenu que l’on publie puis oublie. Le risque est détaillé plus bas ; c’est ici que les enjeux divergent le plus de ceux de Product.

Règles communes aux trois types

Même sans taxonomie partagée, ces types obéissent aux consignes générales sur les données structurées de Google. Voici les règles à retenir :

• Les propriétés requises constituent le seuil d’éligibilité. S’il en manque une, la page n’est pas éligible au résultat enrichi. Les propriétés recommandées améliorent la qualité — Google donne précisément l’exemple du salaire dans une offre d’emploi : les utilisateurs préfèrent les offres qui l’indiquent. La même logique de complétude vaut pour Product.
• Éligibilité ≠ affichage garanti. Un balisage valide vous place dans le groupe éligible ; les systèmes de Google décident encore séparément d’afficher ou non l’amélioration.
• Ne balisez que du contenu visible et exact. Pas de balisage invisible, de faux avis ou de données trompeuses : les règles de Google sur le spam et la qualité du contenu s’appliquent aux trois types, auxquelles s’ajoutent les règles propres à chaque fonctionnalité, comme celles de JobPosting.
• JSON-LD est le format recommandé pour les trois, car il est plus facile à maintenir à grande échelle que Microdata ou RDFa en ligne.

Les connexions de chaque type au-delà du balisage sur la page

Leur véritable point commun n’est pas la taxonomie : Google traite les contenus de type liste comme une gamme de produits distincte :

• Product / ProductGroup ↔ Google Merchant Center. Vous pouvez transmettre les données produit via les données structurées de la page, un flux Merchant Center, ou les deux. Google recommande les deux pour maximiser l’éligibilité et les rapproche : ce sont des systèmes séparés, validés séparément, pas une soumission unique. Réussir le Rich Results Test ne signifie pas que votre flux est valide, et inversement. Prix et disponibilité doivent correspondre dans le balisage, le flux et le paiement.
• JobPosting ↔ Google for Jobs. Un balisage JobPosting valide rend une page consacrée à un seul emploi éligible à l’expérience Jobs, une verticale distincte de Shopping.
• Les retours et la livraison se divisent de la même façon, à un niveau plus fin. MerchantReturnPolicy se place généralement au niveau Organization : fenêtre et conditions de retour standard du site. OfferShippingDetails agit au niveau Offer et sert précisément à remplacer la valeur par défaut de l’organisation pour un article donné (produit plus lourd, tarifs différents selon la région). Traitez-les comme deux enregistrements susceptibles de devenir obsolètes indépendamment, pas comme un seul bloc configuré une fois : politique globale et exceptions par offre nécessitent chacune leur entretien. Les règles de priorité complètes figurent dans leurs analyses respectives.
• Les données structurées de la page, un flux Merchant Center et ce que les fonctionnalités de recherche de Google ou une réponse IA affichent réellement sont trois contrats distincts, pas un pipeline unique : un balisage valide ouvre une éligibilité dans le premier, n’alimente pas automatiquement le deuxième et ne garantit rien dans le troisième. Réussir l’un ne prouve pas la parité des autres.

L’asymétrie avec Bing mérite d’être formulée clairement : Bing valide les trois types de façon générique selon la forme schema.org, mais ne publie aucun tableau de propriétés requis ou recommandé ni aucune politique de contenu propre à l’un d’eux, et ne propose pas d’équivalent aux fiches marchand ou à Google for Jobs. Pour ProductGroup, Fabrice Canel de Bing a indiqué en septembre 2024 que ce balisage n’était pas encore utilisé dans les légendes Shopping, même s’il figurait « on their radar ». Même vocabulaire de base, donc, mais seul Google a créé des expériences de résultats enrichis dédiées et documentées par-dessus.

Différences de risque et de cycle de vie

Voici le contraste essentiel, rarement présenté ainsi : les listes périmées nécessitent une hygiène de cycle de vie pour les trois types, mais les enjeux sont très différents.

• Un Product périmé ou en rupture de stock perd surtout son éligibilité au résultat enrichi, ou affiche « sold out »/« out of stock ». Gênant, pas catastrophique.
• Un JobPosting périmé et non retiré relève d’une autre catégorie de risque. Google affirme ne pas autoriser les offres expirées et précise que ne pas expirer ou retirer un emploi clôturé « may result in a manual action ». C’est bien plus grave qu’une simple inéligibilité. Trois moyens acceptés : placer validThrough dans le passé, renvoyer 404/410 ou retirer le balisage.

Même leçon — les listes structurées ont besoin d’un processus de cycle de vie — mais si vous ne créez qu’un pipeline de nettoyage, commencez par les emplois.

Le schéma de commerce aide-t-il le SEO ?

Pas le classement. John Mueller a été direct : « Structured data won’t make your site rank better. » Le schéma ouvre une éligibilité aux résultats enrichis et aux expériences spécialisées et, séparément, aide Google à comprendre vos pages. Confondre « j’ai ajouté un schéma » avec « je vais mieux me classer » est le mythe le plus courant pour les trois types.

Et cela ne concerne pas que le classement. L’éligibilité, l’affichage effectif d’un résultat enrichi, une hausse du CTR et le chiffre d’affaires sont quatre affirmations distinctes : ne les confondez pas. Un balisage valide ne garantit pas l’affichage dans Shopping ou Jobs, ni davantage de clics et — aucun des types de ce hub n’étant un signal documenté de visibilité dans l’IA — ni l’apparition ou la citation dans AI Overviews ou AI Mode. Mesurez chaque résultat séparément ; un déploiement de schéma vaut pour la fonctionnalité de recherche qu’il peut obtenir, pas comme indicateur des autres.

Mon point de vue rejoint celui de Mueller : sachez à quoi sert réellement le schéma avant d’y consacrer du temps de développement. Il est là pour durer — Mueller a aussi dit que Google ne supprimait pas le schéma — mais vous l’implémentez pour obtenir une fonctionnalité de recherche, pas pour progresser dans les résultats, garantir un clic ou influencer une réponse IA.

Où aller ensuite

Ce hub est la carte ; chacun des sujets suivants possède sa propre analyse détaillée :

• Schéma Product — les deux expériences Google (extrait de produit ou fiche marchand), la distinction entre propriétés requises et recommandées, l’énumération availability et la confusion entre flux et balisage. Commencez ici si votre page vend un article.
• Schéma ProductGroup — regroupement des variantes avec hasVariant/variesBy/ productGroupID, modèles monopage ou multipage, piège de l’URL schema.org complète et rapprochement avec item_group_id de Merchant Center. Commencez ici si votre article existe en plusieurs tailles, couleurs ou matières.
• Schéma JobPosting — propriétés requises ou recommandées, postes à distance ou hybrides, règle d’un emploi par page, expiration et changements d’accès à l’API Indexing en 2024–2025 pour les sites d’emploi. Commencez ici pour une page carrière ou un site d’emploi.
• Schéma MerchantReturnPolicy — type imbriqué au niveau des propriétés pour votre politique de retour : ordre de priorité entre balisage et paramètres Merchant Center, et confusion entre applicableCountry et returnPolicyCountry.
• Schéma OfferShippingDetails — propriété associée pour le tarif, la destination et le délai de livraison, et cas où Google l’exige pour les fiches gratuites.
• Schéma Review — profil d’éligibilité distinct derrière la voie review/ aggregateRating vers un résultat Product : avis unique ou agrégés, restriction sur les avis auto-promotionnels et raison pour laquelle toutes les pages produit ne peuvent pas afficher des étoiles. Consultez-le après avoir choisi l’un des trois types afin de savoir si cette page peut réellement afficher des étoiles.

Pour une vue plus large, ce hub dépend du sous-cluster plus général données structurées ; consultez aussi l’article voisin schema markup consacré au vocabulaire, aux formats et au cycle de dépréciation. Le tout appartient au cluster on-page, dans lequel les données structurées côtoient le reste du SEO technique sur la page.

Résumé par l’IA

Version condensée de l’onglet Advanced :

• Définition : « schéma de commerce » est le regroupement de praticien de Patrick — pas une catégorie Google ou schema.org — pour les types de listes schema.org qui permettent des résultats transactionnels enrichis : Product, ProductGroup et JobPosting.
• Pas une famille officielle : la galerie de Google classe Product, Merchant listing et Variants sous « Shopping », et Job posting dans les Feature guides généraux. schema.org regroupe « Product, Offer, and AggregateOffer » et ne place JobPosting dans aucun groupe de premier niveau avec eux.
• Hiérarchie : Product = Thing > Product ; ProductGroup = Thing > Product > ProductGroup (véritable sous-type de Product pour les variantes) ; JobPosting = Thing > Intangible > JobPosting (branche sans rapport). Product et ProductGroup sont parent-enfant ; JobPosting est taxonomiquement séparé.
• Choix du type : une configuration achetable → Product ; un article avec variantes → ProductGroup autour de ses membres Product (ProductGroup n’est pas vendu) ; une offre d’emploi → JobPosting (un emploi par page, jamais une liste).
• Résultats enrichis : Product → extraits de produit et fiches marchand ; ProductGroup → fiches marchand tenant compte des variantes ; JobPosting → Google for Jobs.
• Règles communes : propriétés requises = seuil d’éligibilité ; éligibilité ≠ affichage garanti ; ne baliser que du contenu visible et exact ; JSON-LD recommandé.
• Au-delà du balisage : Product/ProductGroup ↔ Google Merchant Center (systèmes distincts mais rapprochés ; fournissez les deux ; prix et disponibilité doivent correspondre dans le balisage, le flux et le paiement). JobPosting ↔ Google for Jobs. Retours et livraison se divisent aussi : MerchantReturnPolicy se situe généralement au niveau Organization, OfferShippingDetails le remplace au niveau Offer pour les exceptions ; deux enregistrements et deux calendriers d’entretien.
• Les étoiles d’avis suivent un profil distinct : la voie review/ aggregateRating vers un résultat Product dépend des règles d’éligibilité propres aux extraits d’avis de Google, pas d’une éligibilité générale de toutes les pages produit ; consultez l’article sur le schéma Review.
• Bing : valide les trois types génériquement, sans spécification ou politique dédiée ni équivalent aux fiches marchand ou à Jobs ; d’après Fabrice Canel (septembre 2024), n’utilisait pas encore ProductGroup dans ses légendes Shopping.
• Profil de risque : un Product périmé perd surtout son éligibilité ; un JobPosting périmé ou non retiré peut déclencher une action manuelle — expirez-le via validThrough dans le passé, une 404/410 ou la suppression du balisage.
• Effet SEO : pas un facteur de classement (Mueller : « Structured data won’t make your site rank better ») ; le schéma ouvre une éligibilité et aide à la compréhension, mais cela reste distinct de l’affichage, d’une hausse du CTR ou d’une citation dans une réponse IA. Aucun de ces types n’est un signal documenté de visibilité dans l’IA.
• Ce hub oriente, il n’implémente pas : les tableaux complets de propriétés se trouvent dans les analyses Product, ProductGroup, JobPosting, Review, MerchantReturnPolicy et OfferShippingDetails.

Documentation officielle

Documentation de première main sur les trois types de schémas de commerce et les règles qu’ils partagent.

Google — règles communes

• Consignes générales sur les données structurées — principe d’éligibilité et règles de qualité du contenu et de lutte contre le spam applicables aux trois types.
• Galerie des données structurées — source de référence des éléments qui produisent actuellement des résultats enrichis, et illustration de la séparation entre « Shopping » et « Feature guides ».

Google — Product et ProductGroup (« Shopping »)

• Présentation des données structurées Product — séparation entre extrait de produit et fiche marchand, et relation entre données structurées et flux.
• Données structurées d’extrait de produit — propriétés requises et recommandées pour l’expérience d’extrait plus légère.
• Données structurées de fiche marchand — exigences plus strictes des pages où l’achat est possible.
• Données structurées de variante de produit (ProductGroup) — documentation de ProductGroup comme extension de Product.
• Merchant Center — Spécification des données produit — spécification du flux rapproché du balisage de la page.

Google — JobPosting (« Feature guides »)

• Données structurées d’offre d’emploi — propriétés requises et recommandées, règle d’un emploi par page, politiques de contenu et gestion de l’expiration.

Schema.org (taxonomie)

• schema.org/Product · schema.org/ProductGroup · schema.org/JobPosting · présentation de la hiérarchie des types

Bing / Microsoft

• Bing Webmaster Tools — Balisage d’un site avec des données structurées — prise en charge générique de schema.org, sans spécification d’éligibilité par type.

Citations des sources

Déclarations publiques. Lorsque la page expose le texte, le lien profond mène au passage cité.

Documentation Google — principe commun d’éligibilité

• « Specify all required properties listed in the documentation for your specific rich result type. Items that are missing required properties are not eligible for rich results. The more recommended properties that you provide, the higher quality the result is to users. For example: users prefer job postings with explicitly stated salaries than those without… » Accéder à la citation
• « Content in structured data must also follow the additional content guidelines or policies, as documented in the specific feature guide. For example, content in JobPosting structured data must follow the job posting content policies. » Accéder à la citation

Documentation Google — Product et sa relation avec Merchant Center

• « Two markup types exist: Product snippets for non-purchase pages, emphasizing reviews, and Merchant listings for purchase pages, highlighting product details like sizing and shipping. » Accéder à la citation
• « To provide rich product data to Google Search you can add Product structured data to your web pages, upload data feeds with Google Merchant Center and opt into free listings within the Merchant Center console, or both. » Accéder à la citation

Documentation Google — règles propres à JobPosting

• « The JobPosting markup must only be used on pages that contain a single job posting. We don’t allow the use of JobPosting markup in any other page, including pages that do not list any job. » Accéder à la citation
• « We don’t allow expired job postings. Ideally you should remove expired job postings from your website. If you prefer to not remove them, then you need to ensure the validThrough property is populated and in the past. » Accéder à la citation
• « Jobs that are no longer open for applications must be expired in one of the following ways. Failure to take timely action on expired jobs may result in a manual action. » Accéder à la citation

John Mueller, Google — le schéma n’est pas un facteur de classement

• « Structured data won’t make your site rank better. » Et : « It’s fine to use it for other things in schema.org, that won’t cause problems, but you’re unlikely to see any visible change from it in Google Search. » Couverture Rapporté par Search Engine Roundtable à partir des publications Bluesky de Mueller en avril 2025 ; considérez la formulation comme une transcription de source secondaire.
• « In order to be eligible to be shown as a rich result, you need to make sure that the page uses the right structured data and that it complies with the appropriate policies on our side. » Couverture Rapporté par Search Engine Land à partir d’une réponse #AskGoogleWebmasters de 2019.
• « Exactly. Understand that markup types come and go, but a precious few you should hold on to (like title, and meta robots). » Couverture Rapporté par Search Engine Roundtable à partir d’une réponse de novembre 2025 sur Reddit.

Fabrice Canel, Microsoft Bing — au sujet de ProductGroup

• « ProductGroup markup isn’t used in our captions yet, but it’s on our radar. Our team is closely monitoring its adoption. Stay tuned! » Couverture Rapporté par Search Engine Roundtable à partir d’une déclaration publiée sur X en septembre 2024 ; information datée, à revérifier avant de s’y fier.

Le schéma de commerce en un coup d’œil

Comparaison des trois types

À retenir

• « Schéma de commerce » est un regroupement de praticien, pas une catégorie Google ou schema.org : les trois types partagent un cas d’usage SEO, pas une taxonomie.
• Product et ProductGroup sont parent-enfant ; JobPosting appartient à une branche sans rapport.
• Éligibilité ≠ affichage : un balisage valide vous place dans le groupe éligible, puis Google décide encore d’afficher ou non l’amélioration.
• Ce n’est ni un facteur de classement, ni une garantie de CTR, d’affichage ou de citation par l’IA. Le schéma ouvre l’éligibilité aux résultats enrichis et aide à la compréhension. L’affichage réel, les clics et la présence dans une réponse IA sont trois résultats distincts et non garantis.
• L’éligibilité de Review/AggregateRating suit son propre profil. Toutes les pages produit ou marchand ne sont pas automatiquement admissibles aux étoiles ; cette voie dépend des règles distinctes de Google sur les extraits d’avis.
• Retours et livraison se répartissent plus finement. MerchantReturnPolicy se situe généralement au niveau Organization (politique par défaut) ; OfferShippingDetails la remplace au niveau Offer pour les exceptions. Deux enregistrements, deux calendriers d’entretien.
• JSON-LD est le format recommandé par Google pour les trois.
• Le flux Merchant Center et le balisage Product sont des systèmes séparés que Google rapproche : fournissez les deux et maintenez prix et disponibilité cohérents entre balisage, flux et paiement.
• L’entretien des offres d’emploi comporte le plus de risques : expirez les emplois clôturés (validThrough dans le passé, 404/410 ou retrait du balisage), sous peine d’action manuelle.

De quel type de schéma de commerce ai-je besoin ?

Répondez pour la page que vous balisez : vous arriverez au bon type et à la bonne analyse détaillée à lire ensuite.

Erreurs que je rencontre réellement avec les schémas de commerce

Voici des erreurs concrètes commises avec les balisages Product, ProductGroup et JobPosting, et non des hypothèses. Chacune possède une solution.

Placer JobPosting sur une page qui répertorie plusieurs emplois

La règle de Google est explicite : le balisage JobPosting « must only be used on pages that contain a single job posting », et il est interdit sur toute autre page, y compris une page sans emploi. L’ajouter à un index de carrières ou à des résultats de recherche ne vous apporte pas plusieurs résultats Jobs : il rend simplement le balisage non conforme et inéligible.

À faire plutôt : donnez à chaque poste une URL contenant un seul emploi et ne balisez que cette page. La page de liste ou d’index sert à la navigation, pas au schéma JobPosting.

Laisser en ligne une offre clôturée sans l’expirer

Un Product périmé perd surtout son éligibilité ou affiche « out of stock », ce qui est modérément gênant. Un JobPosting périmé appartient à une autre classe de risque : Google n’autorise pas les offres expirées et précise que ne pas expirer ou retirer une offre clôturée « may result in a manual action ». Il s’agit d’une pénalité à l’échelle du site, pas seulement d’un extrait enrichi perdu.

À faire plutôt : dès la clôture du poste, appliquez l’une des trois solutions acceptées par Google : placez validThrough dans le passé, renvoyez une 404/410 sur l’URL ou retirez complètement le balisage JobPosting. Intégrez-le à l’étape de sortie de votre système de recrutement au lieu d’en faire une correction manuelle.

Traiter ProductGroup comme un substitut au balisage de chaque variante

ProductGroup est un parent qui relie les variantes via hasVariant, variesBy et productGroupID, mais il ne remplace pas Product. Chaque variante — chaque combinaison de taille, couleur ou matière — a encore besoin de son propre balisage Product complet avec ses sku/gtin, prix et disponibilité. Publier uniquement le ProductGroup prive les variantes des données dont Google a réellement besoin.

À faire plutôt : balisez chaque variante achetable comme un Product distinct, puis placez l’ensemble dans un ProductGroup qui les référence.

Attendre du schéma de commerce qu’il améliore vos classements

C’est le mythe le plus courant pour les trois types, et Google l’a dit clairement à plusieurs reprises — John Mueller : « Structured data won’t make your site rank better. » Présenter un déploiement de schéma comme un projet de classement crée de mauvaises attentes et peut conduire à négliger d’autres tâches au profit d’un balisage qui n’allait jamais modifier les positions.

À faire plutôt : implémentez le schéma de commerce pour obtenir l’éligibilité à une fonctionnalité précise (fiche marchand ou fiche Jobs), objectif légitime dont la présentation et les clics ont leur propre valeur, et mesurez-le selon cet objectif, pas selon la position.

Laisser diverger le balisage de la page, le flux Merchant Center et le paiement

Les données produit peuvent provenir des données structurées de la page, d’un flux Merchant Center ou des deux. Google rapproche ces systèmes séparés au lieu de considérer l’un comme une copie de l’autre. Réussir le Rich Results Test ne signifie pas que le flux est valide, et inversement. Si le prix ou la disponibilité diffère entre le balisage, le flux et le montant réellement facturé, l’écart nuit à l’éligibilité comme à la confiance des utilisateurs.

À faire plutôt : gardez le prix et la disponibilité identiques sur les trois surfaces et validez séparément le balisage de la page et le flux, au lieu de supposer que l’un couvre l’autre.

Outils pour créer et vérifier les schémas de commerce

Mon validateur de balisage Schema est le premier outil à utiliser après avoir écrit le JSON-LD de l’un des trois types. Collez un bloc Product, ProductGroup ou JobPosting — ou une page complète — et il effectue des contrôles par niveau de gravité selon le vocabulaire schema.org et les exigences de résultats enrichis de Google. Il aide à repérer une propriété requise manquante avant la mise en ligne, quel que soit le type utilisé.

Mon outil de vérification de l’éligibilité aux résultats enrichis répond à la question plus précise qui revient dans ce hub : non pas « ce JSON-LD est-il valide ? », mais « cette page est-elle réellement éligible à un résultat enrichi ? ». Collez du JSON-LD, une page HTML ou récupérez une URL en ligne : l’outil indique les champs requis présents ou absents pour Product (offers/review/aggregateRating) ou JobPosting (title, description, datePosted, hiringOrganization, jobLocation) — exactement le seuil d’éligibilité décrit ici.

Mon outil de contrôle SEO des PDP est conçu précisément pour la fiche produit de ce hub : il examine une page produit en ligne au-delà du schéma, y compris les signaux sur la page associés aux balisages Product/ProductGroup, afin de déterminer si une page avec un SKU ou regroupant plusieurs variantes est correctement configurée.

Une fois ces vérifications réussies, passez la page dans le test des résultats enrichis de Google : c’est l’outil que Google utilise pour déterminer l’éligibilité, donc l’arbitre final avant la mise en ligne pour chacun des trois types de ce hub.

Testez vos connaissances : schéma de commerce

Cinq questions rapides sur les trois types, leurs relations et ce qu’ils font — ou ne font pas. Choisissez une réponse, puis vérifiez-la.

Ressources utiles

Mes contenus sur le balisage Schema

• Schema Markup — mon analyse plus générale du vocabulaire, des formats, de la compréhension des entités et du cycle de dépréciation. Le schéma de commerce n’en est qu’une partie.
• The Beginner’s Guide to Technical SEO — j’y présente le schéma comme du code qui aide les moteurs à comprendre le contenu et alimente les fonctionnalités qui font ressortir une liste.
• Enterprise SEO — ma règle pragmatique, qui s’applique aussi ici : « I’m a fan of schema markup as long as it gets you a search feature. »

Mes présentations

• How Search Works (SlideShare) — ma présentation de l’exploration, du rendu, de l’indexation et du classement ; contexte utile pour situer les données structurées. Mon avertissement habituel s’applique : « This is my understanding of systems… not going to be 100% complete or accurate. »

Autres ressources du secteur

• Google Again Says Structured Data Does Not Make Your Site Rank Better (Search Engine Roundtable) — déclaration de Mueller d’avril 2025 qui démonte le mythe au cœur de ce hub.
• Google Is Not Killing Schema — Markups May Come & Go (Search Engine Roundtable) — l’idée selon laquelle les types de balisage apparaissent et disparaissent, mais que quelques-uns doivent être conservés.
• Bing May Use ProductGroup Markup In The Future (Search Engine Roundtable) — déclaration de Fabrice Canel de septembre 2024 sur l’absence de prise en charge de ProductGroup par Bing.
• Stick to structured data guidelines if you want the rich result (Search Engine Land) — Mueller sur l’éligibilité, qui exige à la fois le bon balisage et le respect des règles.
• Hiérarchie des types schema.org — le vocabulaire lui-même, directement à la source ; consultez le regroupement « Product, Offer, and AggregateOffer » et la place occupée — ou non — par JobPosting.

Journal des modifications