Comment baliser correctement vos carrousels de recettes sans risquer une pénalité spam ?

Quelle balise Google attend-il exactement pour les pages multi-recettes ?

Müller ne précise pas le nom de la balise dans cette déclaration, ce qui est typique de Google. On peut supposer qu'il fait référence à itemListElement dans le Schema.org, qui permet de structurer une collection de recettes sous un objet ItemList. L'idée est de dire explicitement « cette page contient 5 recettes » plutôt que de baliser 5 fois Recipe en flat.

Le piège classique ? Baliser chaque recette individuellement avec Recipe Schema sans conteneur parent. Google peut alors croire que vous tentez de multiplier artificiellement vos rich snippets pour une seule URL. Et c'est là que ça coince.

Pourquoi Google considère-t-il ça comme du spam potentiel ?

Un carrousel de recettes mal balisé ressemble, aux yeux d'un algo, à une tentative de bourrage de données structurées. Si votre page affiche « 10 recettes de pâtes », mais que vous balisez chaque recette comme si c'était LA recette principale de la page, vous mentez techniquement sur la nature du contenu.

Google cherche à éviter que les SERP se remplissent de rich results dupliqués ou trompeurs provenant d'une même URL. Une page = un résultat enrichi principal, sauf si vous signalez proprement qu'il s'agit d'une collection structurée. Sans cette distinction, le filtre spam peut se déclencher, surtout si vous répétez ce pattern à grande échelle.

Quelle différence concrète entre page mono-recette et page multi-recettes ?

Une page mono-recette affiche un seul contenu principal : titre, ingrédients, étapes, temps de cuisson. Vous balisez avec un unique objet Recipe en root. Facile.

Une page multi-recettes — disons « 7 variations de risotto » — présente plusieurs blocs de contenu distincts sur une seule URL. Chaque bloc mérite son propre Recipe Schema, mais l'ensemble doit être encapsulé dans un ItemList pour indiquer à Google qu'il s'agit d'une agrégation intentionnelle, pas d'une manipulation.

La nuance est critique pour les sites de recettes qui structurent leur contenu en hubs thématiques ou en collections saisonnières.

• Utiliser ItemList comme conteneur parent pour toute page affichant 2 recettes ou plus
• Chaque recette reste balisée individuellement avec Recipe Schema en tant qu'item de la liste
• Renseigner le nombre total d'items (numberOfItems) pour clarifier l'intention éditoriale
• Éviter de baliser des recettes qui ne sont pas visibles ou accessibles sur la page (teasers, suggestions, etc.)
• Tester l'implémentation avec le Rich Results Test pour vérifier que Google interprète correctement la structure

Cette recommandation est-elle alignée avec ce qu'on observe terrain ?

Oui et non. Depuis fin 2022, on voit effectivement des sites de recettes perdre leurs rich snippets ou subir une baisse de visibilité brutale après avoir déployé des pages de type « 10 recettes de X ». Mais Google n'a jamais publié de documentation officielle détaillée sur l'usage d'ItemList pour les recettes — il faut croiser des retours Search Console, des tests A/B et des déclarations comme celle-ci.

Le flou persiste sur le seuil : à partir de combien de recettes faut-il basculer vers ItemList ? 2 ? 3 ? 5 ? [A vérifier] car Google ne donne pas de chiffre. Certains sites passent en ItemList dès 2 recettes par prudence, d'autres seulement au-delà de 5. Aucune donnée officielle pour trancher.

Quels risques si on ignore cette consigne ?

Le principal risque n'est pas une pénalité manuelle — Google ne va pas vous blacklister pour un mauvais balisage Schema. C'est plutôt un filtre algorithmique qui va dégrader ou supprimer vos rich results. Concrètement : perte de CTR, baisse de positions si vos concurrents affichent eux des rich snippets propres.

On a aussi vu des cas où Search Console remonte des alerting « Duplicate markup detected » ou « Misleading structured data ». Le trafic chute, mais pas de message clair dans l'interface. Il faut croiser les logs, les perfs organiques et les tests manuels pour comprendre qu'on a un souci de balisage.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si votre page affiche une recette principale + des suggestions en sidebar ou en bas de page (« recettes similaires »), vous ne devez PAS baliser les suggestions. Elles ne font pas partie du contenu principal de la page, elles servent la navigation. Baliser uniquement la recette hero.

Idem pour les pages catégorie ou listing : si vous affichez des extraits de 20 recettes avec des liens vers les pages dédiées, ne balisez rien sur la page listing. Le Schema.org Recipe doit être réservé aux pages de contenu final, pas aux pages d'agrégation SEO.

Que faut-il modifier concrètement dans le code ?

Audit de toutes vos pages contenant 2 recettes ou plus. Pour chacune, vérifiez si un objet ItemList encapsule les objets Recipe. Si non, ajoutez-le en root. Chaque recette devient alors un itemListElement avec sa position dans la liste.

Exemple minimal : un ItemList avec @type « ItemList », numberOfItems « 5 », et 5 itemListElement contenant chacun un objet Recipe complet. Google interprète alors la page comme une collection intentionnelle, pas comme 5 tentatives de rich snippet.

Comment tester que l'implémentation est correcte ?

Passez chaque URL dans le Rich Results Test de Google. Vous devez voir apparaître l'ItemList ET les Recipe enfants. Si seuls les Recipe apparaissent sans parent, c'est raté. Si l'ItemList est détecté mais que les Recipe ne sont pas reconnus comme items valides, vérifiez votre syntaxe @type et position.

Ensuite, demandez une ré-indexation via Search Console et surveillez l'évolution des impressions riches dans le rapport « Résultats enrichis ». Si les rich snippets disparaissent après un déploiement, rollback immédiat et debuggage du Schema.

Quelles erreurs éviter absolument ?

Ne balisez pas des recettes qui ne sont pas intégralement présentes sur la page. Si vous affichez un teaser avec juste le titre et un lien « Voir la recette », ce n'est pas une recette au sens Schema.org. Google déteste les données structurées qui promettent du contenu absent.

Évitez aussi de mélanger plusieurs types de contenus dans un même ItemList. Si votre page contient 3 recettes + 2 articles de blog, ne les mettez pas dans le même ItemList. Séparez logiquement les types, ou balisez uniquement le contenu dominant.

• Identifier toutes les pages multi-recettes (2+ recettes affichées intégralement)
• Implémenter un objet ItemList en root avec @type « ItemList »
• Encapsuler chaque Recipe dans un itemListElement avec sa position
• Renseigner numberOfItems pour indiquer le total d'items
• Tester chaque URL modifiée dans le Rich Results Test
• Surveiller Search Console pour détecter d'éventuels warnings sur le markup