Une fiche marketplace affiche souvent un même objet vendu par plusieurs marchands, avec des prix, stocks, délais et politiques distincts. Si le JSON-LD fusionne tout dans un seul « produit », il devient impossible de savoir ce qui décrit l’article lui-même et ce qui dépend d’un vendeur. Une offre épuisée peut faire croire que le produit entier est indisponible ; un prix plancher peut être publié sans expliquer qui le propose ; une page vendeur peut reprendre des avis qui concernent le produit.
Le premier symptôme est une divergence entre le contenu visible et le graphe. Le front choisit une offre après localisation, mais le balisage conserve l’offre par défaut. Le catalogue désactive un marchand, pourtant son prix reste dans le cache. Une variante change de canonical, alors que son identifiant structuré pointe encore vers l’ancienne URL. Ces écarts fragilisent la compréhension des moteurs et compliquent surtout le diagnostic interne.
Une marketplace opérateur doit construire ses données structurées depuis les mêmes sources et les mêmes règles que la page. Contre-intuitivement, ajouter davantage de propriétés n’améliore pas forcément le résultat : une propriété exacte et maintenue vaut mieux qu’un graphe très riche dont le prix, le stock ou le vendeur ne correspondent plus à l’écran.
La méthode ci-dessous distingue Product, Offer, AggregateOffer, vendeur et variantes, puis les relie au canonical, au rendu et au monitoring. Les exigences des expériences Google ne se confondent pas toujours avec toute la latitude de Schema.org : la conception garde donc un modèle métier complet, puis publie le sous-ensemble compatible avec la page et l’expérience visée.
Séparer produit, offre et vendeur
Faire porter l’identité durable par le produit
Le produit regroupe le nom, la marque, les images, la description, les identifiants et les caractéristiques qui ne changent pas selon le marchand. Son identifiant reste stable lorsque le prix ou le stock évolue. Une marketplace évite ainsi de créer un nouveau produit chaque fois qu’un vendeur rejoint la fiche.
Le modèle catalogue doit déjà posséder cette séparation. Si chaque annonce dupliquée transporte sa propre description, sa marque et son GTIN sans rapprochement, le JSON-LD ne peut pas réparer la confusion. Le chantier commence par une identité produit et des règles de matching suffisamment sûres.
Faire porter la proposition commerciale par l’offre
L’offre relie un produit ou une variante à un vendeur, un prix, une devise, une disponibilité, un état, une URL et éventuellement des conditions. Elle possède son propre identifiant. Deux vendeurs proposant le même SKU produisent deux offres, même lorsque leurs prix sont égaux.
Cette granularité permet de désactiver une annonce sans faire disparaître le produit. Elle permet également de dater un prix, de prouver le vendeur choisi et de recalculer l’agrégat. Le support retrouve l’offre exacte au lieu de corriger une fiche globale.
Choisir la page réellement décrite
Réserver Product aux pages centrées sur un produit
Une page catégorie qui liste des dizaines d’articles ne doit pas prétendre être un unique produit. Le graphe principal décrit l’objet central de la page. Pour les résultats produit, Google recommande de se concentrer sur une page de produit ou sur les variantes du même groupe, pas sur une liste hétérogène.
Une fiche canonique multi-vendeurs peut décrire le produit et ses offres. Une page vendeur centrée sur une seule annonce peut décrire la même identité produit avec l’offre de ce vendeur, à condition que le contenu visible soutienne ce choix et que la stratégie d’URL évite les duplications.
Ne pas baliser une expérience inaccessible
Les propriétés doivent être visibles ou vérifiables sur la page. Publier une livraison, une politique de retour ou un prix réservé à une autre locale crée une promesse impossible à contrôler. Le contexte anonyme utilisé pour le graphe doit correspondre au rendu servi aux moteurs.
Si la page dépend d’une connexion ou d’une sélection préalable pour révéler une offre, le contrat précise l’état par défaut. Il ne choisit pas arbitrairement la meilleure donnée disponible dans la base. L’offre balisée doit être réellement achetable depuis l’URL annoncée.
Modéliser plusieurs vendeurs sur un produit
Choisir entre offres détaillées et agrégat
Schema.org prévoit AggregateOffer lorsqu’un produit possède plusieurs offres, par exemple chez différents marchands. L’agrégat résume nombre d’offres, prix bas et prix haut. Il ne remplace pas le modèle interne détaillé : le calcul doit toujours partir des annonces réellement publiables.
Pour certaines expériences de merchant listing, Google exige une Offer puisque le marchand doit être le vendeur de l’article, alors que les product snippets peuvent accepter Offer ou AggregateOffer. Une marketplace doit donc définir l’expérience visée et son rôle commercial avant de choisir la sortie, sans supposer qu’un agrégat ouvre toutes les présentations.
Calculer l’agrégat sur la population visible
Le prix bas n’inclut pas une offre suspendue, expirée, réservée à un segment inaccessible ou sans stock lorsqu’elle n’est plus achetable. Le nombre d’offres suit la même population. Le calcul conserve l’horodatage et la version de filtre afin que le support puisse expliquer un écart.
Cas concret : trois vendeurs proposent un produit, mais l’un ne livre pas le pays de la page et l’autre est en rupture. L’agrégat anonyme ne doit pas annoncer trois offres disponibles. La sélection du front et la sélection du graphe partagent la même politique de territoire et de publication.
Identifier groupes et variantes
Donner un identifiant unique à chaque niveau
La famille, la variante et l’offre ne partagent pas la même clé. Une chaussure modèle X forme un groupe ; sa taille et sa couleur forment une variante ; le vendeur et ses conditions forment une offre. Google documente ProductGroup et demande des identifiants uniques au groupe comme aux variantes.
Le SKU ou le GTIN de variante ne doit pas être recopié sur tout le groupe. Le mapping conserve les identifiants normalisés et leur provenance. Une correction de GTIN ouvre un dossier de rapprochement plutôt que de réécrire silencieusement l’identité publique.
Aligner variante sélectionnée et URL
Si chaque variante possède une URL, son graphe décrit cette variante et son canonical. Si toutes partagent une page, la stratégie de ProductGroup garde une URL canonique commune et une sélection compréhensible. Le front, le routeur et le JSON-LD ne doivent pas adopter trois logiques différentes.
La recette teste une variante disponible, une variante épuisée, une valeur inconnue et un changement de slug. Elle vérifie identité, offre, canonical et lien de retour vers le groupe. Le résultat reste stable après cache et rendu serveur.
Publier prix, devise et validité
Utiliser le prix actif réellement proposé
L’offre porte un prix numérique et une devise ISO adaptée à la page. Lorsque plusieurs règles tarifaires existent, le graphe anonyme n’expose pas un prix membre inaccessible. Il ne mélange pas non plus prix HT B2B et prix TTC grand public. Le contexte de calcul est versionné.
La documentation Google distingue prix actif, prix barré et prix membre via les spécifications appropriées. Le modèle conserve l’historique et la règle, mais ne publie que ce que le contenu visible justifie. Deux prix contradictoires dans Offer et priceSpecification rendent le résultat ambigu.
Traiter échéances et promotions
Une date de validité passée peut rendre une annonce inéligible. Le pipeline doit donc régénérer le graphe lorsqu’une promotion commence ou finit. Il ne compte pas uniquement sur le prochain déploiement éditorial.
Un test avance l’horloge avant, pendant et après la promotion. Il compare le prix visible, le prix structuré et la source. Si le cache conserve l’ancien montant, l’alerte bloque le lot concerné et indique quelle couche doit être invalidée.
Aligner disponibilité et état commercial
Traduire un état métier, pas une quantité brute
Schema.org propose des valeurs comme InStock, OutOfStock, BackOrder, PreOrder ou Discontinued. La marketplace mappe ses états vers cette liste avec une règle explicite. Une quantité physique positive ne signifie pas forcément InStock si les unités sont réservées ou si le vendeur est suspendu.
Le mapping inclut territoire, canal et date. Une offre vendable en France peut rester indisponible ailleurs. L’URL de l’offre doit permettre l’achat dans le contexte décrit ; sinon le graphe publie une promesse que le panier refusera.
Réagir aux changements rapides
Prix et disponibilité évoluent plus vite que le contenu. La génération doit suivre les événements commerciaux ou une réconciliation fréquente. Google recommande de garder ces données à jour et souligne que le rendu JavaScript peut rendre les crawls shopping moins fiables lorsque les valeurs changent rapidement.
Le rendu serveur réduit l’écart, mais ne suffit pas sans invalidation. La balance compare offres publiables, état HTML et état JSON-LD. Une divergence sur une offre à fort trafic déclenche une correction prioritaire ; une anomalie isolée reste traçable dans la même file.
Rattacher chaque offre au bon vendeur
Utiliser une identité vendeur stable
L’offre référence le vendeur responsable avec son identité publique. Le nom affiché n’est pas la clé ; il peut changer. Le back-office conserve identifiant, statut, raison sociale ou marque commerciale selon le modèle, ainsi que la date de validation.
Une suspension retire les offres de la population sans supprimer l’historique produit. Une réactivation recalcule prix, stock et politiques avant publication. Le graphe ne réutilise pas une ancienne offre simplement parce que le vendeur redevient actif.
Ne pas attribuer au vendeur les avis produit
Une note produit décrit l’article ; une note vendeur décrit la qualité de service du marchand. Les fusionner change le sens de la preuve. La page et les données structurées doivent garder les deux référentiels séparés.
Le même principe vaut pour marque et vendeur. Le marchand n’est pas automatiquement la marque du produit. Le mapping prend la marque depuis le catalogue produit et le vendeur depuis l’offre, avec des responsabilités distinctes.
Porter livraison et retours au bon niveau
Référencer la politique globale ou l’exception
Une politique commune peut être décrite au niveau de l’organisation et référencée depuis les offres. Une exception propre à un produit ou un vendeur peut être portée au niveau de l’offre. Recopier la politique entière partout multiplie les risques de divergence.
La source doit connaître zones, frais, délais et conditions. Une marketplace qui ne maîtrise pas ces données ne doit pas inventer un shippingDetails complet pour enrichir le graphe. Elle publie le sous-ensemble vérifié et traite l’enrichissement comme un chantier de données.
Tester le vendeur réellement sélectionné
Si chaque vendeur applique des retours différents, l’offre structurée doit référencer la bonne politique. Le test choisit une annonce, vérifie la promesse visible, la politique et le graphe. Il couvre aussi un changement de vendeur par défaut.
Une offre ne peut pas hériter d’une livraison plus favorable simplement parce qu’elle est la première dans la liste. Le moteur de sélection et le générateur partagent le même identifiant d’offre. La trace permet de retrouver la règle de classement.
Synchroniser graphe, canonical et indexation
Décrire l’objet canonique de la page
Le @id, l’URL de l’offre et le canonical doivent suivre la stratégie de page. Une fiche produit canonique ne doit pas créer un produit différent pour chaque paramètre de tri. Une page vendeur indexable garde une identité propre seulement si elle apporte une réponse et une offre réellement distinctes.
Le gate d’indexation décide d’abord si la page mérite d’être publiée. Le JSON-LD ne transforme pas une facette pauvre en landing. Si la page est retenue hors index, son graphe ne doit pas réintroduire des URLs incohérentes dans le système.
Préparer les changements d’URL
Une migration de taxonomie associe ancien @id, ancienne URL et destination. Le déploiement met à jour redirection, canonical, liens et graphe dans le même lot. Une chaîne où le JSON-LD vise encore l’ancienne page brouille le résultat.
La recette prélève produits stables, fusionnés, divisés et retirés. Elle vérifie que l’identité produit reste cohérente et que les offres se rattachent à la destination correcte. Les cas ambigus sortent de l’automatisation.
Générer un JSON-LD fidèle au HTML
Construire depuis un view model commun
Le template visible et le JSON-LD consomment une représentation déjà arbitrée : produit, variante, offres publiables, vendeur, prix et disponibilité. Ils ne lancent pas deux requêtes ou deux calculs indépendants. Cette architecture élimine une source fréquente de divergence.
Le view model contient les identifiants et la version de règle. Il exclut les offres non publiables avant le rendu. Une empreinte peut relier le graphe au lot de données sans exposer d’information interne.
Préférer le HTML initial pour les données rapides
Pour prix et stock, un JSON-LD présent dans le HTML initial réduit la dépendance au JavaScript et au timing de rendu. Le serveur doit toutefois disposer d’un cache correctement invalidé. Un HTML rapide mais obsolète reste faux.
Le test HTTP extrait le script, parse le JSON et compare ses champs au texte visible. Il contrôle aussi qu’un seul graphe principal décrit le produit. Une duplication par plusieurs composants peut publier des offres contradictoires.
Valider syntaxe, sens et fraîcheur
Ajouter trois niveaux de contrôle
Le premier contrôle valide le JSON et les types. Le deuxième vérifie les règles métier : offre liée à un produit, vendeur actif, devise cohérente, prix présent et disponibilité mappable. Le troisième compare la sortie au HTML et à la source commerciale.
Un validateur de résultats enrichis peut signaler les propriétés critiques pour l’expérience visée, mais il ne connaît pas la vérité du catalogue. Un graphe syntaxiquement valide peut toujours annoncer le mauvais vendeur. La recette combine donc validation externe et assertions internes.
Surveiller les cohortes en production
Le monitoring suit erreurs par type, offres sans vendeur, prix divergents, disponibilité obsolète et pages dont le graphe ne correspond plus au canonical. Les alertes sont segmentées par famille et version de règle.
La revue commence par les écarts à fort impact et les causes répétées. Elle compare les rapports Search Console aux contrôles internes sans confondre avertissement, inéligibilité et erreur métier. Chaque correction possède un owner et une preuve de retour au nominal.
Éviter les erreurs fréquentes
Mettre le prix minimum sans conserver l’offre
Un lowPrice isolé ne dit pas quel vendeur, quel territoire ni quel stock ont produit le montant. L’agrégat doit rester calculable depuis les offres publiables. Le dossier d’audit conserve la population et l’instant de calcul.
Autre erreur : annoncer InStock dès que la quantité physique est positive. La disponibilité commerciale doit intégrer réservation, statut vendeur, canal et règles de vente. Le panier constitue un contre-test utile.
Enrichir le graphe sans enrichir la page
Ajouter livraison, retours, avis ou marque uniquement dans le JSON-LD crée une couche impossible à relire par l’utilisateur. Ces données doivent provenir d’un référentiel maintenu et soutenir une information visible ou vérifiable.
Enfin, corriger une valeur directement dans le template masque la cause catalogue. Le correctif doit remonter à l’offre, au vendeur ou au mapping, puis ajouter un test. Sinon la prochaine régénération écrasera la retouche.
Plan d’action pour une première famille
Fermer le modèle avant le template
L’équipe choisit une famille, identifie produit, variantes, offres et vendeurs, puis nomme les autorités. Elle définit la population publiable, le contexte anonyme, les prix et disponibilités. Elle prépare des fixtures multi-vendeurs, rupture, promotion, suspension et changement de canonical. Ce contrat attribue responsabilités, owner de chaque entrée, dépendances et seuils de blocage.
Le développement crée un view model partagé, génère le JSON-LD serveur et ajoute les trois niveaux de contrôle. Le back-office expose la source et la cause d’un rejet. Aucun override de template ne devient une règle de gestion. La sortie conserve instrumentation, monitoring, traçabilité et rollback du générateur afin que chaque offre puisse être rapprochée de sa source.
Ouvrir un pilote et réconcilier
Le pilote porte une catégorie et quelques vendeurs. La recette compare HTML, graphe, panier et source. Exemple concret : l’équipe peut retenir un seuil local de blocage à 1 % d’offres dont prix ou disponibilité divergent du panier, puis refuser l’extension tant que cet écart subsiste. Le monitoring suit prix, stock, seller et canonical.
L’extension se fait par modèle homogène. Elle garde une revue des offres exclues et un rollback du générateur. Un second seuil porte sur le délai de fraîcheur : si le prix structuré reste ancien pendant 24 heures, alors la famille revient au palier précédent jusqu’à réconciliation. Le go dépend de la capacité du support à expliquer une offre, pas du nombre de propriétés publiées.
- À faire d’abord : séparer identité produit, variante, offre et vendeur.
- À tester ensuite : promotion expirée, vendeur suspendu, rupture et canonical déplacé.
- À différer : toute propriété sans source, owner ou visibilité cohérente.
- À refuser : un prix ou un stock calculé différemment du parcours d’achat.
Guides complémentaires pour le catalogue
Stabiliser identités et attributs
Le catalogue PIM d’une marketplace opérateur aide à définir taxonomie, identifiants et modération. Cette base rend les produits et variantes assez stables pour alimenter le graphe.
Le MVP marketplace permet de borner la première cohorte et d’éprouver offre, vendeur et reprise avant une couverture générale.
Donner les preuves au back-office
Les écrans indispensables du back-office doivent montrer source, état commercial et motif de rejet. Le support corrige ainsi l’objet responsable.
L’ouverture d’une première catégorie fournit les cas réels de multi-vendeurs, stock et livraison nécessaires à la recette.
Conclusion : maintenir une promesse exacte
Le produit porte l’identité durable ; la variante porte les options vendables ; l’offre porte vendeur, prix, stock et conditions. Les fusionner produit un graphe impossible à maintenir dès qu’un second marchand ou une seconde variante rejoint la fiche.
Le choix entre Offer et AggregateOffer dépend de la page, du rôle commercial et de l’expérience visée. Dans tous les cas, le calcul part des offres réellement publiables et reste cohérent avec le contenu, le canonical et le parcours d’achat.
Le view model commun, le rendu serveur, les assertions métier et la réconciliation protègent la fraîcheur. Le pilote doit provoquer promotion expirée, suspension, rupture et migration d’URL avant toute extension.
Pour cadrer ce modèle, son pipeline et son exploitation, notre équipe peut vous accompagner dans votre création de marketplace opérateur, de la première fiche multi-vendeurs au contrôle en production.
