La fiche catalogue présente une variante bleue et une variante rouge, chacune avec son SKU et son offre. Les deux objets JSON-LD reprennent pourtant le même @id depuis le gabarit de la page. Le JSON reste valide et les deux références apparaissent dans le script, mais la description ne conserve plus deux identités de produit distinctes.
Le problème peut survivre à une comparaison des champs : BLUE-S et RED-S sont bien présents, les offres existent et aucun prix n’a disparu. La collision porte sur la relation entre ces faits. Si deux objets déclarent la même identité dans le même graphe, leurs propriétés peuvent contribuer au même nœud ; compter les objets avant traitement masque cette différence.
En pratique, l’identité du produit, celle du groupe et celle de l’offre doivent correspondre aux entités réellement décrites. Sept témoins exécutés avec PyLD distinguent collision entre variantes, fragments légitimes d’un même produit, offre partagée et identifiant relatif. Trente-sept assertions examinent le graphe obtenu hors connexion, sans exécuter le parseur Google ni mesurer un résultat enrichi ou un classement.
Notre accompagnement SEO technique relie cette vérification au catalogue et au rendu réellement servi. La gouvernance des données structurées JSON-LD doit pouvoir expliquer quelle variante porte chaque offre, puis retrouver le générateur qui a attribué son identité, avant de demander un nouveau crawl.
Pour qui : les variantes sont visibles mais leurs identités se confondent
Examiner la fiche au niveau du produit effectivement décrit
Le diagnostic concerne les catalogues qui décrivent plusieurs variantes dans une page ou dans des réponses liées. Une couleur, une taille ou une autre option peut correspondre à un SKU distinct. L’équipe catalogue doit confirmer cette granularité avant le contrôle : plusieurs apparences d’un même objet ne demandent pas nécessairement plusieurs produits, tandis que deux variantes commerciales ne doivent pas être fusionnées par un identifiant de page partagé.
Le symptôme peut apparaître après une refonte de template, l’ajout d’un composant de variantes ou la coexistence de deux générateurs. Le prix et le stock visibles semblent corrects, mais l’export des données structurées mélange les relations. Le coût caché vient des corrections au mauvais endroit : modifier les prix, les canonicals ou les champs PIM alors que le générateur reprend simplement la même identité.
Séparer validité JSON et décision sur les entités
Un parseur JSON vérifie la forme du document, sans savoir si BLUE-S et RED-S représentent deux produits distincts. Une validation de champs peut confirmer leur présence sans reconstruire le graphe. La recette doit donc préciser l’ensemble d’entités attendu et les relations entre produits et offres. Un voyant vert de syntaxe ne permet pas de qualifier ce contrat métier.
Ce diagnostic ne choisit pas la stratégie de variantes du site et ne détermine pas son éligibilité complète à une fonctionnalité Google. Il isole une collision d’identité dans des données fabriquées. La documentation officielle et le contenu visible restent à vérifier pour le modèle réel : groupe, variantes, URL sélectionnable, propriétés disponibles et modalités d’achat doivent correspondre au parcours publié.
Anatomie : l’identité du nœud ne se déduit pas de son emplacement
Deux objets écrits séparément peuvent contribuer au même nœud
La spécification W3C des algorithmes JSON-LD 1.1 décrit la construction d’une représentation indexée des nœuds. Le banc applique un traitement de flattening dans le graphe par défaut. Pour le même identifiant, les propriétés observées contribuent au même nœud, sans adopter une politique métier qui ferait arbitrairement gagner le dernier SKU.
Le cas A attribue le même identifiant à BLUE-S et RED-S, puis observe un produit portant deux valeurs SKU et deux relations vers des offres. Le programme ne choisit pas quel SKU correspond à quelle couleur. Cette question appartient au contrat catalogue. Deux objets sources ont donc produit une identité fusionnée, sans erreur de parsing ni disparition des valeurs individuelles.
Conserver les niveaux produit, groupe et offre
Le produit décrit une variante dans le témoin, tandis que l’offre porte ses conditions fictives. Le groupe, lorsqu’il existe dans le modèle réel, relie les variantes plutôt que de devenir l’identité unique de chacune. Réutiliser son @id pour une variante peut aussi cumuler des types ; le cas D observe ce mélange sans prétendre établir une règle générale de rejet par Google.
La documentation Google sur les variantes de produits distingue les identifiants des variantes et du groupe. Ces exigences de description ne se résument pas au seul champ @id. La correction doit vérifier SKU ou GTIN, relation de groupe et contenu accessible, sans présenter notre test de nœuds comme une validation complète du balisage marchand.
Retrouver le composant qui attribue la même identité
Examiner la règle du générateur avant les valeurs produit
Une règle fondée uniquement sur l’URL de la page peut donner le même identifiant à toutes les variantes qu’elle présente. Une autre collision vient d’un fragment copié dans plusieurs composants. Le diagnostic conserve l’objet catalogue reçu, la règle d’attribution et le JSON-LD produit. Il faut démontrer le premier écart, plutôt que modifier chaque SKU pour compenser une identité calculée au mauvais niveau.
La règle doit rester stable lorsque les produits sont réellement les mêmes et distincte lorsqu’ils représentent des variantes différentes. Générer un nouvel identifiant aléatoire à chaque rendu évite certaines collisions mais détruit la continuité. Le propriétaire catalogue et le développeur définissent ensemble la portée, la stabilité et les conditions de changement, puis les testent sur les cas de regroupement et de séparation attendus.
Collecter toutes les descriptions publiées pour la même page
Le HTML initial peut contenir un premier script, puis un composant JavaScript ajouter ou remplacer une description après hydratation. Un audit qui lit seulement son fichier source ne prouve pas le document reçu. Conservez le HTML initial et le DOM rendu comme deux observations nommées, avec leur version et leur contexte de cache. Le banc hors connexion ne réalise aucune collecte navigateur du catalogue réel.
Le SSR et le rendu HTML partagé peuvent réduire certains décalages sans corriger une règle d’identité erronée. Si deux composants utilisent la même clé de page, ils restent incohérents même dans une seule réponse serveur. Le diagnostic sépare donc collision sémantique et fraîcheur : une purge réussie peut diffuser plus vite un graphe qui décrit encore le mauvais nombre d’entités.
Exercice de décision : sept graphes JSON-LD fabriqués
Le banc utilise PyLD 3.3.0 avec un contexte local explicite et une base fixe. Les valeurs BLUE-S, RED-S et les prix fictifs sous forme de chaînes servent uniquement à reconnaître les nœuds ; le modèle ne contient pas tous les champs d’une offre marchande admissible. Les 37 assertions portent sur le flattening, les propriétés conservées et l’absence de chargement de contexte distant.
| Cas | Descriptions fabriquées | Nœuds obtenus | Lecture du résultat |
|---|---|---|---|
| A | Deux variantes avec le même @id | Un Product, deux Offer | Deux SKU portés par un produit |
| B | Identités de variantes distinctes | Deux Product, deux Offer | Un SKU par produit |
| C | Deux fragments du même produit | Un Product, une Offer | SKU et offre complètent la même entité |
| D | Groupe et variante avec le même @id | Un nœud portant deux types | ProductGroup et Product se mêlent |
| E | Deux produits, même offre à deux prix | Deux Product, une Offer | L’offre conserve deux valeurs de prix |
| F | Deux copies identiques du produit | Un Product, une Offer | Aucun second SKU inventé |
| G | Identifiant relatif et absolu équivalents | Un Product, deux Offer | La résolution de base révèle la collision |
Comparer la cardinalité après traitement
Les cas A et B contiennent chacun deux descriptions de variante et deux offres. Leur différence apparaît dans le nombre de produits obtenu et dans la répartition des SKU. Le seuil du témoin est le contrat fabriqué « deux variantes distinctes donnent deux identités produit ». Il ne s’agit pas d’une norme universelle imposant le même nombre de nœuds à tous les catalogues.
Par exemple, si le catalogue confirme BLUE-S et RED-S comme deux variantes distinctes, le résultat A demande une correction de leur identité. La présence des deux SKU dans le graphe ne suffit pas à l’accepter. Le contrôle doit comparer les entités attendues, les propriétés et les relations, puis conserver les descriptions brutes pour retrouver le composant responsable de cette projection.
Ne pas refuser une répétition légitime d’identité
Paradoxalement, supprimer tous les @id répétés casserait aussi le cas C. Deux fragments décrivent ici le même produit : l’un apporte son SKU, l’autre sa relation vers l’offre. Le résultat réunit correctement ces faits pour le témoin. Le cas F confirme qu’une copie identique ne crée pas automatiquement un second produit ou un SKU supplémentaire dans ce traitement.
La question de recette devient donc : les fragments parlent-ils de la même entité selon le contrat catalogue ? Un contrôle de chaîne dupliquée peut orienter l’enquête, mais son verdict dépend des valeurs et des relations attendues. Cette nuance évite de traiter une modularisation du JSON-LD comme une collision tout en laissant deux variantes différentes partager une identité de page.
Corriger aussi les identités des offres reliées
Deux produits distincts peuvent encore partager une offre incohérente
Le cas E conserve deux produits correctement séparés mais réutilise un identifiant d’offre avec deux prix fictifs. Le graphe obtenu porte une seule Offer contenant les deux valeurs. Réparer seulement les identités Product laisserait donc cette autre collision ouverte. Le contrat doit qualifier l’offre, son vendeur, son marché et ses conditions, sans supposer qu’une variante possède toujours exactement une offre.
Les chaînes 19 et 21 ne sont pas des prix de catalogue validés et n’ont aucune devise dans le témoin. Elles permettent de constater que le programme conserve deux valeurs pour le même nœud. Le projet réel doit vérifier les conditions visibles et les propriétés requises, plutôt que choisir la valeur la plus récente ou la moins chère pour rendre le graphe artificiellement univoque.
Préserver les relations pendant la correction
Changer un identifiant sans mettre à jour ses références peut laisser des offres orphelines ou relier un produit à une ancienne description. La recette compare les nœuds et leurs liens avant/après avec la même version catalogue. Elle doit permettre de suivre BLUE-S jusqu’à l’offre qui lui correspond dans le modèle adopté, sans dépendre de l’ordre des objets dans le script.
Par exemple, une page peut présenter plusieurs vendeurs pour la même variante. Cette situation demande une cardinalité différente du témoin à deux offres séparées. Le responsable catalogue précise le modèle et la source de chaque condition, puis le générateur le traduit. L’unicité d’identité doit protéger le sens commercial, sans supprimer des offres légitimes pour satisfaire un compteur de nœuds.
Distinguer l’URL de navigation et l’identité décrite
Une base résolue peut révéler un doublon caché
Dans le cas G, une identité relative rejoint l’identité absolue après résolution avec la base fixe du banc. Le traitement observe alors un produit portant les deux SKU. Comparer seulement les chaînes brutes laisserait croire à deux identifiants différents. La recette doit conserver l’URL de base et la forme résolue, avec une politique claire pour les domaines et les chemins du catalogue réel.
Une règle de normalisation trop large peut à son tour réunir des objets distincts. Ne mettez pas arbitrairement en minuscules tout un chemin et ne retirez pas un fragment dont le modèle se sert pour distinguer les entités. Le programme utilise une base fabriquée explicite ; il ne vérifie aucune redirection, aucun canonical public ni aucune résolution réseau de l’identité déclarée.
Ne pas réparer le graphe par une nouvelle stratégie de canonical
La navigation vers une variante et sa description structurée sont liées par le modèle, mais ne constituent pas la même décision. Une collision d’@id ne justifie pas à elle seule de créer des URL ou de modifier leurs canonicals. Le propriétaire SEO examine la page qui porte l’intention, le contenu accessible et la sélection de variante avant de changer les signaux d’indexation.
Conservez la distinction entre identité de groupe, identités produit et URL ouvrant l’état pertinent. Une page unique peut demander un modèle différent de plusieurs pages de variante. La documentation Google correspondant au parcours retenu guide ce choix, tandis que le banc prouve seulement le comportement de sept graphes locaux. Aucun gain de crawl, d’impressions ou de conversion n’est mesuré ici.
Servir une version cohérente du générateur et du catalogue
Suivre les caches qui conservent l’ancien graphe
Après correction du générateur, une réponse en cache peut encore porter l’identité commune aux variantes. La revalidation et l’invalidation doivent viser les fragments effectivement publiés, avec une observation du HTML reçu. Les logs rapprochent version du template, version catalogue et contexte de requête. Une purge déclarée réussie ne prouve pas que toutes les pages observées utilisent déjà la projection corrigée.
Le rendu JavaScript doit aussi conserver la même version lorsqu’il enrichit les données. Une hydratation qui ajoute un fragment ancien peut réintroduire la collision après un HTML initial correct. La recette compare ces deux états et nomme les routes utilisées. Les architectures SSR ou statiques n’exemptent pas de ce contrôle, car le défaut dépend de la règle d’identité et de ses copies publiées.
Attribuer la preuve et le retour arrière
Le contrat d’entrée nomme les identités catalogue et leurs relations ; la sortie attendue décrit le graphe admis pour le gabarit. Le responsable du générateur conserve les dépendances et la journalisation de sa version. Le seuil de blocage porte sur une collision démontrée entre entités distinctes du modèle, avec des témoins de répétition légitime pour éviter les faux positifs.
Le runbook prévoit un repli compatible avec le catalogue et les caches encore actifs. Le monitoring suit la cohorte corrigée, ses graphes et les réponses réellement servies ; le rollback ne consiste pas à actualiser le snapshot attendu pour faire disparaître une alerte. Si la collecte est incomplète, la sortie reste à vérifier, avec une responsabilité et une prochaine action explicites.
Erreurs fréquentes : compter les scripts au lieu des entités
Accepter deux objets parce que leurs champs sont présents
Le cas A conserve chaque SKU et chaque offre tout en réunissant les variantes dans un seul produit. Une vérification de présence donne donc une confiance excessive. Le contrôle doit comparer le modèle d’identité après traitement, puis examiner les relations vers les offres. Le nombre de scripts, d’objets sources ou de propriétés ne constitue pas une preuve de séparation des entités.
Le signal faible est une même identité calculée pour de nombreuses variantes d’une page, alors que les SKU changent. Un autre apparaît lorsqu’un seul Product porte des valeurs qui appartiennent à des articles distincts du catalogue. Ces observations demandent une enquête sur le gabarit et ses données ; elles ne permettent pas d’annoncer une sanction, une désindexation ou un comportement précis du parseur Google.
Transformer PyLD en preuve d’éligibilité Google
Le programme local implémente le traitement testé avec PyLD et un contexte inline. Il ne reproduit pas toutes les décisions de Search, du Rich Results Test ou de Merchant Center. Les champs nécessaires à une offre marchande complète ne sont pas réunis dans ces témoins. Présentez le résultat comme une preuve de graphe dans cet environnement, puis faites la validation adaptée au site réel.
Une implémentation conforme et un contenu fidèle peuvent rester sans présentation enrichie. Le suivi Search Console décrit ce que Google rapporte après publication, sans isoler automatiquement la cause d’une variation. La correction doit être évaluée par identité retrouvée, cohérence et couverture de recette avant d’examiner les effets éventuels de trafic. Aucun objectif de classement ne découle des 37 assertions locales.
Plan d’action : attribuer chaque identité avant la prochaine release
Construire les témoins avec catalogue et SEO
Choisissez une famille dont les variantes et les offres peuvent être expliquées par leurs propriétaires. Conservez la projection actuelle, le contenu visible et la règle d’identité. Le développeur reproduit une collision et une répétition légitime, puis compare le graphe attendu au résultat. Le responsable SEO qualifie ensuite les exigences du modèle public, sans demander au programme de décider seul de l’intention commerciale.
La politique de contexte fait aussi partie de la recette : le banc interdit tout chargement distant, tandis que le site réel peut utiliser une configuration différente à qualifier. Conservez les versions du processeur, du contexte et de la base utilisées. Une évolution de dépendance demande de rejouer les témoins avant d’accepter un nouveau résultat comme référence saine.
- Refuser une identité partagée lorsque les propriétés appartiennent à deux variantes réellement distinctes.
- Conserver les fragments complémentaires lorsqu’ils décrivent la même entité selon le contrat catalogue.
- Valider les relations d’offre après chaque changement d’identité produit ou de groupe.
- Observer le HTML initial et le rendu avant d’étendre la correction aux gabarits voisins.
Relier le graphe à la non-régression de la fiche
Le diff de données structurées entre releases organise contrats, collecte et classement des changements. Les sept témoins approfondissent une différence que la présence des champs ne révèle pas : leur réunion sous une même identité. Gardez la forme brute et le graphe traité pour relire cette décision lors d’une modification du générateur.
La lecture des écarts entre offre visible et JSON-LD Product complète le contrôle par prix, stock et parcours. Le seuil de recette vient de votre modèle et de ses conséquences. La QA et la CI doivent conserver des cas positifs et refusés, puis les observations publiques de la cohorte corrigée avant de fermer le dossier.
Conclusion : conserver les variantes après traitement du graphe
Deux descriptions sources ne prouvent pas l’existence de deux identités produit. Le contrôle doit regarder les nœuds et leurs relations après traitement, avec la granularité que le catalogue confirme. Il doit aussi reconnaître les fragments légitimes d’une même entité, afin de ne pas supprimer une modularisation correcte au nom d’une unicité de chaîne trop simple.
Les sept graphes et les 37 assertions distinguent les variantes fusionnées, l’offre à deux prix, les types mêlés et la résolution d’une identité relative. Le contexte reste local, sans appel distant ni test Google exécuté. Cette preuve permet de reproduire un mécanisme ; elle ne valide pas seule une implémentation marchande ou un résultat enrichi.
Avant la prochaine release, attribuez les identités au niveau produit, groupe et offre, puis observez les copies réellement servies. La gouvernance JSON-LD doit relier ces règles aux sources catalogue, au rendu et aux témoins de non-régression, avec un propriétaire capable d’expliquer les collisions refusées.
Dawap vous accompagne en SEO technique pour auditer les générateurs, cadrer leurs identités et vérifier les pages déployées. Nous coordonnons catalogue, développement et acquisition autour d’un graphe qui décrit les entités visibles, avec des preuves et des limites explicites plutôt qu’une promesse de classement.
