SEO Technique

Implémenter les données structurées pour le carrousel Google : le guide qui booste vos clics

Votre balisage produit est propre, mais le carrousel Google ne s'affiche pas ? Le coupable est souvent la couche `ItemList` oubliée. Découvrez le guide pour enfin décrocher votre carrousel.

Implémenter les données structurées pour le carrousel Google : le guide qui booste vos clics

Vous avez balisé votre page produit avec du Product, votre fiche événement avec du Event, et le carrousel refuse toujours de s'afficher dans les résultats. J'ai vécu exactement ça pendant près de deux mois sur un site de matériel de randonnée. Le balisage était propre. Le Rich Results Test me sortait un beau "Article valide". Et pourtant : rien. Aucun carrousel. Juste un résultat bleu classique, celui qu'on obtient depuis 2003.

Le problème n'était pas dans le balisage des produits. Il était dans la couche ItemList que j'avais complètement zappée — persuadé, à tort, que Google déduirait tout seul la liste à partir de mes fiches.

Implémenter les données structurées pour le carrousel Google, ce n'est pas baliser chaque élément. C'est déclarer la liste elle-même comme une entité, puis y loger les éléments. Cette nuance, on me la demande par mail au moins une fois par semaine, alors voilà le guide que j'aurais voulu lire avant de perdre six semaines.

Points clés à retenir

  • Le carrousel hôte repose sur un seul type racine : ItemList. Sans lui, les éléments ne s'affichent jamais en carrousel.
  • Chaque élément doit être un objet ListItem avec une position explicite — sauter un chiffre casse la liste entière.
  • Le type de contenu (produit, événement, lieu) est déclaré dans item, pas à la racine.
  • Le Rich Results Test valide la syntaxe, pas l'éligibilité : un rapport vert ne garantit pas l'affichage.
  • Sur les pages de catégorie, mieux vaut baliser une sélection éditoriale courte qu'un catalogue de 200 références.
  • Le statut reste expérimental sur plusieurs verticales ; l'affichage peut varier d'une requête à l'autre sans explication.

Le carrousel Google : ce que vous balisez vraiment n'est pas ce que vous croyez

Un carrousel de données structurées, c'est cette rangée horizontale de cartes qui apparaît dans les résultats, surtout sur mobile. Chaque carte pointe vers une page différente, et souvent vers un fragment précis de cette page (une ancre, un paragraphe).

Le piège est là. On croit baliser "mes produits". En réalité, on balise une collection de liens + un contenu cible par lien. Le carrousel n'est pas un annuaire de pages, c'est une table des matières enrichie.

Pourquoi un balisage produit seul ne suffit jamais

J'ai repris le rapport Search Console d'un client en janvier : 14 000 impressions sur la page catégorie, zéro impression carrousel. Le Product était carrément nickel sur chaque fiche. Le souci, c'est que Google n'a aucune raison de deviner que ces fiches forment une liste. Vous lui donnez des briques isolées. Il lui manque le ciment.

Ce ciment, c'est ItemList.

Trois familles de carrousels qu'il faut arrêter de mélanger

On lit partout que "le carrousel" est une seule chose. Faux. Il y en a plusieurs, avec des balisages distincts et des cas d'usage différents :

Type de carrousel Balisage racine Cas d'usage
Carrousel hôte (rich result) ItemList Listes de produits, événements, lieux, articles liés
Carrousel FAQ / Q&R FAQPage + questions Pages d'établissement, FAQ structurées
Carrousel agrégateur (expérimental) ItemList en variante éditoriale Pages de résumé, catégories paginées

Le carrousel hôte exige ItemList. Le carrousel FAQ repose sur FAQPage. Le troisième type est encore en test côté Google et son affichage est très inégal selon les requêtes et les régions. Ne confondez pas les trois dans vos tests — c'est l'erreur qui m'a coûté le plus de temps.

Le balisage JSON-LD ItemList : un exemple commenté qui fonctionne

Voici la structure minimale que j'utilise désormais systématiquement. Elle passe le Rich Results Test et déclenche l'affichage sur les verticales compatibles.

Le balisage JSON-LD ItemList : un exemple commenté qui fonctionne
{
  "@context": "https://schema.org",
  "@type": "ItemList",
  "name": "Sacs de randonnée légers",
  "itemListOrder": "https://schema.org/ItemListOrderAscending",
  "numberOfItems": 5,
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Sac 30L ultra-léger",
      "url": "https://exemple.fr/sac-30l#fiche-technique"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Sac 45L tissu ripstop",
      "url": "https://exemple.fr/sac-45l#fiche-technique"
    }
  ]
}

Les propriétés critiques à ne pas oublier

  • position : commence à 1, jamais à 0. Sauter un chiffre invalide la liste silencieusement.
  • itemListElement : obligatoire, contient au minimum 2 éléments pour qu'un carrousel ait un sens.
  • url : pointe vers la page ou son ancre. Les ancres profondes sont parfaitement valides et souvent plus pertinentes.
  • numberOfItems : facultatif, mais je le mets toujours — ça aide à détecter les désynchros quand on met à jour la page.

Faut-il baliser Product à l'intérieur du ListItem ?

Ça dépend de la verticale. Sur une page catégorie e-commerce, oui : imbriquez un Product complet dans item, avec prix, disponibilité et identifiant. Sur une page éditoriale ("Nos 5 coups de cœur"), non — un ListItem avec url et name suffit, et c'est plus juste sémantiquement.

J'ai testé les deux approches sur le même site. Sur les catégories, Product imbriqué apporte un vrai gain de richesse visuelle. Sur les articles éditoriaux, l'ajouter n'apportait rien — juste plus de surface d'erreur.

Pourquoi votre carrousel ne s'affiche pas : les erreurs de balisage que je vois le plus

Une fois le JSON-LD bien en place, il reste une longue liste de raisons pour lesquelles rien ne s'affiche. Voici celles qui reviennent :

Liste incomplète ou éléments sans position

Trois fois sur cinq. Le développeur a construit la liste en boucle et oublié d'incrémenter position. Google ne signale pas toujours l'erreur — il ignore simplement le carrousel.

Le contenu pointé n'est pas indexable

J'ai vu un ItemList pointer vers des URLs en noindex par accident (résidus d'un test de staging). Le carrousel ne s'est jamais affiché. Vérifiez toujours que les URLs de vos ListItem répondent bien 200 et sont accessibles aux robots.

L'incohérence page / balisage

Si votre page liste 12 produits mais que votre ItemList en déclare 4, ou l'inverse, vous vous exposez à un rejet. Google croise le contenu visible et le balisage. Restez cohérent, même si ça veut dire baliser moins que ce qui est affiché.

Éligibilité régionale et verticale

Tous les types de contenu ne sont pas éligibles au carrousel hôte partout dans le monde. Certaines restrictions s'appliquent spécifiquement dans l'EEE (règles liées au DMA), et l'éligibilité peut varier selon la verticale : produits, événements, établissements locaux, voyages. Ne présumez jamais que ce qui marche sur un site .com marche à l'identique sur un .fr. Vérifiez par test, pas par analogie.

Tester et valider : la procédure que j'applique à chaque mise en production

Deux outils, dans cet ordre.

  1. Rich Results Test : valide la syntaxe JSON-LD et l'éligibilité théorique. Vérifie les types reconnus, détecte les propriétés manquantes. Ne dit rien sur l'affichage réel.
  2. Rapport "Résultats enrichis" dans Search Console : montre ce que Google a effectivement détecté et les erreurs bloquantes sur des pages réelles.

Ce que j'ai appris à mes dépens : un rapport Search Console "valide" avec 200 éléments détectés ne garantit rien. L'affichage reste une décision algorithmique. Vous fournissez le matériel, Google décide.

Avertissement ou erreur : quelle différence concrète ?

Une erreur bloque le rich result. Un avertissement indique une propriété manquante mais non bloquante — Google peut quand même afficher le carrousel. Ne corrigez pas tous les avertissements en priorité : concentrez-vous d'abord sur les erreurs, puis sur les avertissements qui touchent les propriétés réellement utilisées à l'affichage.

Optimiser sans sur-balisage : ma règle des 3 à 10 éléments

On me demande souvent "combien d'éléments faut-il ?". Réponse honnête : personne ne le sait précisément, et Google ne publie pas de seuil. En pratique, j'observe que 3 à 10 éléments donnent les meilleurs résultats — au-delà, ça devient du remplissage, et le carrousel perd son intérêt éditorial.

Ma règle : sur une page catégorie, je balise une sélection éditoriale courte (les 5 à 8 références mises en avant dans le visuel), pas le catalogue complet. C'est plus lisible pour Google, plus honnête vis-à-vis de l'utilisateur, et ça évite les problèmes de maintenance quand les stocks bougent.

Ce qui m'amène à un point que je n'avais pas anticipé au départ :

L'affichage du carrousel varie fortement selon la requête, la région et le moment. J'ai vu une même page afficher un carrousel en février et plus rien en avril, sans changement de code. C'est le prix d'un dispositif encore expérimental sur plusieurs verticales. Ne construisez pas toute votre stratégie SEO dessus. Utilisez-le comme un bonus, pas comme un fondement.

Ce qu'il faut retenir, vraiment

Le carrousel Google n'est pas un résultat enrichi comme les autres. Il repose sur ItemList comme balisage racine, exige une hiérarchie de ListItem propre, et son affichage reste conditionnel à des critères que Google ne détaille jamais complètement.

Ce qui marche : balisez la liste, pas seulement ses éléments. Vérifiez la cohérence entre ce qui est visible et ce qui est déclaré. Testez sur des pages réelles. Et acceptez que l'absence d'affichage ne signifie pas forcément que vous avez mal fait.

La question que je me pose de plus en plus, c'est : à quoi bon optimiser pour un format que Google peut retirer d'un jour à l'autre sur une verticale donnée ? La réponse, pour moi, c'est qu'un ItemList propre reste utile même sans carrousel — il aide Google à comprendre la structure de votre page, et ça, ça ne disparaît pas avec une mise à jour d'algorithme. Le carrousel, c'est la cerise. Le gâteau, c'est le balisage sémantique correct. Si vous inversez la priorité, vous vous retrouverez à déboguer un JSON-LD à 23h un vendredi, comme moi.

Olivier Chevalier

Olivier Chevalier

Olivier Chevalier est journaliste spécialisé dans le SEO technique, domaine qu'il couvre depuis plus de huit ans. Ses sujets d'enquête portent sur l'architecture des sites, la performance serveur et les évolutions des algorithmes de recherche. À travers ses articles, il analyse les contraintes techniques qui influencent la visibilité des contenus en ligne.

Voir tous les articles →