What Is Carousel Schema?

Carousel Schema is ItemList structured data that organizes multiple entities from one site into an explicit ordered collection for eligible host-carousel search experiences.

The container is ItemList, each entry is a ListItem, and position states the intended order. The standard host-carousel documentation combines ItemList with supported content types such as Recipe, Movie, Course and Restaurant. A carousel is not a universal layout instruction: adding ItemList does not force search results to become swipeable cards, and it does not control unrelated multi-site features such as Top stories. The visible page must contain the same collection, item type, order and destinations described by the markup. Eligibility and actual presentation remain separate outcomes.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Build a visible collection.
• Use a supported entity type.
• Keep markup and order synchronized.

Primary specification: Google Search carousel structured data documentation.

Carousel markup is valuable when it describes a real list, not when it is added merely to request a visual treatment.

The standard host carousel supports collections of Recipe, Course, Movie and Restaurant content when the applicable type-specific rules are also met.

ItemList provides list structure, but each entity still needs valid structured data for its own feature. A movie requires an accurate name and poster image; a recipe needs its dish name and completed-dish image; a course has provider and course requirements; a restaurant needs the applicable local-business facts. Do not assume that any arbitrary Article, Person, software tool or blog post becomes carousel-eligible because it appears in an ItemList. Keep every item in a standard collection the same supported type. Separate editorial lists when a page mixes recipes, products, places and videos.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Classify every visible item.
2. Choose one supported type.
3. Validate its detail requirements.
4. Remove unsupported entries.

Start with a supported content feature and then add ItemList; ItemList alone does not create eligibility.

A standard carousel can use a summary page linking to separate detail pages or an all-in-one page containing full entities at visible anchors.

In the summary model, the collection page displays short descriptions and each ListItem contains a one-based position plus a unique canonical URL for a detail page on the same domain. Each destination must contain valid structured data for that item type. In the all-in-one model, the page contains full information for every entity; each ListItem nests an item and the item URL points to an anchor near its visible section on the current page. Do not combine these models accidentally by nesting incomplete items while linking to absent anchors.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Map content locations.
• Use unique canonical destinations.
• Create real visible anchors.

Choose the page model that matches where users can find the complete information for each item.

ItemList must contain at least two ListItem entries for the standard carousel, with unique one-based positions that match the visible list order.

The itemListElement array is the ordered collection. Each entry uses @type: ListItem and a position integer beginning at one. Array order by itself is not a sufficient statement of semantic order; position is the durable signal. Summary entries add url, while all-in-one entries add a complete supported item. Do not reuse position values, leave gaps after filtering or retain entries deleted from the page. A CMS should generate both visible cards and JSON-LD from the same collection record to prevent drift.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Count visible items.
2. Assign sequential positions.
3. Add the correct destination model.
4. Regenerate after list edits.

A correct ItemList preserves membership, identity and order after every editorial change.

Summary-page carousel URLs must be unique same-domain canonical detail pages, while all-in-one URLs must target visible anchors on the current page.

For a standard summary page, a recipe collection cannot send one card to a social profile and another to an external marketplace. Each destination should focus on that item and expose valid type-specific markup. Canonical redirects, tracking parameters and locale alternates need consistent handling so two cards do not collapse to one final page. In the all-in-one model, the fully qualified URL includes a fragment that matches an actual HTML id or named anchor near the entity. Test links without relying on client state. Broken or duplicate destinations undermine both discovery and user trust.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Resolve redirects.
• Check canonical uniqueness.
• Test fragments and locale paths.
• Remove broken items.

Every carousel destination should open the exact visible item promised by its card.

The standard carousel and carousel beta are separate features with different content types, page models, item minimums and geographic availability.

The standard host carousel covers Recipe, Movie, Course and Restaurant, and supports summary or all-in-one architectures. The beta carousel covers Product, Event and LocalBusiness subtypes, requires a summary page plus standalone detail pages and at least three marked entities. The beta feature currently has limited availability in the EEA, Turkey and South Africa under documented query categories and participation routes; it is not a US carousel opportunity. For a US traffic strategy, do not cite the beta feature as available merely because Product appears in its documentation. Build for the standard feature where relevant and treat beta rules as region-specific, changeable requirements.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Identify the exact feature.
2. Check supported type and region.
3. Apply the correct page model.
4. Monitor beta requirement changes.

Keep standard and beta implementations separate so geography and eligibility claims remain truthful.

Carousel markup can increase a list’s visual and decision value when an eligible result appears, but CTR impact must be measured rather than promised.

A host carousel can expose several relevant options from one publisher, giving searchers more paths into a site. That can improve qualified clicks for query families matching the collection, but it may also distribute clicks across detail pages or satisfy some comparisons before a visit. Rank, device, query mix, title quality and image quality all influence observed CTR. Use Search Console page and query evidence, compare mobile and desktop separately, and track engagement on destination pages. Avoid manipulating positions solely to promote the highest-margin item when the visible list claims an editorial ranking based on another criterion.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Establish a baseline.
• Segment query and device.
• Measure detail-page engagement.
• Keep editorial ordering honest.

Optimize list usefulness and destination quality first, then assess CTR with segmented evidence.

Common mistakes include unsupported item types, too few entries, mixed standard types, duplicate positions, external URLs, missing anchors and structured lists that differ from visible content.

A plugin may wrap every archive in ItemList and call it a carousel even when the content type is unsupported. Summary pages sometimes link to retailer or social URLs, while all-in-one pages use fragments that do not exist. Client-side filtering can leave ten structured items when only six cards render, or lazy loading can expose more markup than the initially accessible list. Teams also apply beta Product rules to US pages, assume a mobile Movie carousel appears on desktop, or include genuine ratings from one entity on another card. Validators can catch syntax, but architecture and geographic claims need human review.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Identify feature and region.
2. Validate type and item count.
3. Open every URL or anchor.
4. Compare markup with rendered list.

The highest-risk mistake is applying rules from the wrong carousel feature or sending a card to the wrong entity.