ItemList schema

What ItemList actually is, beyond the spec line

Open any page ranking for a « best X » query and you will find the same three layers: a visible ordered list, an internal link to each item, and, if the developer did the work, an ItemList block in the head. That block does not describe a page, it describes a collection. Three properties carry the weight in practice: itemListElement, which holds the members, itemListOrder, which tells a parser whether the sequence is meaningful, and numberOfItems. The rest is decoration.

Two implementation patterns exist and they are not interchangeable. The summary form gives each ListItem a position and a url pointing at a separate page, so the list acts as a table of contents for content living elsewhere. The all-in-one form nests the full entity inside each ListItem, so the list is self contained and the parser never fetches anything. Google's carousel documentation uses the first pattern; a comparison page holding every spec on a single URL is the second. Mixing the two inside one list is the most common way a valid looking block becomes unusable.

The part most implementations miss: ItemList is structural, not descriptive. It says « these things belong together, in this order ». It says nothing about what the things are. If each member is not itself a valid Product, Event, LocalBusiness or Article, you have shipped an empty envelope. That is why the real work in a list implementation is almost never in the ItemList itself, it is in the per item markup underneath, and why the shared vocabulary both Google and Bing read rewards depth over wrapper hygiene.

The carousel beta changed what ItemList is for

In August 2025 Google introduced Structured Data Carousels in beta, rolled out first in South Africa, built on exactly this shape: an outer ItemList containing multiple ListItem entries, with eligible content types including LocalBusiness, Product, Event and related verticals. On 21 January 2026, according to PPC Land, Google extended that South African carousel to further query categories including food delivery, car hire and bus booking, and businesses already using the supported structure qualified without adding new markup.

Read that rollout carefully before briefing a developer. It was geographically limited, vertical specific, and it did not turn generic list markup into a SERP feature. Third party implementation documentation reports that carousel eligibility generally requires at least two items, and that some vertical carousels such as Course List require three or more. Those are floors, not targets. Wrapping an ItemList around your eight latest blog posts produces no carousel in any market, and it never did.

The honest 2026 position: ItemList finally has a concrete SERP use case, but only inside Google's supported carousel verticals and supported countries. Everywhere else it remains machine documentation. That is not worthless, it is a different value proposition, and one nobody should present to a client as a rich result. If your vertical is not on the list, the correct expectation is zero visual change and a cleaner entity graph.

Google is pruning rich results, which reframes the bet

On 12 June 2025, as reported by Search Engine Land, Google retired seven structured data features: Book Actions, Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement and Vehicle Listing. Search Console reporting followed them out, and deprecated Search Console export fields were scheduled to return NULL from 1 October 2025. In November 2025 Google confirmed it was not abandoning structured data in general, while phasing out Practice Problem support from Search, Search Console and the Rich Results Test starting January 2026, and clarifying that Dataset markup serves Dataset Search rather than general rich results.

Two details in that sequence deserved more attention than they got. Book Actions was pulled back off the deprecation list in November 2025 because a Search feature still used the markup, which is a solid argument for checking Google's own documentation rather than a blog post's « retired schema » table. And on 7 May 2026 FAQ rich results stopped appearing in Google Search entirely. That does not touch ItemList directly, but it confirms the direction of travel: fewer visual enhancements, selectively supported. If you still maintain a FAQPage block on every single template, that is now maintenance with no SERP payoff attached.

No Google announcement makes ItemList a ranking factor, and none deprecates it either. The defensible reading is that Google is cutting underused rich result types while expanding a small number of list based experiences. That asymmetry is the entire argument for keeping list markup clean: it sits on the side of the ledger that is growing rather than the side being pruned.

Where it pays in an SEO and netlinking operation

Comparison pages, ranked selections and directory style category pages are the pages that both convert and attract editorial links. Across the editorial media we run in-house, the pages picking up spontaneous citations are almost always ranked selections, not essays. ItemList does not earn that link, the selection work does, but it makes the page structure explicit to every parser reading it, and that matters slightly more each quarter.

Machine legibility is where the 2026 argument actually lives. Google expanded AI Mode on 7 October 2025 to more than 35 languages and over 40 additional countries and territories, bringing availability past 200 countries and territories. Semrush, analysing more than 10 million keywords, found AI Overviews on 6.49% of queries in January 2025, 7.64% in February and 13.14% in March, and later 2025 reporting on the same dataset showed those triggers broadening out of purely informational queries into commercial, transactional and navigational ones. That shift is what makes structured product, event, course and business lists strategically more interesting than blog list markup. What it does not do is make ItemList a citation signal: Google has never claimed that, and neither should anyone selling GEO work.

Measure accordingly. Google launched dedicated Search Console reports for generative AI visibility on 3 June 2026, covering Search and Discover, and those numbers tell you far more than a green tick in a validator. A 2025 professional survey cited in 2026 reporting put structured data at 21.8% of respondents seeing a positive impact, against 16.4% for backlink acquisition and 22.9% for internal linking. Treat that as practitioner sentiment rather than a causal experiment, because that is exactly what it is. The useful reading is not « schema beats links », it is that on-page and the way you wire pages to each other should be fixed before authority gets pointed at them. When acquisition does come, picking the host media yourself from a public catalogue beats delegating that choice to someone taking a margin on it.

What we see go wrong

The recurring failure is markup describing something the page does not show. Google's structured data policies require marked up content to be visible to users, so a list of ten items where only three render is a quality problem waiting for a manual review, not a shortcut to a carousel. Positions fail the same way: they start at 1, they increment, and duplicating a position or leaving gaps makes the ordering meaningless to a parser that reads itemListOrder as a promise about the sequence.

Second failure, treating validation as eligibility. The Rich Results Test only reports features it supports. A perfectly valid ItemList outside a supported carousel vertical returns nothing, and teams read that silence as a bug. It is not a bug, it is the answer. Validate syntax in the Schema Markup Validator, check eligibility against Google's current documentation for your specific vertical and market, then stop.

Third, the injection problem. List markup pushed through a tag manager after render, or generated client side on a page Google renders slowly, is markup that may never be read. Ship it server side in the JSON-LD block Google recommends, inside the initial HTML response. And keep the per item types complete: a carousel needs each entry to be a valid entity with its own required properties, so polishing the wrapper while the Product entries lack price or availability is wasted effort.

Last, the strategic mistake. Teams add list markup to pages that have no business being lists, then wonder why nothing moved. Structured data of any kind describes a page, it does not improve one. If the underlying selection is thin, ItemList makes a thin page machine readable, which is not an outcome anybody is paying for.

Shipping it without wasting a sprint

Decide the pattern before anyone opens an editor: summary form when each item owns a URL, all-in-one form when the page holds the full detail. That single call determines whether you need internal links or nested entities, and reversing it later means rewriting the template rather than editing a block.

Then treat it as a template job, never an editorial one. List markup belongs to the page type and should be generated from the same data that renders the visible list, so ordering, count and content cannot drift apart. Hand written blocks living in a CMS field drift within a quarter, every time, on every site we have audited.

Check eligibility once per vertical and market rather than once per page, because that is the level at which Google's support actually varies. Then instrument properly: a Search Console appearance filter if your feature has one, the generative AI visibility reports for the surfaces that do not, and organic performance on the whole template as the real read. If those numbers stay flat, the list itself is the problem, and no amount of markup repairs a selection nobody wants to cite. Schema work is cheap and durable, which is precisely why it should never be the line item that eats a quarter.