Par l’équipe Limpi. Les faits externes sont distingués des méthodes Limpi et aucune visibilité, position ou citation automatique n’est garantie.
Quand une page représente-t-elle Product ?
Une fiche présentant un produit identifiable est le cas le plus direct. Product doit décrire cette entité réelle, pas un mot-clé ou une catégorie entière simplement parce qu’elle contient plusieurs produits. Une page éditoriale, une catégorie ou un guide d’achat peut nécessiter une autre modélisation. Ajouter Product partout ne transforme pas ces pages en fiches produit.
Product snippet et merchant listing
Google distingue les exigences des product snippets de celles des merchant listings. Un extrait produit peut enrichir un résultat textuel avec des informations comme avis, prix ou disponibilité. Les expériences marchand peuvent utiliser davantage de données commerciales, par exemple livraison et retours selon les cas. Identifiez l’expérience pertinente avant de copier le même objet sur tout le catalogue.
Le rôle de Offer
Offer décrit une offre commerciale associée au produit. Si vous fournissez prix, devise, disponibilité ou URL d’achat, ces valeurs doivent correspondre à ce que l’utilisateur voit. Un prix structuré devenu différent du prix affiché est un problème de qualité, même si le JSON reste syntaxiquement valide. Utilisez idéalement la même source métier pour l’interface et le schema.
Avis et notes
Les propriétés d’avis doivent représenter de vraies informations présentes et conformes aux règles applicables. Ne générez pas de note artificielle pour remplir un champ. Un schema plus court mais exact est préférable à un objet rempli de valeurs inventées. La donnée structurée doit représenter le produit, pas maximiser le nombre de propriétés.
Variantes de produit
Les tailles, couleurs ou autres variantes demandent une modélisation cohérente. Google documente ProductGroup et les relations de variantes pour certains cas. Le choix dépend de la façon dont le site expose les URLs et les options. Une variante avec sa propre URL n’a pas le même fonctionnement qu’un simple sélecteur sur une page unique.
Identifiants et cohérence
SKU, GTIN, marque et autres identifiants doivent décrire le bon produit. Avant d’ajouter des relations complexes, clarifiez les identifiants et les URLs. Une donnée structurée ne répare pas une architecture produit ambiguë. Si deux scripts produisent deux Product contradictoires, le problème vient souvent de sources de données non coordonnées.
Alignement avec le contenu visible
Nom, image, prix, disponibilité et informations importantes doivent rester cohérents entre JSON-LD et page. Les catalogues changent souvent : promotion, rupture, devise ou variante. Il faut donc tester la mise à jour continue, pas seulement le balisage le jour du déploiement. Une donnée correcte aujourd’hui peut devenir fausse demain si le pipeline se désynchronise.
Validation et éligibilité
Le Rich Results Test et Search Console peuvent aider à détecter les propriétés incorrectes ou manquantes pour les expériences prises en charge. Toutes les propriétés recommandées ne sont pas forcément obligatoires. Même lorsqu’une page est éligible, Google ne garantit pas l’apparition d’un résultat enrichi. La priorité reste l’exactitude.
Créer Product ou corriger Product ?
L’implémentation générale consiste à décider si la page représente un produit et quelles propriétés sont fiables. Le dépannage traite une erreur précise de prix, Offer, disponibilité ou identifiant. Ces intentions sont complémentaires mais distinctes. Un guide général doit renvoyer vers le dépannage lorsqu’un problème de validation apparaît.
Questions fréquentes
Toutes les pages e-commerce doivent-elles avoir Product ? Non. Offer est-il toujours nécessaire ? Cela dépend de l’expérience et des données réelles. Product garantit-il un rich result ? Non. Cette page Limpi doit-elle se déclarer Product ? Non, elle explique Product et peut rester WebPage.
Checklist avant déploiement
Choisissez plusieurs produits représentatifs : disponible, indisponible, en promotion, avec variantes et sans variantes. Comparez pour chacun le nom, l’image, le prix, la devise, la disponibilité et les identifiants entre la page et les données structurées. Une validation sur une seule fiche simple peut masquer des erreurs présentes dans les autres états du catalogue. Le test doit couvrir les cas métier qui changent réellement les valeurs du schema.
Sources de données et synchronisation
Lorsque le prix visible vient du catalogue, la disponibilité d’un stock et le JSON-LD d’un autre service, les décalages deviennent probables. Centralisez autant que possible les valeurs utilisées par l’interface et le balisage. Si plusieurs systèmes restent nécessaires, définissez clairement lequel est source de vérité et à quelle fréquence les données sont rafraîchies. Le problème le plus fréquent n’est pas toujours la syntaxe : c’est une information structurée devenue fausse alors que le code reste valide.
Suivi après modifications du catalogue
Les templates e-commerce changent souvent : promotions, nouveaux modes de livraison, variantes, marketplace ou internationalisation. Après une évolution, contrôlez de nouveau les pages structurées et les rapports disponibles dans Search Console. Une propriété autrefois correcte peut devenir inadaptée lorsque le modèle commercial change. La maintenance doit donc suivre le produit réel et non considérer le schema comme un bloc installé une fois pour toutes.
Critère de clôture
Considérez le balisage comme propre lorsque plusieurs états de produit représentatifs restent cohérents entre données visibles et JSON-LD, que les erreurs de validation importantes sont traitées et que les valeurs commerciales se mettent à jour avec la même fiabilité que l’interface. Conservez ces cas de test afin de détecter rapidement une régression lors de la prochaine évolution du catalogue.
Cas des promotions temporaires
Une promotion courte peut rendre faux un balisage qui reste en cache plus longtemps que l’interface. Vérifiez la durée de cache du HTML, du JSON-LD et des données de prix. Lorsque la promotion se termine, le prix structuré doit évoluer avec la page. Le même raisonnement s’applique aux ruptures de stock et aux changements de disponibilité.
Variantes et identifiants
Lorsque plusieurs variantes partagent une même page, vérifiez que les identifiants, SKU et offres ne sont pas mélangés. Une donnée structurée qui combine le prix d’une variante avec l’image ou l’identifiant d’une autre devient incohérente même si chaque propriété est valide isolément. Les tests doivent donc couvrir le changement réel de variante dans l’interface.
Sources officielles
Les règles des moteurs et des fournisseurs de crawlers peuvent évoluer. Les affirmations techniques de cette page sont bornées par les documentations officielles ci-dessous.
Continuer à comprendre votre visibilité
À lire ensuite
Données structurées Corriger Product Choisir un schema.org