What the carousel schema generator does
This tool builds the ItemList JSON-LD that Google uses to render a carousel rich result, the horizontally scrollable row of cards that can appear in search for recipes, courses, movies, restaurants, and similar lists. You enter the items in your list, in the order you want them shown, and the generator outputs a single ItemList block whose itemListElement array carries each item as a numbered ListItem. The result is copy-and-paste ready and structured the way Google expects for a host-specific carousel.
A carousel is not its own content type. It is a presentation layer Google can choose to apply when a page links to several other pages that each carry a supported rich-result type. The ItemList you generate here is the wrapper that ties those items together and declares their order. The individual items still need their own underlying schema on their own pages for the carousel to be eligible, which is the single most important thing to understand before you use this output.
The two carousel patterns and which one you need
Google supports two shapes of list markup, and choosing the wrong one is the most common structural error. The first is the summary or all-in-one page pattern, where one page lists many items and each ListItem points by url to a separate detail page that holds the full schema. The generator produces this when your items each have their own destination URL. Here the ListItem only needs a position and a url; the rich data lives on the page that url points to.
The second is the all-on-one-page pattern, where a single page contains the full content of every item, such as a single article that ranks ten products. In that case each ListItem nests the complete item schema inside it, for example a full Product or Recipe object as the item value, rather than just pointing elsewhere. The generator can emit either shape; you pick based on whether your items live on separate pages or all on one. Mixing the two, like giving a ListItem both a url to a detail page and a full nested object, is invalid and a frequent cause of failed validation.
What the generated ItemList contains
The output is a JSON-LD script with @context schema.org and @type ItemList. Its core is itemListElement, an array where every entry is a ListItem. Each ListItem carries a position, which is a one-based integer that fixes the display order, and either a url for the summary pattern or a nested item object for the all-on-one-page pattern. The generator numbers positions sequentially starting at one and keeps them contiguous, because gaps or duplicate positions break the ordering Google relies on.
Order in the array is not what determines display order; the position values are. The generator keeps the two aligned so the first card shown matches the first item you entered. If you later reorder items by hand, renumber the positions to match, or the carousel may render in an order you did not intend. The block is placed on the page that represents the list itself, typically your category, roundup, or hub page.
How to read the result and verify eligibility
Read the output top to bottom and check three things. Positions should run one, two, three with no gaps. Every summary-pattern ListItem should have a real, absolute url that resolves to a live page. And the count of ListItems should match the number of items you intend to show. Google has practical limits on how many cards it will display, so an extremely long list will simply be truncated rather than rejected.
Validation has two layers and they are easy to conflate. The Rich Results Test checks the ItemList wrapper for syntax and structure, but it cannot confirm the carousel will appear unless the linked items also qualify. Test the ItemList page first, then test one of the linked detail pages to confirm its own schema, such as Recipe or Course, is valid. A perfectly formed ItemList pointing at pages with broken or missing item schema produces no carousel at all.
Which content types can become a carousel
Carousels are not available for every kind of list, and knowing the eligible set saves wasted effort. Google supports the host carousel for a defined group of content types, the kind that already have their own rich-result treatments, such as recipes, courses, movies, restaurants and local businesses, and certain product and article roundups. The ItemList wrapper organizes these eligible items into the scrollable row, but it cannot conjure a carousel for a type Google does not offer one for. Before you build the list, confirm your items belong to a supported type.
This is why the order of operations matters. The carousel is the last layer, not the first. The right sequence is to make sure each item page carries valid, reasonably complete schema for its supported type, then wrap those pages in an ItemList. If you start by building the ItemList and only later discover the items have no qualifying schema, you have a wrapper around nothing. The generator gives you the wrapper; the eligibility comes from the items, so treat the ItemList as the finishing touch on top of item schema that already works.
Keeping the markup honest and in sync with the page
Google's structured-data policy is explicit that markup must represent content a user can actually see on the page, and carousels are a place where teams are tempted to cheat. Listing items in the ItemList that do not appear on the visible page, padding the list with extra entries to look comprehensive, or ordering the markup differently from the on-page list are all policy risks that can cost you the rich result or trigger a manual action. The ItemList should mirror the real, visible list a reader scrolls through.
Synchronization is an ongoing job, not a one-time setup. Roundups and category pages change as you add, remove, and reorder items, and the ItemList has to move with them. A common failure mode is a carousel that still lists a product you discontinued or omits one you added last month, because the markup was generated once and never refreshed. Treat the ItemList as part of the page's living content: when the visible list changes, regenerate the markup so positions stay contiguous and the items still match what is on screen.
Common mistakes specific to carousel markup
The biggest mistake is marking up a list of generic items that have no supported rich-result type. Carousels are only available for specific host types Google documents, and an ItemList of arbitrary blog links or random products without proper Product schema will validate as an ItemList but never become a carousel. Confirm your item type is one Google supports for carousels before investing in the markup.
The second is broken or non-canonical URLs in the summary pattern. Each url must be absolute, must use HTTPS, and must point at the indexable canonical version of the detail page. Relative paths, redirects, and links to noindexed pages all sabotage the carousel. The third is inconsistent item types within one list. Google expects a carousel to be homogeneous, so do not mix recipes and courses in the same ItemList; build one carousel per type.
A quieter mistake is letting the carousel contradict what is visible on the page. The items in your ItemList should genuinely appear, in roughly the same order, in the page content a user sees. Structured data that lists items the page does not show is a structured-data policy violation and can trigger manual action, not just a missing rich result.
How carousels fit modern SEO and AI search in 2026
Carousels remain a strong real-estate play in classic search because they let a single result occupy a wide, scrollable strip that pushes competitors down. For roundups, recipe collections, course catalogs, and product lists, that visual prominence drives clicks. The ItemList markup is the entry ticket, and it costs little once your item pages already carry their own schema.
Beyond the visual feature, ItemList does real work for AI systems. Large language models and AI Overviews parse structured lists to understand ranked sets, which is exactly the format they like to summarize and cite. A clean, ordered ItemList that mirrors a genuine best-of or top-ten article gives an AI engine an explicit, machine-readable ranking to lift. So even on pages where the visual carousel never appears, the markup improves how clearly machines understand your list.
What to do after you generate the markup
Paste the ItemList block onto your list page and deploy. If you used the summary pattern, confirm each linked detail page already has valid, complete schema for its type; if it does not, generate and add that first, because the carousel depends on it. Then run the Rich Results Test on the list page and on at least one detail page to verify both layers pass.
Request indexing of the updated pages in Search Console, then watch the Enhancements and rich-result reports over the following days to confirm Google has parsed the ItemList. If the carousel does not appear, recheck that your item type is carousel-eligible, that every url resolves to an indexable page, and that the listed items match the visible content. Keep positions contiguous whenever you add or remove items, and regenerate the block rather than editing positions by hand to avoid numbering drift.