La fiche produit qu'une IA peut recommander

Ce qu'un assistant lit sur une fiche pour recommander un produit, bloc par bloc, avec un exemple de balisage et une checklist en 17 points.

Mis à jour le 9 octobre 2026 · par l'équipe skoup

Ce qu'un assistant cherche sur une fiche

Quand ChatGPT, Gemini ou Perplexity recommandent un produit, ils le décrivent : un prix, une ou deux caractéristiques, une raison de le choisir. Ces informations viennent de quelque part. Si votre fiche ne les donne pas clairement, l'assistant les prend ailleurs, ou recommande un autre produit.

Ce guide passe la fiche produit en revue, bloc par bloc, et se termine par une checklist. Les robots à autoriser et le flux produit sont traités dans le guide ChatGPT Shopping, la démarche d'ensemble dans le guide GEO e-commerce. Les faits sur Google, Shopify et WooCommerce viennent de leur documentation, lue le 9 octobre 2026.

Un point d'abord, pour ne pas surestimer le balisage. Google écrit dans son guide d'optimisation pour l'IA que les données structurées ne sont pas requises pour ses réponses génératives, et qu'il n'existe aucun balisage spécial pour elles. Il recommande en revanche les flux Merchant Center. Le balisage reste utile : il dit le prix et la disponibilité sans ambiguïté, et il rend la fiche éligible aux résultats enrichis. Mais c'est le texte de la page qui est lu en premier.

Le texte de la fiche

Tout est dans le HTML

Faites le test sur une fiche : affichez le code source de la page (Ctrl+U) et cherchez le nom du produit, son prix et une phrase de la description. Ce qui n'y est pas n'est pas lu par la plupart des robots des assistants.

Les pièges les plus fréquents :

des avis clients chargés par un widget après l'affichage de la page ;
un onglet « Caractéristiques » dont le contenu n'arrive qu'au clic ;
un prix de variante calculé par un script ;
une description, un tableau de tailles ou un comparatif publiés en image.

Un nom qui se suffit à lui-même

« Le Classique » ne dit rien en dehors de votre site. « Vélo électrique urbain Le Classique, cadre aluminium » se comprend dans une réponse. Un bon nom de produit tient en quatre éléments : la marque, le type de produit, le modèle, et l'attribut qui distingue la variante (couleur, taille, contenance). Quand la variante change le prix, elle doit figurer dans le nom de la variante.

Les chiffres avec leur condition

Écrire « autonomie de 120 km » est mieux qu'une icône. Écrire « autonomie de 120 km en mode éco, 70 km en mode sport » est mieux encore : un assistant répète souvent un chiffre tel quel, et un chiffre sans sa condition devient une promesse que le produit ne tient pas.

Regroupez les caractéristiques dans un vrai tableau HTML, avec la même unité partout : le poids en kilos sur la fiche, dans le flux et sur les places de marché.

Répondre aux questions d'achat

Les clients ne demandent pas « parle-moi du modèle X ». Ils demandent un produit pour un usage, un budget, une contrainte. Une fiche qui répond à ces questions donne à l'assistant de quoi justifier une recommandation. Ajoutez un court paragraphe pour chacune de celles qui s'appliquent :

Pour qui : l'usage prévu, et aussi à qui le produit ne convient pas. Une limite écrite noir sur blanc rend le reste plus crédible.
Comparé à quoi : ce qui le distingue de votre autre modèle, ou de la catégorie.
Compatibilité : tailles, appareils, pièces, normes.
Entretien et durée de vie : ce qu'il faut faire, ce qui s'use, ce qui est garanti.
Contenu du colis : ce qui est inclus, ce qui ne l'est pas.
Livraison et retour : délais, frais, nombre de jours pour retourner.

Images et avis

Chaque image porte un texte alternatif qui décrit le produit et sa variante : « Vélo Le Classique vert sauge, vue de profil ». Une image par variante, au moins.

Les avis clients sont une source que les assistants citent volontiers (« les acheteurs soulignent… »). Ils ne servent que s'ils sont lisibles dans la page. Et ils ne se balisent que dans ce cas : Google demande que les avis balisés soient « readily available to users from the marked-up page », selon ses règles des extraits d'avis. Jamais d'aggregateRating pour une note qui n'est pas affichée.

Les données structurées

Google précise ce qu'il attend d'une fiche marchande dans sa documentation merchant listings :

requis : name, image et une offre (offers) avec price, supérieur à zéro, et priceCurrency, au format ISO 4217 (EUR) ;
recommandés : un identifiant (gtin, gtin13…, ou mpn), brand, hasMerchantReturnPolicy, shippingDetails, aggregateRating et review.

La disponibilité s'écrit avec une valeur schema.org : InStock, OutOfStock, PreOrder, BackOrder, Discontinued… Un prix barré se déclare à part, avec "priceType": "https://schema.org/StrikethroughPrice" ; le prix actif n'a pas de priceType.

La règle qui prime sur toutes les autres, dans les consignes générales de Google : « Your structured data must be a true representation of the page content. » Le balisage dit ce que la page affiche, ni plus ni moins.

Voici un exemple minimal pour une fiche à un seul produit, livraison et retour compris :

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Vélo électrique urbain Le Classique, vert sauge",
  "image": ["https://www.example.com/images/le-classique-vert.jpg"],
  "description": "Vélo électrique urbain, cadre aluminium, 21 kg, autonomie de 120 km en mode éco.",
  "sku": "CLASSIQUE-VERT-M",
  "gtin13": "3760123456784",
  "brand": { "@type": "Brand", "name": "Example" },
  "offers": {
    "@type": "Offer",
    "url": "https://www.example.com/products/le-classique",
    "price": 2490.0,
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": { "@type": "MonetaryAmount", "value": 0, "currency": "EUR" },
      "shippingDestination": { "@type": "DefinedRegion", "addressCountry": "FR" },
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "handlingTime": {
          "@type": "QuantitativeValue",
          "minValue": 0,
          "maxValue": 1,
          "unitCode": "DAY"
        },
        "transitTime": {
          "@type": "QuantitativeValue",
          "minValue": 2,
          "maxValue": 4,
          "unitCode": "DAY"
        }
      }
    },
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "applicableCountry": "FR",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 30,
      "returnMethod": "https://schema.org/ReturnByMail",
      "returnFees": "https://schema.org/FreeReturn"
    }
  }
}

Livraison et retour peuvent aussi se déclarer une fois pour toute la boutique. Google le prévoit : « consider configuring your shipping settings and return policies in Google Merchant Center », ou à défaut au niveau du compte dans Search Console. Une politique déclarée là n'a pas besoin d'être répétée sur chaque fiche.

Les variantes

Le noir à 2 490 € et le vert à 2 590 € sont deux offres différentes. La documentation de Google sur les variantes de produit (mise à jour le 8 septembre 2026) décrit deux façons de les présenter :

une seule page pour toutes les variantes, avec un paramètre d'URL par variante (?color=vert&size=m) ;
une page par variante, chacune avec un balisage complet.

Dans les deux cas, le balisage regroupe les variantes dans un ProductGroup, avec productGroupID (la référence parente), variesBy (ce qui change : couleur, taille…) et hasVariant (la liste des variantes). Chaque variante a un identifiant unique, sku ou gtin. Et chaque variante doit avoir une URL qui l'affiche présélectionnée, avec la bonne image, le bon prix et le bon stock dès le chargement de la page.

Shopify et WooCommerce : ce qui est déjà en place

Shopify

Les thèmes officiels Dawn et Horizon insèrent le balisage avec le filtre Liquid structured_data. Selon la documentation Shopify, il produit un Product pour un produit sans variante et un ProductGroup dès qu'il y a des variantes. L'exemple de la documentation contient brand, category, description, image, name, offers et url. Elle ne dit pas si le GTIN y figure : vérifiez-le dans le code source de vos fiches.

Deux champs de l'admin méritent d'être remplis :

le code-barres de chaque variante : Shopify en accepte jusqu'à 20 par produit ou variante, de type GTIN, EAN, UPC, ISBN ou ASIN (aide Shopify) ;
la catégorie, choisie dans la taxonomie standard de Shopify : elle débloque des métachamps de catégorie, des attributs prédéfinis (matière, taille, couleur…) qui décrivent le produit de façon structurée.

Un thème tiers ou une application peut ajouter son propre bloc Product. Cherchez "@type": "Product" dans le code source : deux blocs qui donnent deux prix différents, c'est une contradiction de plus.

WooCommerce

Le cœur de WooCommerce produit lui-même un bloc Product (classe WC_Structured_Data, code source lu le 9 octobre 2026) : nom, URL, description (la description courte si elle existe), image, SKU, GTIN tiré du champ « GTIN, UPC, EAN ou ISBN », prix, devise, disponibilité et note moyenne des avis. Deux limites à connaître :

une fiche variable sans variante sélectionnée affiche une fourchette de prix (AggregateOffer, avec lowPrice et highPrice), pas un prix ;
le balisage du cœur ne contient pas de marque (brand).

Une extension SEO peut ajouter son propre bloc ou remplacer celui de WooCommerce. Même vérification que sur Shopify : un seul bloc Product par fiche, avec le prix affiché.

Une fiche, un prix, une adresse

Le guide ChatGPT Shopping détaille la cohérence entre la page, le balisage, le flux et les places de marché. Deux détails s'y ajoutent sur la fiche elle-même :

une URL stable : si vous changez l'adresse d'une fiche, redirigez l'ancienne vers la nouvelle ;
une promotion qui se termine pour de bon : le prix barré, le badge et le sale_price du flux disparaissent le même jour.

Ce que skoup contrôle

L'audit technique de skoup vérifie ces points sur vos fiches : contenu et nom du produit présents sans JavaScript, balisage Product avec un prix et une disponibilité valides au sens des fiches marchandes de Google, livraison et politique de retour (jamais en erreur, puisqu'elles peuvent être déclarées dans Merchant Center), conformité du flux fiche par fiche. Dès le plan Growth, le write-back corrige la description, le titre SEO, la meta et le code-barres ; sur WooCommerce, le titre SEO et la meta seulement avec Yoast SEO ou Rank Math. Jamais le prix. Le détail est sur la page Produit.

La checklist

Le nom, le prix et la description sont dans le code source de la page.
Le nom du produit dit la marque, le type, le modèle et la variante.
Les caractéristiques chiffrées sont écrites en texte, avec leur unité et leur condition.
Un tableau HTML regroupe les caractéristiques, pas une image.
La fiche dit pour qui est le produit, et pour qui il ne l'est pas.
Compatibilité, entretien, contenu du colis, livraison et retour ont chacun leur réponse.
Chaque image a un texte alternatif qui nomme le produit et la variante.
Les avis clients sont lisibles dans le HTML de la page.
Un seul bloc Product (ou ProductGroup) par fiche.
name, image, price et priceCurrency sont présents ; la disponibilité utilise une valeur schema.org.
Chaque produit ou variante a un GTIN, ou à défaut une référence fabricant.
La marque est déclarée (brand).
Livraison et retour sont balisés, ou déclarés dans Merchant Center ou Search Console.
aggregateRating n'apparaît que si la note est affichée.
Chaque variante a son URL, qui affiche son prix, son image et son stock.
Le prix est le même sur la page, dans le balisage, dans le flux et sur les places de marché.
Une fiche qui change d'adresse redirige l'ancienne.

Pour savoir si ces corrections changent ce que les assistants répondent, mesurez avant et après, avec les mêmes questions : c'est la méthode du guide Suivre ses produits dans ChatGPT. L'audit gratuit donne un premier point de départ.