How to format content for AI search: 80,761 of 104,474 list items were navigation

What the standard says a list element means

Three elements carry a list in HTML and they are not interchangeable. The HTML Standard, a Living Standard that carried the date 25 September 2026 when it was read on 27 September 2026 at html.spec.whatwg.org/multipage/grouping-content.html, defines the ul element as representing "a list of items, where the order of the items is not important", and the ol element as representing "a list of items, where the items have been intentionally ordered, such that changing the order would change the meaning of the document". The dl element it defines separately, as "an association list consisting of zero or more name-value groups (a description list)". The li element gets one sentence: it "represents a list item".

Those definitions matter here because only one of the three is in real use. Of the 20,664 list elements counted, 20,150 were ul, 300 were ol and 214 were dl. At page level the gap is starker: 867 of the 1,071 pages used at least one ul, 97 used any ol and 39 used any dl. The element whose whole purpose is to say that sequence carries meaning appears on fewer than one page in ten, and the one that says order is irrelevant is on four pages in five. That is a reasonable distribution for a home page, which is mostly not a procedure, but it is worth holding next to the advice to format for extraction: a numbered list is the only list markup that tells a machine the order is a claim, and almost nobody is sending one. The outlier is harvard.edu, whose home page carried 20 ordered lists against 2 unordered, the reverse of every other page measured.

Nesting is common and deep. 9,961 of the 20,664 lists sat inside another list, and the deepest chain ran to six levels on fiocruz.br. A list inside a list inside a list is the standard shape of a drop-down menu expressed in markup, which is the first hint about what most of this material is doing. The average list held 5.1 items, so these are not long enumerations of facts. They are short groups, repeated many times per page, which is again the shape of a menu rather than of an argument. None of this is a defect and none of it is a prose parity failure: the markup is valid, it renders, and a screen reader reads it correctly. It is also not what this scanner currently scores, and the methodology page is the place that says so: no sub-score reads a list element at all, so every figure below is a census rather than a grade. It is simply not the thing the formatting advice imagines it is.

Where the list markup actually sits

Every list was classified once, by its ancestors and nothing else. A list counts as navigation here when it sits inside a nav, header, footer or aside element, or inside any element whose role attribute declares navigation, banner or contentinfo. Those are the regions the platform itself names as furniture: the WAI-ARIA 1.2 specification, a W3C Recommendation dated 6 June 2023, defines the navigation role as "A landmark that contains a collection of navigational elements" and the main role as "A landmark that contains the main content of the document". Nothing about the classification involves reading the words.

15,417 of the 20,664 lists were navigation by that rule, and 80,761 of the 104,474 items. 77.30 percent of every list item on these pages is furniture. The word counts run the same way and harder: 242,253 of the 375,898 words sitting inside list items were inside a navigation region, and a navigation item averaged 3.0 words against 5.6 for one outside. Taken across the whole body rather than just the lists, 404,797 of 1,255,759 words on these pages sat inside a nav, header, footer or aside, which is a rate this scanner has reported before on a much smaller sample: 1,395 of 2,729 text blocks were navigation on five captured pages, carrying under a fifth of the words. At 1,071 pages the shape survives.

The per-page distribution is the part the aggregate hides. 428 of the 1,071 pages carried no list at all outside the navigation regions, and 230 of those 428 did carry lists, every single one of which was navigation. acehardware.com is the clearest case: 178 list elements holding 1,840 items, 5,817 words on the page, and not one list outside the header, nav and footer. hdfcbank.com carried 470 lists and 1,491 items with 1,438 of the items in navigation. The median page carried exactly one list outside the furniture. Meanwhile 198 pages carried no list element of any kind, and 66 of those were serving 500 words or more of prose, which is the honest counterexample to the advice: a page can be readable, substantial and entirely list-free.

The menus that are not in a nav element

Classifying by ancestor is the only rule a crawler can apply cheaply, and it undercounts. The HTML Standard says so itself, in a sentence that reads like a warning once you have the numbers: "Not all groups of links on a page need to be in a nav element". A footer column of links, a set of category tiles, a language switcher and a related-articles rail are all lists of links, all conforming, and none of them has to declare itself.

So the 5,247 lists that sat outside the navigation regions were tested a second way, on a rule with nothing to do with position. A list counts as a menu here when it holds two or more items and every one of those items contains link text and no other words. 1,981 of the 5,247 passed that test, holding 11,186 of the 23,713 items counted outside navigation. Just under half of the list items that survived the first filter are links and nothing but links. ulisboa.pt carried 78 such lists outside its navigation regions, rakuten.co.jp 75 and kayak.com 66. Subtract them, and subtract the 886 lists outside navigation that held exactly one item, and 2,380 lists remain out of the original 20,664: lists of two or more items, outside the furniture, carrying words that are not purely a link. That is 11.5 percent of the list markup on these pages, and it is the part a formatting instruction is actually talking about.

Two things follow, and only one of them is about the sites. The first is for anyone writing the advice: telling a publisher to add bullet points to a page where 88.5 percent of the existing list elements are navigation, a menu or a list of one is instruction without a mechanism, because nothing in the markup distinguishes the new list from the old ones. A publisher who wants to see the difference has to look at what a crawler actually receives rather than at the rendered page, where a menu and a list of facts look nothing alike. The second is for anyone building a reader, this scanner included. A boilerplate filter keyed on nav, header and footer catches 15,417 of the lists here and misses 1,981 more that behave identically, which is the same class of error as three table elements on five real pages where all three were navigation and the reason table markup is worth so little of what it appears to promise. The all-links test is a heuristic and it will have its own false positives: a genuine link roundup is a list of links and is also content.

The one declaration that would separate the two

HTML has an element for this and it is not new. MDN's reference for the main element, last modified 10 September 2026, states that it "represents the dominant content of the body of a document" and that its content "should be unique to the document", adding that content repeated across a set of documents "such as sidebars, navigation links, copyright information, site logos, and search forms shouldn't be included unless the search form is the main function of the page". The HTML Standard puts the same idea in one line, that the main element represents the dominant contents of the document, and adds a hard constraint: "A document must not have more than one main element that does not have the hidden attribute specified".

338 of the 1,071 pages declared neither a main element nor a role of main. On those pages nothing in the delivered markup says which region is the content, so a reader has to guess from position, density or heuristics, and this scanner has already measured what that guess is worth: deleting the main element from five captured pages cut the extracted corpus from 13,615 words to 11,950, and on one of the five the landmark was worth 43 percent of the text. canadiantire.ca served 11,278 words with no main element and six lists. hdfcbank.com served 6,358 words, 470 lists and no main element. 27 further pages declared more than one main landmark, counting main elements and a role of main together. The standard's constraint applies to main elements without the hidden attribute and this run did not read that attribute, so the 27 is a count of declared landmarks rather than of confirmed violations; on hookagency.com the ten were ten main elements, and a document with ten dominant regions has told a machine nothing it can use. It is the same class of defect as a head carrying two descriptions, which is where 43 of 1,083 home pages ended up: the field exists, it is populated twice, and the duplication destroys the signal the field was for.

The split runs along tooling rather than along care, the same pattern found when 412 of 1,080 home pages named their site in neither source Google reads first. 35 of the 42 readable Bubble pages declared no main, and 27 of 42 Webflow pages, against 1 of 54 on Wix and Squarespace and 1 of 34 Shopify storefronts. A hosted theme emits the landmark and a page built block by block does not, which means the declaration is a property of the generator more than of the publisher. 108 of the 338 pages with no main also carried no words inside a nav, header, footer or aside, so on those pages neither half of the distinction is declared: there is no stated content region and no stated furniture, just a div tree. Whether any AI crawler weights the landmark is not something this run can answer, and no crawler vendor publishes that it does.

How to format content for AI search, if the markup is already there

The practical answer these figures support is narrower than the usual advice and it is not about adding bullets. Declare which region is the content, because 338 pages here do not and the one element that does it costs nothing. Use ol when the order is a claim, because 97 pages in 1,071 do and it is the only list markup that carries that meaning. And if a list is genuinely a set of facts rather than a set of links, say so as data rather than only as formatting, because there is a vocabulary for exactly that and almost nobody is using it.

schema.org's ItemList type is blunt about the distinction in its own description: a list of items of any sort, "Not to be confused with HTML lists, which are often used only for formatting". The entry reports a usage band of 1 million to 10 million domains, attributed to monthly aggregations from Google web index data for August 2026. On this corpus the rate is far below that. Re-reading the same 1,071 home pages the same day, 1,068 answered again and 613 carried at least one parseable JSON-LD block, a denominator consistent with the 615 found the previous day when 313 of 615 pages gave no schema node an @id. 17 of the 1,068 declared an ItemList. Between them they held 59 nodes covering 541 declared items, against 104,474 list items in HTML on the same pages. All 59 nodes carried itemListElement, 47 carried numberOfItems and 5 carried itemListOrder, so the ones that exist are well formed; there are just seventeen of them. 265 pages carried five or more lists outside their navigation regions and declared no ItemList at all.

Two of the seventeen are worth naming because they run in opposite directions. theglobeandmail.com declared 39 ItemList nodes covering 68 items, which is a news front page describing its own sections as data. france24.com declared a single ItemList of 102 items on a page where every HTML list sat inside a navigation region, so the structure a machine can read as content exists only in the JSON-LD. That is the inverse of the default case, and it is the only arrangement measured here where the declared structure and the visual structure disagree in the publisher's favour. It is worth saying plainly that no citation, ranking or retrieval outcome was measured in any of this, so nothing here shows that an ItemList earns anything, and the honest state of the evidence on structured data generally is thinner than the advice around it. What the figures support is a statement about what is declared, not about what it buys.

None of this replaces the earlier work in this series, and it sits next to it rather than above it. 311 of 704 article pages ran over 300 words with no heading, 84 of 1,091 home pages offered a crawler no internal path at all, 18,171 of 52,077 images carried an empty alt attribute, and on 11 of 271 pages JavaScript supplied all of the prose. Formatting is the last of those problems to matter, because a page whose text never arrives cannot be badly formatted, and the ordering is the whole reason AI visibility is measured access first and presentation last. The reason it is worth a measurement anyway is that formatting is the part of generative engine optimization and answer engine optimization most often sold as a checklist item, and on these pages the checklist item was already ticked 104,474 times over.