Données structurées pour les pages catégories produits : ItemList, Product, et ce qu'il ne faut pas baliser

Une page catégorie produit et une page produit individuelle répondent à deux questions différentes, et le vocabulaire de données structurées de Google les traite différemment. Baliser une page catégorie comme s'il s'agissait d'une immense page produit est l'erreur la plus fréquente sur les sites e-commerce générés.

Une page catégorie et une page produit sont deux entités distinctes

Une page produit décrit une seule chose : un article précis avec un prix, un statut de disponibilité et, quand elles sont réellement collectées, des avis. Une page catégorie décrit une collection : une liste filtrée ou parcourue de nombreux articles. Schema.org donne à chacune son propre type pour cette raison — Product pour l'entité unique, ItemList pour la collection.

ItemList : ce que ça dit à Google d'une liste

Quand une page liste plusieurs produits distincts, la documentation de Google sur les données structurées Product couvre directement ce cas : baliser la page avec ItemList, où chaque itemListElement est un ListItem pointant vers une référence Product allégée — généralement name, url et image. Cela indique à Google ce dont la page est une liste.

Ce que cela ne fait pas, c'est se substituer aux rich results marchands — les extraits affichant prix, disponibilité et notes à côté d'un produit dans les résultats. Ceux-ci sont liés au balisage Product complet de la page produit individuelle et, dans la plupart des cas, à un flux Google Merchant Center synchronisé avec elle.

Les breadcrumbs sur une arborescence de catégories profonde

Les arborescences de catégories sont généralement l'endroit où le balisage breadcrumb prouve son utilité. Un BreadcrumbList qui reflète le fil visible — rayon, catégorie, sous-catégorie — donne à Google une hiérarchie explicite indépendante de la structure d'URL, ce qui compte d'autant plus que la profondeur augmente et que les facettes multiplient les variantes d'URL d'un même nœud.

Chaque ListItem nécessite une position, un name, et une URL item qui résout vers une page canonique réelle. Un breadcrumb qui pointe vers une variante filtrée ou paginée plutôt que vers la page catégorie canonique est une source fréquente de décalage entre le fil visible et le balisage.

Un exemple JSON-LD fonctionnel

{
  "@context": "https://schema.org",
  "@type": "ItemList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "item": {
        "@type": "Product",
        "name": "Chaussure de trail — modèle A",
        "url": "https://exemple.fr/chaussures/trail/modele-a",
        "image": "https://exemple.fr/images/modele-a.jpg"
      }
    },
    {
      "@type": "ListItem",
      "position": 2,
      "item": {
        "@type": "Product",
        "name": "Chaussure de trail — modèle B",
        "url": "https://exemple.fr/chaussures/trail/modele-b",
        "image": "https://exemple.fr/images/modele-b.jpg"
      }
    }
  ]
}

Notez ce qui est absent : pas d'offers, pas d'aggregateRating, pas de review dans les entrées de la page catégorie. Ces champs appartiennent à la page produit de destination, où l'affirmation qu'ils portent (ce prix précis, cette note précise) est vérifiable en contexte.

Cinq erreurs qui invalident un lot entier

• Baliser chaque combinaison de facettes comme un ItemList distinct. Les URL filtrées et triées d'une même catégorie produisent des données structurées quasi dupliquées à l'échelle, l'équivalent du contenu dupliqué sur pages templatisées.
• Copier les offers complets du produit sur la page catégorie. Un prix affiché sur une page de liste est un instantané ; la source de vérité est la page produit. Dupliquer les données offers à deux endroits invite à la désynchronisation.
• Omettre le BreadcrumbList sur les arborescences profondes. Plus l'arborescence de catégories est profonde, plus le balisage prouve sa valeur — et plus il coûte cher de l'omettre.
• Décalage du nombre d'éléments. Un ItemList annonçant 40 produits alors que la page visible en affiche 12 (pagination ou chargement différé) est incohérent avec ce que l'utilisateur voit réellement — exactement le type de décalage entre balisage et contenu que les consignes de Google signalent.
• Syntaxe JSON invalide à l'échelle. Une simple virgule surnuméraire dans un gabarit partagé peut invalider les données structurées de toute une arborescence de catégories d'un coup. C'est le même mode de défaillance traité dans données structurées : Article, FAQPage, BreadcrumbList, et il mérite le même contrôle automatisé.

Valider avant publication

• Rich Results Test — confirme les enrichissements que le parseur de Google reconnaît pour l'URL soumise.
• Schema Markup Validator — vérifie la conformité au vocabulaire schema.org indépendamment de l'éligibilité spécifique à Google.
• Rapports d'enrichissement de Search Console — la seule vue reflétant ce qui est réellement indexé et interprété à l'échelle, après coup plutôt qu'en amont.

Sur une arborescence de catégories templatisée, valider une URL représentative par variante de gabarit avant la mise en ligne d'un lot, puis surveiller les rapports d'enrichissement chaque semaine le premier mois — la même discipline « publier puis vérifier » que pour le canonical sur pages templatisées.

Ce que les données structurées ne font pas

Des données structurées valides et bien scopées ne garantissent jamais une amélioration de classement ni un rich result. Google traite le balisage comme un indice sur le contenu d'une page, pas comme une instruction sur son affichage — l'éligibilité à un enrichissement dépend toujours des propres règles de Google et, pour de nombreuses fonctionnalités produit, de signaux extérieurs au JSON-LD lui-même. Chaque affirmation de cet article doit être comprise ainsi : une description de ce qui est techniquement supporté, pas une promesse de visibilité.