Données structurées des fiches produits : ce qu'il faut baliser pour Google Shopping et les réponses IA

Pour qu'une fiche produit soit éligible aux fiches gratuites de Google Shopping et reprise par les moteurs de réponse comme ChatGPT, Perplexity ou l'AI Overview de Google, elle doit exposer ses informations en JSON-LD avec le type Product, un bloc Offer complet (prix, devise, disponibilité) et un identifiant produit unique (GTIN ou MPN). Tout le reste, avis, frais de port, politique de retour, variantes, augmente le nombre de situations où votre page peut être affichée ou citée. Voici la liste exacte de ce qu'il faut baliser, dans quel ordre de priorité, et comment vérifier que ça fonctionne.

Le socle : un balisage Product complet et honnête

Le balisage produit se place dans un script JSON-LD, dans le code source de la page, généré côté serveur de préférence. Il décrit le produit principal de la page, pas la catégorie, pas une sélection de produits associés.

Les propriétés à ne jamais oublier

• name : le nom commercial exact, celui affiché en titre de page. Pas de mention promotionnelle ajoutée.
• image : plusieurs URL absolues, en haute définition, avec au moins un visuel détouré sur fond neutre.
• description : la description réelle du produit, sans balises HTML.
• sku : votre référence interne, identique à celle du flux marchand.
• gtin (EAN, UPC, ISBN selon le cas) ou mpn pour les produits sans code-barres.
• brand : sous forme d'objet Brand avec un name, jamais une simple chaîne vide de sens.

Les propriétés qui creusent l'écart

Elles ne sont pas obligatoires mais elles répondent précisément aux questions que les internautes posent aux assistants : couleur, matière, taille, poids, compatibilité. Pensez à color, material, size, weight, audience, isRelatedTo, et surtout à additionalProperty pour toutes les caractéristiques techniques qui n'ont pas de propriété dédiée (autonomie, puissance, indice de protection, contenance). Une fiche qui déclare vingt caractéristiques structurées a mécaniquement plus de chances d'être retenue par un moteur qui compare deux modèles.

Le bloc Offer : c'est lui qui décide de votre présence dans Shopping

Sans offre valide, pas de résultat enrichi et pas de fiche gratuite. Le bloc offers doit contenir au minimum le prix, la devise en code ISO (EUR), l'URL canonique de la page et la disponibilité (InStock, OutOfStock, PreOrder, BackOrder). Ajoutez ensuite :

• priceValidUntil pour les prix promotionnels datés ;
• itemCondition, indispensable si vous vendez du reconditionné ou de l'occasion ;
• shippingDetails (OfferShippingDetails) : frais de livraison, zone desservie, délais de préparation et de transit ;
• hasMerchantReturnPolicy (MerchantReturnPolicy) : durée du droit de retour, pays concerné, qui paie le renvoi ;
• seller avec le nom légal de la boutique.

La livraison et les retours ne sont pas des détails administratifs. Ce sont exactement les éléments qu'un assistant IA cite quand un utilisateur demande « où acheter ce modèle avec un retour gratuit ». Les déclarer en clair, c'est se rendre citable.

Variantes : utilisez ProductGroup plutôt que dix fiches concurrentes

Un tee-shirt décliné en cinq tailles et trois couleurs ne doit pas générer quinze fiches qui se cannibalisent. Le type ProductGroup regroupe les déclinaisons : il porte un productGroupID, la propriété variesBy (par exemple couleur et taille) et la liste des hasVariant, chaque variante gardant son propre SKU, son GTIN et son offre. Ce modèle évite les doublons et donne aux moteurs une vision claire de votre gamme, ce qui améliore la précision des réponses générées à votre sujet.

Avis et notes : puissants, mais très encadrés

Le bloc aggregateRating (note moyenne, nombre d'avis) et les blocs review individuels enrichissent visuellement les résultats. Trois règles : les avis balisés doivent être visibles sur la page, ils doivent provenir de clients et non de l'éditeur du site, et la note déclarée doit correspondre au calcul affiché. Un balisage d'avis auto-attribués expose à une action manuelle dans la Search Console, avec perte de tous les résultats enrichis du domaine. En cas de doute, ne balisez rien.

Ce que les moteurs IA lisent en plus du balisage

Les données structurées donnent un cadre lisible, mais un modèle de langage exploite aussi le texte visible. Trois pratiques augmentent nettement le taux de citation :

• Un tableau ou une liste de caractéristiques rédigée en langage naturel, cohérente avec le JSON-LD.
• Une section questions/réponses balisée en FAQPage sur les points d'usage réels : compatibilité, entretien, dimensions.
• Des phrases factuelles autonomes, du type « ce modèle pèse 1,2 kg et se recharge en USB-C », qu'un moteur peut extraire sans reformuler.

Vérifiez également que votre fichier robots.txt n'interdit pas les robots des moteurs de réponse si vous souhaitez y être visible : un blocage silencieux annule tout le travail de balisage.

Les erreurs qui bloquent l'affichage

• Prix incohérent entre le JSON-LD, la page et le flux Merchant Center. C'est la première cause de suspension d'offres.
• Disponibilité figée sur InStock alors que le produit est épuisé.
• JSON-LD injecté par JavaScript après interaction : il peut ne jamais être vu au moment du rendu.
• GTIN manquant sur un produit de marque, ce qui empêche le rapprochement avec les fiches concurrentes.
• Balisage dupliqué ou deux blocs Product contradictoires sur la même URL.

Contrôler et suivre son balisage

Trois outils suffisent, tous gratuits :

• Le test des résultats enrichis de Google, sur search.google.com/test/rich-results, pour valider une URL au cas par cas.
• Le validateur officiel de schema.org, sur validator.schema.org, pour contrôler la syntaxe des types et propriétés.
• La Google Search Console, rapports « Extraits produits » et « Fiches de marchand », pour suivre les erreurs à l'échelle du catalogue.

Les spécifications complètes sont publiées sur schema.org/Product et dans la documentation Google Search Central. Programmez un contrôle après chaque mise à jour de votre CMS ou de votre thème : une refonte de template supprime souvent un balisage sans prévenir.

Checklist à appliquer sur chaque fiche

• Un seul bloc Product en JSON-LD, généré côté serveur.
• Nom, images, description, SKU, GTIN ou MPN, marque.
• Offre avec prix, devise, URL, disponibilité à jour.
• Frais de livraison et politique de retour déclarés.
• Variantes regroupées en ProductGroup.
• Avis réels uniquement, cohérents avec l'affichage.
• Caractéristiques techniques en additionalProperty et en texte visible.
• Validation dans le test des résultats enrichis avant mise en production.

FAQ

Les données structurées remplacent-elles un flux Merchant Center ?

Non. Le flux reste la source de référence pour Google Shopping, car il permet de gérer précisément les attributs, les catégories et les mises à jour de stock. Les données structurées viennent le compléter : elles permettent à Google de vérifier la cohérence des prix et de la disponibilité sur la page, et elles rendent la fiche exploitable par les moteurs IA qui, eux, n'ont pas accès à votre flux.

Le GTIN est-il obligatoire ?

Il n'est pas obligatoire au sens technique, mais il est déterminant. C'est l'identifiant qui permet de rattacher votre offre à un produit connu et donc de la faire apparaître dans les comparaisons. Pour un produit fabriqué en propre ou fait main, indiquez un MPN et la marque à la place.

Les données structurées améliorent-elles le classement dans Google ?

Elles ne sont pas un facteur de classement direct. Elles conditionnent en revanche l'éligibilité aux résultats enrichis et aux fiches gratuites, ce qui augmente la visibilité et le taux de clic à position égale. C'est un gain de surface d'affichage, pas un gain de position.

Que faire du balisage d'un produit en rupture de stock ?

Gardez la page en ligne et passez simplement la disponibilité sur OutOfStock ou BackOrder. Supprimer la fiche fait perdre l'historique de la page et les liens entrants. Si le produit est définitivement arrêté, redirigez vers le modèle qui le remplace.

JSON-LD ou microdonnées dans le HTML ?

Le JSON-LD est le format recommandé par Google. Il est isolé du code d'affichage, plus facile à maintenir et moins exposé aux erreurs lors des refontes graphiques. N'utilisez jamais les deux en parallèle sur la même page : les informations risquent de se contredire.