How can you properly tag your recipe carousels without risking a spam penalty?

What tag does Google exactly expect for multi-recipe pages?

Müller doesn't specify the name of the tag in this statement, which is typical of Google. It can be assumed he is referring to itemListElement in Schema.org, which allows you to structure a collection of recipes under an ItemList object. The idea is to explicitly say, "this page contains 5 recipes" rather than tagging Recipe 5 times in a flat manner.

The classic pitfall? Tagging each recipe individually with Recipe Schema without a parent container. Google may then believe that you are trying to artificially multiply your rich snippets for a single URL. And this is where the problem arises.

Why does Google consider this as potential spam?

A poorly marked recipe carousel looks, in the eyes of an algorithm, like an attempt to stuff structured data. If your page displays "10 pasta recipes," but you tag each recipe as if it were the MAIN recipe of the page, you are technically lying about the nature of the content.

Google aims to prevent SERPs from being filled with duplicated or misleading rich results from the same URL. One page = one primary rich result, unless you properly signal that it is a structured collection. Without this distinction, the spam filter may trigger, especially if you repeat this pattern on a large scale.

What is the concrete difference between a single-recipe page and a multi-recipe page?

A single-recipe page displays only one main content: title, ingredients, steps, cooking time. You mark it with a single Recipe object as root. Easy.

A multi-recipe page — let's say "7 variations of risotto" — presents several distinct content blocks on a single URL. Each block deserves its own Recipe Schema, but the whole must be encapsulated in an ItemList to indicate to Google that this is an intentional aggregation, not manipulation.

The nuance is critical for recipe sites that structure their content into thematic hubs or seasonal collections.

• Use ItemList as a parent container for any page displaying 2 or more recipes
• Each recipe remains individually tagged with Recipe Schema as an item of the list
• Provide the total number of items (numberOfItems) to clarify the editorial intent
• Avoid tagging recipes that are not visible or accessible on the page (teasers, suggestions, etc.)
• Test the implementation with the Rich Results Test to ensure Google correctly interprets the structure

Is this recommendation aligned with what we observe in practice?

Yes and no. Since late 2022, we have indeed seen recipe sites lose their rich snippets or experience a sharp drop in visibility after deploying pages like "10 recipes for X." However, Google has never published detailed official documentation on the usage of ItemList for recipes — it requires cross-referencing Search Console feedback, A/B tests, and statements like this.

The ambiguity remains regarding the threshold: how many recipes do you need to switch to ItemList? 2? 3? 5? [To be verified] as Google doesn’t provide a number. Some sites switch to ItemList at 2 recipes for caution, others only beyond 5. No official data to settle the matter.

What are the risks if we ignore this guideline?

The main risk is not a manual penalty — Google won't blacklist you for incorrect Schema markup. It's more of an algorithmic filter that degrades or removes your rich results. In practical terms: loss of CTR, drop in positions if your competitors display clean rich snippets.

We've also seen cases where Search Console raises alerts like "Duplicate markup detected" or "Misleading structured data." Traffic drops, but no clear message appears in the interface. It requires cross-referencing logs, organic performance, and manual tests to realize there's a markup issue.

In what cases does this rule not apply?

If your page displays a main recipe + suggestions in the sidebar or at the bottom of the page ("similar recipes"), you should NOT mark the suggestions. They are not part of the main content of the page; they serve navigation. Only tag the hero recipe.

The same goes for category or listing pages: if you show snippets of 20 recipes with links to dedicated pages, do not markup anything on the listing page. The Schema.org Recipe should be reserved for final content pages, not SEO aggregation pages.

What changes should be made in the code?

Audit all your pages containing 2 or more recipes. For each, verify if an ItemList encapsulates the Recipe objects. If not, add it as root. Each recipe then becomes an itemListElement with its position in the list.

Minimal example: an ItemList with @type "ItemList", numberOfItems "5", and 5 itemListElement each containing a complete Recipe object. Google then interprets the page as an intentional collection, not 5 attempts at rich snippets.

How can you test if the implementation is correct?

Pass each URL through Google’s Rich Results Test. You should see the ItemList AND the child Recipes appear. If only the Recipes appear without their parent, it’s a failure. If the ItemList is detected but the Recipes are not recognized as valid items, check your @type and position syntax.

Then, request re-indexing via Search Console and monitor the evolution of rich impressions in the "Rich Results" report. If the rich snippets disappear after a deployment, immediate rollback and debugging of the Schema are required.

What mistakes should you absolutely avoid?

Do not tag recipes that are not entirely present on the page. If you display a teaser with just the title and a "See the recipe" link, this is not a recipe in the Schema.org sense. Google dislikes structured data that promises absent content.

Avoid mixing multiple content types within the same ItemList. If your page contains 3 recipes + 2 blog articles, do not put them in the same ItemList. Logically separate types, or only tag the dominant content.

• Identify all multi-recipe pages (2+ recipes fully displayed)
• Implement an ItemList object as root with @type "ItemList"
• Encapsulate each Recipe in an itemListElement with its position
• Provide numberOfItems to indicate the total number of items
• Test each modified URL in the Rich Results Test
• Monitor Search Console for potential warnings on the markup