ItemList Schema

TL;DR — ItemList is a bit of schema.org code that says “this page is a list of things, in this order.” The two important parts are the list of entries (itemListElement) and a rank number on each one (position). By itself it does not get you a fancy search result — Google’s swipeable Carousel is built on top of ItemList, and only shows up when you pair it with one of a few specific content types (recipes, movies, courses, restaurants). It won’t help you rank higher, either.

What ItemList schema is

When you build a “Top 10” page, or a recipe roundup, or a list of courses, you can see it’s a list. A search engine mostly sees a wall of text and some HTML. ItemList is a small block of structured-data code that spells it out: “this is a list, here are the items, and here’s the order they go in.”

Schema.org describes it as “A list of items of any sort—for example, Top 10 Movies About Weathermen, or Top 100 Party Songs.” It also adds a clarifying line worth remembering: “Not to be confused with HTML lists, which are often used only for formatting.” An ordinary <ol> or <ul> makes a list look like a list; ItemList makes it mean a list to a machine.

Two properties do almost all the work:

• itemListElement — the list of entries. Each entry is usually a ListItem.
• position — a number starting at 1 that says where each entry ranks in the list.

The one thing everyone gets wrong

Adding ItemList by itself does not get you a special search result. This is the top misconception, so it’s worth stating plainly. ItemList is the mechanism; the visible payoff — a swipeable set of cards in Google’s results — is a separate feature called a Carousel. And a carousel only appears when you combine ItemList with one of a short, Google-controlled list of content types (for the classic carousel: Course list, Movie, Recipe, Restaurant). A generic “Top 10 blog posts” page marked up with plain ItemList doesn’t earn that display.

There’s also a family connection that surprises people: breadcrumbs use the same mechanism. BreadcrumbList — the schema behind those “Home › Category › Page” trails — is technically a type of ItemList. Same itemListElement, same position. Once you learn one, you’ve mostly learned the other.

Why it matters (and what it doesn’t do)

• It can make you eligible for a carousel — if you have a supported content type and everything else is right. Eligible isn’t the same as guaranteed, either: Google says plainly it doesn’t guarantee that features consuming structured data will actually show up in search results.
• It helps machines understand your page is a structured list. That’s the container’s job — I’m not going to claim a broader “helps AI systems read your page” payoff on top of that without Google publishing something specific to point to.
• It does not improve your rankings. Like all structured data, ItemList is not a ranking factor. Google has been consistent on this for years.

Want the full picture — the two implementation patterns, the exact supported types, the newer geo-limited beta carousel, how BreadcrumbList fits in, and the common validation failures? Switch to the Advanced tab.

TL;DR — ItemList is schema.org’s generic ordered-list container; itemListElement

• a 1-based position do the work, with itemListOrder and numberOfItems as lesser-used extras (numberOfItems matters for paginated lists). It is not itself a rich result — Google’s Carousel is built on top of it and only fires with a supported companion type: Course list, Movie, Recipe, Restaurant for the classic carousel, and LocalBusiness/Product/Event for a newer beta that’s geo-gated to the EEA, Turkey, and South Africa. Two patterns: summary-page (url-only ListItems) and all-in-one (nested items). Rules: 2+ items (3+ for the beta), all the same type on the classic carousel (the beta allows mixing), markup must match visible content. BreadcrumbList is formally a subtype of ItemList (with HowToSection, HowToStep, OfferCatalog) — the detail most guides miss. And structured data is not a ranking factor — its payoff is eligibility and understanding, not position.

What ItemList actually is

Schema.org’s definition is deliberately broad: “A list of items of any sort—for example, Top 10 Movies About Weathermen, or Top 100 Party Songs.” The line that explains why the type needs to exist is the next one: “Not to be confused with HTML lists, which are often used only for formatting.” An <ol>/<ul> conveys “these are a list, in this order” purely by visual convention. ItemList declares the container (ItemList), each entry (ListItem), and each entry’s rank (position) as data a machine can read without inferring anything from layout.

Two properties do the heavy lifting:

• itemListElement — the array of entries. Schema.org: “For itemListElement values, you can use simple strings (e.g. ‘Peter’, ‘Paul’, ‘Mary’), existing entities, or use ListItem.” For anything that wants a URL or a position (i.e. anything aiming at a rich result), you use ListItem.
• position — a 1-based integer giving each ListItem its rank.

Two more are documented but skipped by most guides:

• itemListOrder — “Type of ordering (e.g. Ascending, Descending, Unordered).” A declaration, not something Google enforces.
• numberOfItems — “The number of items in an ItemList. Note that some descriptions might not fully describe all items in a list.” This one earns its keep on paginated lists: a “Top 100” split across five pages can use numberOfItems to state the full count even though any one page marks up only twenty entries.

(There’s also aggregateElement for holding aggregate ratings/offers across the list — genuinely niche; you’ll rarely touch it.)

The two implementation patterns

Google’s carousel documentation describes two shapes, and which one you use changes what each ListItem looks like:

Summary page and multiple detail pages

A summary page lists each item briefly, and each entry links out to a dedicated detail page. Here the ListItem is minimal — Google: the summary page defines an ItemList where each ListItem has only three properties: @type (set to ListItem), position (the position in the list), and url (the canonical URL of the item’s detail page). The full per-item structured data (the Recipe, the Movie, etc.) lives on each detail page.

All-in-one summary page

Everything lives on one page, so each ListItem carries a nested item containing the full companion-type markup (the whole Recipe object, for instance) rather than just a url. Use this when there are no separate detail pages.

ItemList is not the Carousel — this is the core distinction

Here’s the accuracy spine of the whole topic. ItemList is a container; Carousel is a rich result built on top of it. ItemList alone, with no supported companion type, does not produce a distinct “list” rich result in classic Google Search. Google’s docs are explicit that carousel eligibility requires both pieces.

Classic Carousel — the supported types

To be eligible for a host carousel rich result, you add ItemList structured data in combination with one of a small, Google-controlled set of supported features. As of Google’s current (2026) documentation, that list is:

• Course list
• Movie
• Recipe
• Restaurant

That’s it for the classic carousel. Other types — Product, BlogPosting, Event — can carry ItemList markup for organization and machine understanding, but that alone does not make them classic-carousel-eligible.

Carousels (Beta) — the newer, geo-gated program

There’s a second, newer program — Carousels (Beta) — that Google describes as “a list-like rich result that people can scroll horizontally to see more entities from a given site.” It’s the more actively-evolving part of this feature area, and it differs from the classic carousel in three important ways:

• Different supported types: ItemList combined with LocalBusiness and its subtypes (Restaurant, Hotel, VacationRental), Product, or Event — a broader and different set than the classic four.
• Geographically limited: it’s available only in EEA countries, Turkey, and South Africa, on desktop and mobile, with the eligible query types varying by region. This is not a global feature — a caveat worth stating plainly, since several third-party write-ups discuss it as if it’s generally available.
• A higher minimum: the beta requires a summary page plus detail pages with at least three itemListElement.item entries, versus the classic carousel’s two.
• Mixing is allowed: unlike the classic carousel’s strict same-type rule, Google’s beta documentation says you “can mix and match different types of entities (for example, hotels, restaurants), if needed for your scenario” — don’t carry the classic same-type assumption over when you’re working with the beta.

Treat the beta as “watch this space” rather than a stable, universal feature.

How BreadcrumbList (and a few others) relate to ItemList

This is the single most under-covered, differentiating fact about ItemList, and it clears up a common point of confusion: BreadcrumbList is not a separate, unrelated schema type — it is formally a subtype of ItemList. Schema.org states it directly: “A BreadcrumbList is an ItemList consisting of a chain of linked Web pages, typically described using at least their URL and their name, and typically ending with the current page.” And schema.org’s own “More specific Types” list for ItemList is exactly four entries: BreadcrumbList, HowToSection, HowToStep, and OfferCatalog.

Practically, that means the itemListElement + position mechanics you use for a carousel are literally the same ones you use for breadcrumbs — only the outer @type (BreadcrumbList vs. plain ItemList) and the semantic purpose change. Google frames breadcrumbs the same way: to specify breadcrumbs, you define a BreadcrumbList containing at least two ListItems. If you’ve implemented one, you already understand the other. (The breadcrumb side of this family lives in its own deep dive, and the visible carousel result is the subject of a sibling carousel piece — both sit in this same structured-data sub-cluster.)

Implementation requirements and common validation failures

Most carousel/ItemList failures come down to a handful of documented rules:

• Minimum item count. Google requires the itemListElement array to contain two or more ListItem elements for the classic carousel (three or more for the beta). One item is not a list.
• Same-type rule (classic carousel) — the frequent real cause of failures. Google: “All items in the list must be of the same type. For example, if a list is about recipes, only include Recipe items. Don’t mix different types.” A list that mixes Recipes and Products won’t validate as a classic carousel. This rule is specific to the classic program — the beta above explicitly permits mixing entity types, so don’t carry the same-type assumption over when that’s the program you’re targeting.
• Visible-content parity. A general structured-data policy that’s called out specifically here: the text visible to the user must be similar to the information in the structured data. You can’t mark up items that aren’t genuinely represented in the visible page.
• Same-domain URLs. A host carousel shows cards from the same site; the item URLs should be on your own domain.
• Standard structured-data hygiene applies. JSON-LD is Google’s recommended format, all required properties for your companion type must be present (“Items that are missing required properties are not eligible for rich results”), and you must not block the marked-up pages from Googlebot via robots.txt or noindex. These are the same general guidelines that govern every rich-result type — the broader structured-data hub covers them in full.

Does ItemList schema affect rankings? (No.)

Short answer: no. Structured data is not a ranking factor, and that includes ItemList. This is Google’s consistent, repeated position. At Search Central Live APAC 2025, Gary Illyes made the point that “excessive or redundant schema only adds page bloat and has no additional ranking benefits,” framing schema as an aid to entity understanding and machine features — explicitly not part of the ranking process. Google’s standing position across recent years is the same: structured data is not a ranking signal, and even in cases of structured-data misuse the consequence is loss of rich-result eligibility (via a manual action), not a ranking penalty.

Where does the value come from, then? Two places: rich-result eligibility (a carousel can lift click-through, not position) and machine understanding. On the second point, John Mueller — speaking personally, and explicitly “not official guidance” — noted in early 2026 that some features genuinely benefit from structured data, giving the example that “pricing, shipping, availability for shopping is basically impossible to read in high fidelity & accurately from a text page.” That’s the honest frame: ItemList helps machines understand a structured list; it does not rank it higher.

ItemList vs. CollectionPage — a quick disambiguation

These get confused because both apply to “listing” pages, but they answer different questions. ItemList describes an ordered list of discrete items — the entries and their positions. CollectionPage is a page type that represents a themed collection; it’s about page-level semantics (“this page is a collection of things”) rather than the ordering of specific list items. They’re not mutually exclusive — a category page can be a CollectionPage that also contains an ItemList of its products — but reach for ItemList when what you want to express is “here are the ranked items,” and CollectionPage when you want to express “this page is a curated collection.”

Where this fits

ItemList is a deep dive under the broader structured data hub, alongside the sibling pieces on the visible carousel rich result (ItemList’s main Google application) and on BreadcrumbList (formally a subtype of the very same mechanism). For the fundamentals that govern every type here — the schema.org vocabulary, JSON-LD, the “not a ranking factor” spine, and the shrinking list of supported rich results — see the Structured Data hub. That sub-cluster lives inside the broader on-page SEO cluster.

AI summary

A condensed take on the Advanced version:

• ItemList = a generic schema.org list container. “A list of items of any sort.” itemListElement (the entries, usually ListItem) + a 1-based position do the work; itemListOrder and numberOfItems are lesser-used extras (numberOfItems matters for paginated lists).
• ItemList is NOT a rich result by itself. Google’s Carousel is built on top of it and only fires with a supported companion type. This container-vs-rich-result distinction is the top misconception.
• Classic Carousel supported types: Course list, Movie, Recipe, Restaurant — pair one with ItemList to be eligible (never guaranteed).
• Carousels (Beta) is a separate, newer program: LocalBusiness/Product/Event, geo-gated to the EEA, Turkey, and South Africa, minimum three entities. Not globally available.
• Two implementation patterns: summary-page (ListItems with just @type/position/url, detail markup on separate pages) and all-in-one (each ListItem nests the full item).
• BreadcrumbList is a formal SUBTYPE of ItemList (with HowToSection, HowToStep, OfferCatalog). Breadcrumbs and carousels share the exact same itemListElement/position mechanics.
• Rules that cause most failures: 2+ items (3+ beta), all the same type on the classic carousel (the beta allows mixing), and markup must match visible content.
• Not a ranking factor. Illyes (2025): redundant schema is “page bloat” with “no additional ranking benefits.” Value = rich-result eligibility + machine understanding; misuse costs eligibility, not rankings. Mueller (personally, “not official guidance”) notes schema helps for hard-to-parse data like pricing/availability.
• ItemList vs. CollectionPage: ItemList = an ordered list of discrete items; CollectionPage = a page type for a themed collection. Not mutually exclusive.

Official documentation

Primary-source documentation from Google and schema.org.

Google

• Carousel (ItemList) Structured Data — the classic host carousel: supported types (Course list, Movie, Recipe, Restaurant), the summary-page vs. all-in-one patterns, the 2+ items and same-type rules.
• Carousels (Beta) Structured Data — the newer, geo-gated program (LocalBusiness/Product/Event; EEA, Turkey, South Africa; 3+ entities).
• Breadcrumb (BreadcrumbList) Structured Data — the breadcrumb application of the same ItemList mechanism.
• Structured Data General Guidelines — the policies that apply to ItemList as to every type: visibility, accuracy, required properties, no robots.txt/noindex blocking.

schema.org

• ItemList — the type itself: the definition, the HTML-list distinction, itemListElement/itemListOrder/numberOfItems, and the “More specific Types” list confirming the subtypes.
• BreadcrumbList — confirms, from the other direction, that BreadcrumbList is an ItemList.
• ListItem — the entry type that carries position, url, and item.

Quotes from the source

On-the-record statements from Google and schema.org. Where a page exposes the text, the link is a deep link that jumps to the quoted passage.

schema.org — what ItemList is

• “A list of items of any sort—for example, Top 10 Movies About Weathermen, or Top 100 Party Songs.” — schema.org, ItemList. Jump to quote
• “Not to be confused with HTML lists, which are often used only for formatting.” Jump to quote
• On itemListElement: “For itemListElement values, you can use simple strings (e.g. ‘Peter’, ‘Paul’, ‘Mary’), existing entities, or use ListItem.” Jump to quote

schema.org — BreadcrumbList is an ItemList

• “A BreadcrumbList is an ItemList consisting of a chain of linked Web pages, typically described using at least their URL and their name, and typically ending with the current page.” — schema.org, BreadcrumbList. Jump to quote

Google — the same-type rule

• “All items in the list must be of the same type. For example, if a list is about recipes, only include Recipe items. Don’t mix different types.” — Google Search Central, Carousel documentation. Jump to quote

Gary Illyes, Google (Search Central Live APAC 2025, via Search Engine Journal’s write-up)

• Excessive or redundant schema “only adds page bloat and has no additional ranking benefits” — schema helps entity understanding and machine features, but is not part of the ranking process. Read the coverage

John Mueller, Google (Reddit, reported Jan 2026 by Search Engine Roundtable — explicitly framed as personal opinion, “not official guidance”)

• On where schema genuinely helps: “Pricing, shipping, availability for shopping is basically impossible to read in high fidelity & accurately from a text page, for example.” Read the coverage

ItemList — cheat sheet

The properties

Classic Carousel vs. Carousels (Beta)

The rules that break validation

• Fewer than the minimum items (2 classic / 3 beta).
• Mixed item types on the classic carousel — all items must be the same type there (the beta allows mixing).
• Markup that doesn’t match visible on-page content.
• Item URLs off your own domain (host carousels are same-site).
• Missing required properties on the companion type.

Fast facts

• ItemList alone is not a rich result — you need a supported companion type for a carousel.
• BreadcrumbList is a subtype of ItemList (with HowToSection, HowToStep, OfferCatalog).
• Not a ranking factor — value is eligibility + machine understanding.
• JSON-LD is Google’s recommended format.
• ItemList vs. CollectionPage: ordered list of items vs. a themed-collection page type.

Do I need ItemList — and will it get me a carousel?

Work down the questions; each answer points you to the right move.

1. Is your page genuinely a list of discrete, ranked/ordered items?

• No → ItemList isn’t the right type. If the page is a themed collection, look at CollectionPage instead. If it’s a breadcrumb trail, that’s BreadcrumbList (a subtype of ItemList, but with its own required shape).
• Yes → continue.

2. Are those items one of the carousel-supported types?

• Course list / Movie / Recipe / Restaurant → you’re eligible for the classic Carousel (global). Continue to 3.
• LocalBusiness / Product / Event → you can only get a carousel via the Carousels (Beta) program, which is limited to the EEA, Turkey, and South Africa and needs 3+ entities. Elsewhere, your ItemList still helps machine understanding but won’t produce a carousel.
• Anything else (blog posts, generic “Top 10”) → plain ItemList is fine for structure and understanding, but it will not produce a carousel rich result. Don’t expect one.

3. Do you have separate detail pages for each item?

• Yes → use the summary-page pattern: each ListItem needs only @type, position, and url; put the full companion-type markup on each detail page.
• No, everything’s on one page → use the all-in-one pattern: each ListItem nests the full item markup.

4. Final eligibility checks before you expect a carousel:

• 2+ items (3+ for the beta)? · All the same type (classic only — the beta allows mixing)? · Markup matches visible content? · Item URLs on your own domain? · Required companion-type properties present? · Page not blocked by robots.txt/noindex?
• All yes → you’re eligible. Remember Google still decides whether to actually render it — rich results are never guaranteed.

Reality check: none of this lifts rankings. The upside is a possible carousel (better click-through) and cleaner machine understanding — not a higher position.

Common ItemList/carousel problems and how to fix them

Symptom-cause-fix lookups for the situations that actually stop a carousel from appearing, or that break the BreadcrumbList side of the same mechanism.

The markup validates clean, but no carousel ever appears

Likely cause: ItemList by itself is not a rich result — a carousel only fires when ItemList is paired with a supported companion type (Course list, Movie, Recipe, Restaurant for the classic carousel; LocalBusiness/Product/Event for the geo-gated beta). If the page’s items are a type outside those lists (a generic “Top 10 blog posts,” for instance), the ItemList is doing its job for machine understanding but was never going to produce a carousel. Fix: confirm the companion type is one of the supported ones for the program you’re targeting; if it isn’t, don’t expect a carousel — remember that even fully eligible markup only makes you eligible, never guaranteed, since Google still decides whether to render it.

The list validates but Google flags a same-type or count error

Likely cause: the two most common structural failures — mixing item types on the classic carousel (“All items in the list must be of the same type… Don’t mix different types”) or having fewer than the minimum (2+ for the classic carousel, 3+ for the beta). If you’re targeting the beta instead, mixed types aren’t your problem — Google’s beta docs explicitly allow mixing entity types when the scenario calls for it. Fix: for the classic carousel, check every ListItem in itemListElement is the same schema.org type; for the beta, skip that check and confirm the entry count against the right minimum for the program you’re pairing with instead.

The carousel doesn’t render even though item count and type are correct

Likely cause: visible-content parity — the text visible to the user must be similar to the information in the structured data, and the item URLs should be on your own domain for a host carousel. A list that marks up items not genuinely represented on the visible page, or that points at off-domain URLs, fails this general structured-data policy even when the ItemList shape itself is technically correct. Fix: check each marked-up item is genuinely visible on the page (or, in the summary-page pattern, that each detail page carries the full companion-type markup) and that URLs resolve on your own domain, then re-validate.

Breadcrumbs (or another ItemList subtype) fail the same way

Likely cause: because BreadcrumbList is formally a subtype of ItemList sharing the same itemListElement/position mechanics, the same structural mistakes — too few items, mismatched visible content — break breadcrumb eligibility too. Fix: apply the same checks (minimum items, visible-content match) to the BreadcrumbList markup as you would to a carousel ItemList; if you’ve debugged one, you already know how to debug the other.

Worked examples: the two ItemList patterns

The article above describes summary-page and all-in-one patterns in prose only — here’s what each actually looks like as JSON-LD, plus how BreadcrumbList reuses the exact same shape.

Pattern 1 — summary page + separate detail pages

Each ListItem carries only @type, position, and url; the full Recipe/Movie/etc. markup lives on the linked detail page, not here.

{
  "@context": "https://schema.org",
  "@type": "ItemList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "url": "https://example.com/recipes/lemon-bars"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "url": "https://example.com/recipes/banana-bread"
    }
  ]
}

• position is 1-based, not 0-based.
• url is the canonical URL of that item’s own detail page — the Recipe object itself is marked up over there, not nested here.
• This shape needs 2+ entries for the classic carousel (3+ for the beta), and every entry must be the same companion type on the far end.

Pattern 2 — all-in-one page (no separate detail pages)

Everything lives on one page, so each ListItem nests the full item object instead of just a url.

{
  "@context": "https://schema.org",
  "@type": "ItemList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "item": {
        "@type": "Recipe",
        "name": "Lemon Bars",
        "url": "https://example.com/recipes#lemon-bars"
      }
    },
    {
      "@type": "ListItem",
      "position": 2,
      "item": {
        "@type": "Recipe",
        "name": "Banana Bread",
        "url": "https://example.com/recipes#banana-bread"
      }
    }
  ]
}

• Use this when there’s no dedicated detail page per item — the whole companion-type object (Recipe here) nests under item.
• Both items are Recipe — mixing in a Product or Movie here would break the same-type rule and disqualify the whole list from carousel eligibility.

How BreadcrumbList reuses the same mechanism

BreadcrumbList is formally a subtype of ItemList — same itemListElement/position shape, just a different outer @type and semantic purpose:

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Recipes",
      "item": "https://example.com/recipes/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Lemon Bars"
    }
  ]
}

• Google requires at least two ListItems for a breadcrumb trail — the same “2+ items” mechanic as the classic carousel, just applied to page hierarchy instead of content items.
• The final crumb (the current page) typically omits item, since it has no further link target.

Tools for checking ItemList and carousel eligibility

• Rich-Result Eligibility Checker — paste your JSON-LD, an HTML page, or fetch a live URL and see, per type, which of Google’s rich results it qualifies for, including the Breadcrumb feature this article establishes as a subtype of ItemList — it flags the exact missing required field rather than just a generic pass/fail, which is the fastest way to see whether a BreadcrumbList (or a carousel companion type) is actually eligible.
• Schema Markup Validator — paste or fetch your JSON-LD and run it through severity-tiered structured-data validation: schema.org vocabulary checks, Google’s rich-result requirements, and cross-block @id graph checks, with a corrected copy-pasteable JSON-LD block back. Useful for catching the same-type mismatches and missing-property errors that are the most common cause of ItemList/carousel validation failures.
• Google’s Rich Results Test — Google’s own eligibility checker; a good second opinion once the two tools above come back clean, since it reflects Google’s live parsing rather than a third-party interpretation of the spec.

Confirming an ItemList/carousel change actually took effect

The checks below prove a specific ItemList or BreadcrumbList change works, in the order to run them, with the signal that means “undo this.”

Confirm the JSON-LD parses and hits the right eligibility bar

Test to run: paste the updated JSON-LD into the Rich-Result Eligibility Checker or the Schema Markup Validator. Expected result: the companion type (Recipe, Movie, Course list, Restaurant, or the beta’s LocalBusiness/Product/Event) shows as eligible, with no missing-required-property errors and no same-type mismatches flagged. Failure interpretation: a flagged missing property means the companion type’s own required fields aren’t present yet; a same-type warning means the itemListElement array mixes types, which disqualifies the whole list. Monitoring window: immediate — this is a point-in-time parse check, re-run right after any markup edit. Rollback trigger: if the checker reports new eligibility errors that weren’t there before the change, revert to the last known-passing JSON-LD while you investigate.

Confirm the item and minimum-count rules hold

Test to run: count the ListItem entries in itemListElement and check each one’s @type (on the nested item, or on the linked detail page for the summary-page pattern) against the same-type rule. Expected result: 2 or more entries for the classic carousel (3 or more for the beta), and every entry resolving to the identical companion type. Failure interpretation: fewer entries than the minimum, or a mixed-type list, means the ItemList is structurally valid JSON-LD but still won’t qualify for a carousel. Monitoring window: immediate — this is a static structural check against the current markup. Rollback trigger: if a content change drops the list below the minimum count, treat that as a regression and restore the removed items or pull the carousel-targeting markup until the count is back up.

Confirm Google actually renders the feature (not just eligibility)

Test to run: run the live page through Google’s Rich Results Test, then watch Search Console’s Enhancements report for the relevant carousel or breadcrumb feature over the following weeks. Expected result: Rich Results Test confirms the feature is detected with no errors, and the Enhancements report shows valid items with no new warnings. Failure interpretation: eligibility passing in a third-party tool but Google’s own test or Search Console showing errors usually means a policy issue (visible-content mismatch, blocked page) rather than a markup syntax problem. Monitoring window: a carousel’s actual appearance in search results is never guaranteed even when eligible, so treat 2–4 weeks of Search Console data as the point where you can judge whether the feature is being picked up at all. Rollback trigger: if Search Console starts reporting a rising error count for this item type after the change, revert the markup to the last version that showed zero errors.

Resources worth your time

My related writing

• Structured Data: What It Is and How to Use It — my Ahrefs guide to schema types, implementation methods, validation tools, and the sameAs entity angle; the broader context ItemList sits inside.
• The Beginner’s Guide to Technical SEO — where structured data (and lists like this) fit in the bigger picture.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawling, rendering, indexing, and ranking, for the context of where markup like ItemList does and doesn’t move the needle. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

Official

• Google — Carousel (ItemList) Structured Data and Carousels (Beta) — the two carousel programs, their supported types, and requirements.
• Google — Structured Data General Guidelines — the policies every rich-result type (ItemList included) has to satisfy.
• schema.org — ItemList and BreadcrumbList — the type definitions, and the subtype relationship confirmed from both directions.

From around the industry

• Google Search Central APAC 2025: Everything From Day 2 (Search Engine Journal) — Gary Illyes on schema, ranking, and “page bloat.”
• John Mueller (Personally) On If Schema Helps With LLMs & Google (Search Engine Roundtable, Jan 2026) — Mueller’s personal, non-official take on where structured data genuinely helps.
• What Is ItemList Schema? A Complete Guide (Greadme) — a solid third-party walkthrough of carousel eligibility conditions and the two implementation patterns.
• ItemList Schema (Rank Math KB) — plugin-oriented reference that separates “ItemList” from “Carousel” and covers both use-case patterns.

Test yourself: ItemList Schema

Five quick questions on what ItemList is — and isn’t. Pick an answer for each, then check.

ItemList Schema

ItemList is a schema.org type — a generic container for an ordered or unordered list of items ('a list of items of any sort'). Two properties do most of the work: itemListElement (the array of entries, usually ListItem objects) and position (a 1-based rank on each item). It's the underlying mechanism Google's Carousel rich result is built on, and BreadcrumbList is formally a subtype of it — but ItemList by itself is not a rich result and doesn't affect rankings.

Related: Structured Data, BreadcrumbList Schema, carousel rich result

ItemList Schema

ItemList is a schema.org type: a generic, machine-readable container for a list of things. Schema.org defines it as “A list of items of any sort—for example, Top 10 Movies About Weathermen, or Top 100 Party Songs,” and adds “Not to be confused with HTML lists, which are often used only for formatting.” That distinction is the whole point — an <ol> conveys “these are a list” only visually, while ItemList declares the container, each entry, and each entry’s rank in a way search engines and other machines can parse.

Two properties carry the load:

• itemListElement — the array of entries. Each entry is usually a ListItem, which can hold a position, a url, and/or a nested item.
• position — a 1-based integer giving each entry’s rank within the list.

Two others exist but are used less: itemListOrder (Ascending/Descending/Unordered — a hint, not enforced) and numberOfItems (the total count, useful when a list is paginated and one page’s markup doesn’t represent the whole set).

For SEO, the key nuance is that ItemList is plumbing, not a payoff. On its own it produces no distinct “list” rich result. Google’s Carousel rich result is built on top of ItemList — you add ItemList plus one of a short set of supported types (Course list, Movie, Recipe, Restaurant for the classic carousel) and Google may render a swipeable set of cards. BreadcrumbList is formally a subtype of ItemList (along with HowToSection, HowToStep, and OfferCatalog), which is why breadcrumbs and carousels share the same itemListElement/position mechanics. Like all structured data, ItemList is not a ranking factor — its value is rich-result eligibility and entity understanding.

Related: Structured Data, BreadcrumbList Schema, carousel rich result

Changelog