Schema ItemList

Ce qu'ItemList décrit vraiment

ItemList est un conteneur générique du vocabulaire schema.org : il ne décrit pas des entités, il décrit le fait qu'un ensemble d'entités forme une liste. Toute la substance se trouve dans la propriété itemListElement, un tableau de ListItem, chacun portant une position et soit une url pointant vers la page de l'élément, soit un objet item imbriqué décrivant l'élément en entier. Ces deux formes ne sont pas interchangeables, et confondre l'une avec l'autre est la première cause de balisage inerte qu'on rencontre.

La forme résumé, où chaque ListItem ne contient qu'une position et une URL, sert les pages qui listent des éléments hébergés ailleurs sur le site : un classement de fiches produit, une sélection de prestataires, un sommaire de rubrique. La forme complète, où chaque position embarque un Product, un Event ou un LocalBusiness avec ses propriétés obligatoires, sert les pages qui décrivent tout sur place. Un carrousel Google exige la seconde, avec des items individuellement valides selon leur propre type.

Détail que beaucoup d'audits ignorent : BreadcrumbList est un sous-type d'ItemList. Tout site qui balise correctement son fil d'Ariane utilise donc déjà ItemList sans l'avoir décidé, avec exactement la même mécanique de positions ordonnées. Cela explique pourquoi ces deux balisages entrent parfois en collision quand ils sont générés par deux plugins différents sur la même page.

Enfin, ItemList appartient à un vocabulaire bien plus large que ce que Google consomme réellement. Le fait qu'un type existe dans la spécification schema.org ne dit rien de son exploitation par un moteur, et c'est précisément la nuance qui sépare un balisage utile d'un balisage décoratif. Un audit qui remonte des anomalies de données structurées sans préciser lesquelles ont un débouché d'affichage produit une liste de tâches sans valeur.

Carrousels : le seul débouché SERP réel

En août 2025, Google a ouvert en bêta les carrousels issus de données structurées, d'abord en Afrique du Sud. Le principe est exactement celui décrit plus haut : un ItemList extérieur sert de conteneur, chaque entrée est un ListItem identifiant un élément distinct, et les types éligibles relèvent de verticales précises comme LocalBusiness, Product ou Event. Le déploiement était géographiquement restreint dès le départ, pas mondial.

Le 21 janvier 2026, d'après PPC Land, Google a étendu cette expérience sud-africaine à de nouvelles catégories de requêtes : livraison de repas, location de voiture et réservation de bus, sans exiger de nouveau balisage des entreprises qui implémentaient déjà la structure supportée. C'est un signal intéressant sur la trajectoire : la mécanique est stable, ce qui bouge, ce sont les verticales et les marchés où Google décide de l'activer.

Les documentations d'implémentation tierces convergent sur deux seuils opérationnels : deux éléments minimum pour prétendre à un carrousel, trois ou plus pour certaines listes verticales comme Course List. Et la limite qui compte vraiment : un ItemList générique posé autour de dix articles de blog, de dix fiches produit non conformes ou de dix événements sans propriétés requises ne produit aucun carrousel. La liste de blog balisée n'a jamais eu de rendu SERP dédié, et rien depuis août 2025 ne l'a changé.

Il faut lire ça dans le mouvement général, qui va dans l'autre sens. Le 12 juin 2025, Google a retiré sept fonctionnalités de données structurées : Book Actions, Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement et Vehicle Listing, avec un arrêt du reporting Search Console et des champs d'export dépréciés renvoyant NULL à partir du 1er octobre 2025. En novembre 2025, Google a annoncé la fin du support de Practice Problem à partir de janvier 2026 et clarifié que Dataset servait Dataset Search plutôt que les résultats enrichis classiques. Le 7 mai 2026, les résultats enrichis issus du balisage FAQ ont cessé d'apparaître dans Google Search.

Un épisode mérite d'être retenu par tous ceux qui pilotent un backlog technique : Book Actions a finalement été repêché, Google ayant retiré la mention de dépréciation en novembre 2025 parce qu'une fonctionnalité de recherche utilisait encore le balisage. Morale opérationnelle : on ne planifie pas une suppression de schema sur la foi d'un article listant les types « morts », on vérifie la documentation Search Central en cours. La position défendable en 2026 est donc simple : Google taille dans les rich results sous-utilisés tout en élargissant sélectivement quelques expériences en liste, dont les carrousels. ItemList n'est ni promu au rang de signal, ni menacé.

Baliser une liste correctement en 2026

Le format à utiliser est le JSON-LD injecté dans le head, pas le microdata dispersé dans le DOM : il se génère côté template, se diffe proprement en revue de code et survit aux refontes CSS. Un seul ItemList par page décrivant la liste principale, des positions entières contiguës commençant à 1, des URL absolues et canoniques, et un name qui correspond au titre affiché. numberOfItems et itemListOrder se remplissent quand l'ordre a un sens éditorial, ce qui est le cas d'un classement et pas celui d'un annuaire alphabétique.

La règle qui casse le plus de balisages : le JSON-LD doit refléter ce que l'utilisateur voit. Une page paginée qui rend dix éléments mais déclare quarante positions ment sur son contenu, et une liste chargée après interaction sans rendu serveur ne sera pas vue par le crawler au moment où il évalue la page. Sur les URL, même exigence : une position qui pointe vers une adresse en redirection 301 ou vers une variante non canonique fait perdre l'appariement entre l'élément déclaré et la page réellement indexée.

Côté validation, il faut accepter un comportement qui déroute : le Rich Results Test ne rapporte que les fonctionnalités supportées. Un ItemList parfaitement valide peut n'y déclencher aucun résultat enrichi détecté, et ce n'est pas une erreur, c'est l'absence de débouché pour cette verticale. De même, Search Console n'ouvre un rapport que pour les types d'apparence qu'il suit. Piloter un chantier schema sur le nombre d'éléments valides revient à mesurer la longueur du câble plutôt que le courant.

Le contexte génératif change le cadrage de la mesure sans changer les faits. Le 7 octobre 2025, Google a étendu AI Mode à plus de 35 langues et plus de 40 pays et territoires supplémentaires, portant la disponibilité à plus de 200 pays et territoires. Cela renforce mécaniquement l'intérêt de données d'entités et de listes lisibles par machine, mais Google n'a jamais déclaré qu'ItemList était un signal de classement ou de citation dans AI Mode, et vendre cette promesse à un client serait malhonnête. Depuis le 3 juin 2026, Google publie dans Search Console des rapports dédiés à la visibilité générative sur Search et Discover : c'est là qu'on regarde si une page liste gagne du terrain, pas dans un validateur de schéma.

Où ça compte dans une opération de netlinking

Les pages qui portent un ItemList utile sont souvent celles qui portent aussi l'essentiel de la valeur commerciale : comparatifs, sélections, classements, annuaires de prestataires. Ce sont également les formats qui attirent le plus naturellement des liens éditoriaux, parce qu'un journaliste ou un blogueur cite volontiers un classement documenté. Le balisage rend cette structure explicite pour les moteurs, il ne la rend pas méritante.

La montée des surfaces génératives rend ces formats plus stratégiques qu'avant. Une analyse Semrush portant sur plus de 10 millions de mots-clés a mesuré des AI Overviews sur 6,49 % des requêtes en janvier 2025, 7,64 % en février et 13,14 % en mars, soit un doublement en deux mois. Les analyses fondées sur le même jeu de données indiquaient fin 2025 un élargissement des requêtes déclencheuses au-delà de l'informationnel, vers le commercial, le transactionnel et le navigationnel. Traduction opérationnelle : une liste structurée de produits, d'événements ou d'établissements pèse davantage qu'un balisage de liste d'articles de blog.

Reste à situer le levier à sa juste place. Une enquête professionnelle de 2025, reprise dans les analyses de 2026, rapportait que 21,8 % des répondants constataient un impact positif des données structurées, contre 16,4 % pour l'acquisition de liens et 22,9 % pour le maillage interne. Ce sont des déclarations de praticiens, pas une expérimentation causale, et personne ne devrait en tirer qu'un schéma remplace un profil de liens. Ce que ces chiffres disent honnêtement, c'est que le travail de liens internes reste le levier le plus régulièrement ressenti, et qu'il coûte moins cher que tout le reste.

Sur les médias éditoriaux que nous opérons en propre, les pages de sélection sont balisées en ItemList sans qu'aucune ne déclenche de carrousel : les verticales concernées ne sont pas supportées. Ce qui les fait ranker, ce sont les domaines référents et la profondeur du contenu, pas le JSON-LD. C'est aussi la raison pour laquelle un arbitrage budgétaire honnête compare le coût d'une refonte schema à ce que coûte réellement un lien éditorial posé chez un éditeur. Une enquête menée en 2025 auprès de 518 professionnels du SEO situait le coût moyen d'un backlink de qualité autour de 508,95 dollars, ce qui donne l'ordre de grandeur pour trancher. Quand la question est de savoir sur quels médias placer ces liens, mieux vaut consulter le catalogue des supports sans avoir à créer de compte que de raisonner sur des moyennes de marché.

Les erreurs qu'on voit en audit

La plus fréquente : l'ItemList posé sur la page d'accueil pour lister les rubriques du site. Aucun débouché, aucune verticale supportée, aucun affichage, et un fichier de plus à maintenir. La deuxième : des positions qui commencent à zéro, sautent des numéros ou se répètent parce que la boucle du template inclut un élément publicitaire au milieu de la liste. Google n'a pas à deviner l'ordre implicite, une numérotation cassée invalide l'ensemble.

Vient ensuite la collision de balisages. Deux extensions qui injectent chacune leur ItemList, ou un fil d'Ariane et une liste principale qui se marchent dessus, produisent une page où le moteur doit arbitrer entre deux descriptions contradictoires de la même structure. Sur un site géré par plugins, la vérification se fait sur le HTML rendu en production, pas sur le code du thème.

Erreur plus subtile, et coûteuse pour ceux qui visent réellement un carrousel : imbriquer des objets Product ou Event incomplets. Un produit sans offers exploitable ou un événement sans date et lieu valides reste un item invalide, et un seul item invalide suffit à disqualifier le conteneur. Le carrousel ne se refuse pas au niveau de l'ItemList, il se refuse au niveau de l'élément le plus faible.

Enfin, deux erreurs de jugement plutôt que de code. La première consiste à copier un exemple de carrousel documenté pour une verticale supportée, à ne rien voir apparaître, et à en conclure que les données structurées ne servent à rien : le problème était le périmètre, pas le balisage. La seconde consiste à classer en priorité haute, dans un audit, des dizaines d'avertissements schema sans débouché d'affichage, pendant que la page comparative qui porte le chiffre d'affaires n'a que trois domaines référents. Le balisage se corrige en une demi-journée de dev, l'autorité se construit sur des mois : l'ordre des travaux devrait refléter cette asymétrie.