Quand utiliser le schema ItemList pour décrire une liste réelle ?

Par l’équipe Limpi. Les faits externes sont distingués des méthodes Limpi et aucune visibilité, position ou citation automatique n’est garantie.

Comprendre Schema.org ItemList

Schema.org ItemList sert à représenter une liste réelle d’éléments lorsque la liste elle-même constitue une structure utile à décrire. Le type ne transforme pas automatiquement toute succession de liens, de cartes ou de paragraphes en donnée structurée pertinente. Il faut d’abord vérifier qu’il existe bien un ensemble d’éléments organisé et identifiable dans le contenu visible.

Inspecter la liste réellement présentée

Commencez par observer ce que voit l’utilisateur : quels éléments composent la liste, dans quel ordre ils apparaissent et si cet ordre possède une signification. Comparez ensuite le JSON-LD éventuel avec la liste visible. Les éléments déclarés ne devraient pas inventer des entrées absentes, masquer des éléments importants ni présenter un classement qui n’existe pas dans l’interface.

Distinguer ItemList des types voisins

ItemList décrit une collection ordonnée ou non d’éléments. BreadcrumbList possède un rôle beaucoup plus précis pour un fil d’Ariane. Une page de catégorie peut contenir une liste de produits sans que la page elle-même devienne Product. De même, une liste d’articles peut rester une WebPage qui référence plusieurs contenus plutôt que d’accumuler des types sans relation claire.

Identifier les causes de balisage artificiel

Les erreurs apparaissent souvent lorsqu’un plugin ajoute ItemList à toutes les pages contenant plusieurs cartes, lorsqu’un template transforme automatiquement une navigation en liste éditoriale ou lorsque des positions sont générées sans correspondre à l’ordre réellement visible. Une autre source d’incohérence vient des listes paginées dont chaque page recommence artificiellement à la position 1.

Décider quand ItemList apporte une information réelle

Utilisez ItemList lorsqu’une liste structurée constitue réellement une entité utile à décrire : sélection d’éléments, classement, série cohérente ou ensemble organisé. Ne l’ajoutez pas uniquement parce qu’une page contient plusieurs liens internes. Le choix doit venir de la nature du contenu et non d’un objectif de produire davantage de JSON-LD.

Structurer les éléments sans inventer de données

Lorsque le type est justifié, décrivez les éléments avec les propriétés réellement connues. itemListElement peut référencer des ListItem, et position peut être utile lorsque l’ordre a un sens. Gardez des URL et des noms cohérents avec le contenu visible. Évitez de générer des positions, notes ou catégories qui ne sont pas maintenues par la source éditoriale.

Gérer l’ordre, la pagination et les variantes

Une liste classée n’a pas les mêmes exigences qu’un ensemble sans ordre significatif. Sur une pagination, décidez si chaque page représente une portion d’une liste plus large ou une liste autonome. Sur mobile, un changement de mise en page visuelle ne doit pas forcément modifier la logique de la liste. La modélisation doit suivre l’ordre sémantique réel plutôt qu’une simple disposition CSS.

Relier ItemList au reste du graphe

ItemList peut coexister avec WebPage et avec les entités réellement listées. Le document courant reste une page éditoriale lorsqu’il explique le fonctionnement du balisage. Si les éléments possèdent déjà des @id stables, réutilisez-les plutôt que de créer des copies concurrentes. L’objectif est de rendre les relations cohérentes, pas de multiplier les objets isolés.

Valider la cohérence avec le contenu visible

Une validation syntaxique ne suffit pas. Comparez chaque élément structuré avec la liste affichée, son nom, son URL et sa position éventuelle. Testez aussi les variantes de tri, filtres et pagination. Si l’utilisateur voit dix éléments mais que le JSON-LD en décrit cinquante issus d’un catalogue caché, la représentation ne correspond plus au contenu réellement présenté.

Prévenir les régressions du template

Centralisez la génération de la liste depuis la même source de données que l’interface lorsque c’est possible. Un changement de tri, de pagination ou de filtrage doit pouvoir mettre à jour simultanément le rendu visible et les données structurées. Évitez les scripts indépendants qui recalculent une deuxième version de la liste avec une logique différente.

Clôturer le contrôle sur Schema.org ItemList

Pour clôturer le contrôle « Quand utiliser le schema ItemList pour décrire une liste réelle ? », conservez la page testée, les éléments visibles, leur ordre, les propriétés JSON-LD et la raison pour laquelle la liste constitue une entité pertinente. Contrôlez aussi /seo/donnees-structurees, /seo/schema-breadcrumblist et /seo/schema-webpage afin de vérifier que les rôles restent distincts. La borne documentaire reste Schema.org ItemList : elle décrit le vocabulaire, sans garantir à elle seule une fonctionnalité particulière dans les résultats de recherche. Gardez la page Limpi elle-même en WebPage puisque ce guide explique ItemList sans être la liste métier qu’il décrit.

Tester un scénario représentatif

Prenez une page présentant une sélection ordonnée de dix ressources. Vérifiez d’abord que les dix cartes sont visibles et que leur ordre est intentionnel. Dans le graphe, chaque ListItem peut recevoir une position correspondant à cet ordre et référencer l’URL de la ressource concernée. Modifiez ensuite le tri : si l’interface passe de « recommandé » à « plus récent », vérifiez que les positions structurées évoluent avec elle ou que le balisage n’affirme pas un classement devenu faux. Testez ensuite une pagination. Si la deuxième page affiche les éléments 11 à 20 d’un classement global, documentez la logique retenue au lieu de recommencer les positions au hasard. Comparez enfin une simple navigation de pied de page contenant dix liens : elle forme bien une liste en HTML, mais cela ne signifie pas qu’elle mérite une entité ItemList éditoriale. Ce contre-exemple permet de séparer structure HTML, navigation et donnée structurée décrivant une collection réelle. Pour chaque contrôle, relevez le type, itemListElement, ListItem, position, item ou URL, name éventuel et @id utilisé. Vérifiez qu’aucune entrée structurée ne pointe vers une ressource supprimée, redirigée ou absente de la présentation. Si une liste est filtrée selon le profil de l’utilisateur, testez le rendu anonyme destiné aux crawlers au lieu de décrire une liste personnalisée inaccessible. Sur une catégorie e-commerce, distinguez aussi la liste de produits des entités Product individuelles : ItemList peut organiser des références, tandis que chaque produit conserve sa propre identité. Sur une page éditoriale « 10 outils à vérifier », n’ajoutez pas de positions seulement pour obtenir un balisage plus riche si l’ordre n’est pas réellement défendu dans le contenu. La clôture doit montrer que la liste structurée, la liste visible et la source métier utilisent le même périmètre et le même ordre lorsque celui-ci a un sens.

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.

• schema itemlist