BlogFindings
31 disclosure widgets on five pages, and not one held an FAQ
Counted on 26 August 2026 across the five real pages this scanner captured on 15 July 2026, the details element appears 31 times, every one collapsed by default, and not a single summary label contains a question mark.
The advice that follows from this has become common enough to be worth checking: put your frequently asked questions inside details elements, the argument goes, and an answer engine will find a tidy question and answer pair sitting in the markup. It is a plausible argument. This post does not test whether it works, because nothing here observed a crawler. It tests something cheaper and prior to that, which is whether anybody is actually doing it. This repository stores five real pages twice, once as a plain HTTP client received them and once as a browser finished with them, and those ten documents are the only corpus available to count. On 26 August 2026 an HTML parser was run over all of them looking for one element.
In short
- The five real pages stored as golden fixtures in this repository, captured on 15 July 2026, carry 31 details elements between them, spread as 6 on astro.build, 3 on gymshark.com, 10 on the developer.mozilla.org HTML reference, 12 on webflow.com and none at all on the en.wikipedia.org Web crawler article.
- Not one of the 31 carries the open attribute, so every disclosure widget in the set starts collapsed, and not one of the 31 summary labels contains a question mark, so none of them is the FAQ accordion that generative engine optimisation advice keeps recommending.
- The 31 widgets hold 77 words of summary label and 1,834 words of body text, of which 334 words sit inside anchor elements and 1,500 do not, and all 1,500 of the non-anchor words are on webflow.com alone.
- Every one of those figures is identical in the raw HTTP response and in the rendered DOM on all five pages, so a client that never runs JavaScript received the collapsed text in the first response.
- Read out of core/src/extract.ts on 26 August 2026, neither details nor summary appears in DROP_TAGS or BLOCK_BOUNDARY_TAGS, so Lantad reads collapsed text as ordinary prose and has no check for the element at all.
| Page, captured 15 July 2026 | details | In boilerplate | In main | Summary words | Body words | Of those, anchor text |
|---|---|---|---|---|---|---|
| astro.build | 6 | 6 | 0 | 6 | 24 | 24 |
| gymshark.com | 3 | 3 | 0 | 4 | 39 | 39 |
| developer.mozilla.org HTML reference | 10 | 10 | 0 | 19 | 271 | 271 |
| webflow.com | 12 | 4 | 8 | 48 | 1,500 | 0 |
| en.wikipedia.org Web crawler article | 0 | 0 | 0 | 0 | 0 | 0 |
| Total | 31 | 23 | 8 | 77 | 1,834 | 334 |
What 31 disclosure widgets on five real pages actually held
Four of the five pages use the element and one does not. The English Wikipedia article on web crawlers carries no details element in either view, which is worth stating first because it is the only one of the five written primarily as a document rather than as an interface. The other four carry 31 between them, and they are not distributed the way a reader might guess: the two marketing homepages and the storefront account for 21 of the 31, and the reference documentation page accounts for the remaining 10.
The word counts are where the shape of the finding appears. Across all 31 widgets there are 1,834 words of body text, excluding the summary labels, counted once each so that the four nested widgets on the MDN page are not tallied twice inside their parents. Of those 1,834 words, 334 sit inside an anchor element. On astro.build the figure is 24 words of body text and 24 words of anchor text. On gymshark.com it is 39 and 39. On the MDN HTML reference it is 271 and 271. Three of the four pages that use the element put nothing inside it except links, to the word.
That is a menu, and the summary labels confirm it without any interpretation being required. They read Resources, Community, Enterprise, Help, My Account, Pages, Guides, Elements, Attributes, Global attributes, Attributes by element and Attribute values. The average label runs to two and a half words across all 31. This is the same pattern the extractor found when it counted text blocks on the same five pages and classified 1,395 of 2,729 as navigation, and the same pattern that turned up when every table element on these pages proved to be layout rather than data. A general-purpose HTML element gets adopted by the part of the page that has the most repetitive structure, which is the chrome, and the prose it was nominally designed to organise goes somewhere else.
Not one of the 31 summaries contained a question mark
The check for the FAQ claim is as blunt as it sounds. Every summary element in the set was extracted, its text flattened, and searched for a question mark. Across all 31 there are zero. There is no borderline case to argue about and no judgement call in the count: the corpus contains no interrogative label at all, so it contains no question and answer pair expressed through this element.
That is a negative result on four pages, and four pages establish nothing about the web. What it does establish is that the practice is absent from the only sample this repository can inspect, including on a page written by people who document the element for a living. The MDN HTML reference uses details ten times and every one of them is a navigation disclosure in the sidebar, four of them nested one level deep inside another. If the FAQ pattern were as widespread as the advice implies, a documentation site would be an odd place for it to be missing.
The second half of the check is the open attribute, and it comes out just as cleanly. Not one of the 31 carries it. MDN's reference for the details element, last modified 24 April 2026, describes open as a boolean attribute indicating whether the contents are currently visible, states that the details are shown when the attribute exists and hidden when it is absent, and adds the trap worth knowing: you have to remove the attribute entirely to hide the contents, because writing open="false" makes them visible. Every widget in this set is therefore closed on arrival. One of the four pages does carry a data-start-open="false" attribute of its own, which is authored markup rather than the standard one, and an early pass at this count matched the word open inside that string before the regular expression was tightened to require an attribute boundary. The figure of zero is the one that survived being checked properly.
-
Summary contains a question mark0 of 31 No interrogative label anywhere in the set, so no FAQ is expressed through this element on these five pages. -
Carries the open attribute0 of 31 Every widget arrives collapsed. MDN notes that open="false" would still show the contents, because the attribute is boolean. -
Nested inside another details4 of 31 All four sit in the developer.mozilla.org sidebar, one level deep inside a parent disclosure. -
Body text is entirely anchor text3 of 4 pages astro.build at 24 of 24 words, gymshark.com at 39 of 39, the MDN reference at 271 of 271.
One page typeset its marketing copy as JSON behind a button labelled Machine Mode
The webflow.com homepage is the outlier on every measure here, and it is worth describing exactly rather than summarising, because the markup is unusual. All 12 of its details elements carry a class of accordion-item is-machine-mode, they sit near a visible button whose text reads Machine Mode, and their summary labels are not words. Flattened to text, four distinct labels repeat three times each, and each one reads as a fragment of JSON: the label for the first is the string "@audienceType": "Marketer", followed by Designer, Developer and Agency.
Inside them is the 1,500 words of non-anchor body text that account for every word of prose inside a details element across all five pages. That text is typeset the same way. Flattening it produces keys and braces: "@type": "ListItem" followed by "name": "Build" and a description reading, in full, Bring team members and AI agents into one shared workspace, with design systems to keep everything on brand. The visible type tokens across the 12 widgets are ListItem, which appears 20 times, Review, which appears 12 times, and card, which appears 4 times. Requested on 26 August 2026, https://schema.org/card answers HTTP 404, so card is not a term the vocabulary defines.
None of this is structured data, and the distinction is the whole point of including it. The text sits in ordinary HTML text nodes, not inside a script element with a type of application/ld+json, so no parser reads it as structured data no matter what it spells. The page does publish real markup separately and publishes a great deal of it: a single JSON-LD block whose graph, when this site counted typed nodes across the same five captures, held 96 of the 102 in the corpus, 39 of them WebPageElement nodes naming navigation copy, and 6 of them Review nodes whose authors named the customer rather than the writer. So the fair reading is that Machine Mode is a design device aimed at a human looking at a marketing page, sitting alongside genuine markup rather than substituting for it. What a crawler receives from the widgets themselves is 1,500 words of prose with quotation marks and braces in it.
| Where it sits | What it contains | Count | Read as structured data |
|---|---|---|---|
| Visible summary labels in 12 details elements | The string "@audienceType" with one of Marketer, Designer, Developer or Agency | 12 | No |
| Visible body text in the same 12 elements | Keys, braces and marketing prose, 1,500 words, none of it inside an anchor | 1,500 words | No |
| Visible type tokens in that text | ListItem 20 times, Review 12 times, card 4 times, the last of which schema.org does not define | 36 | No |
| One script element of type application/ld+json | A graph holding 96 typed nodes, 39 of them WebPageElement | 96 nodes | Yes |
What to check on your own site, and what this does not tell you
The limits first, because they are large. Five pages captured on one day is not a sample of the web, four of them use the element at all, and one of those four contributes 82 percent of the prose. No crawler was observed and no engine was queried, so nothing here is evidence that GPTBot, ClaudeBot, PerplexityBot or any other agent treats a collapsed disclosure differently from an open one. This post reports what four documents contain, and the honest form of the FAQ question stays open: the practice being absent from this corpus is not the same as the practice not working.
What can be checked on any page, cheaply and without trusting this or any other survey, is the thing that actually decides the outcome. Fetch the page as a plain client and look for the answer text in the bytes that come back. If the questions and answers are in details elements they will be there, collapsed or not. If they are injected by script on click they will not be, and the FAQPage schema type describing them is then a description of content that client never received. The robots.txt tester answers the prior question of whether a named crawler is allowed to fetch the page at all, and there is no point auditing markup on a URL that returns a disallow.
Two smaller things follow from the position data. If your disclosure widgets sit inside a nav or a footer, their text is chrome by construction, and a scanner that separates the document from its furniture will treat it that way. If they sit inside main and hold real answers, the text is in the document and the collapsed state costs you nothing on a fetch-only client, which is the useful half of this whole finding. Per-stack guidance on getting the first response to carry your prose is in the Next.js guide and the Shopify guide, the platform-specific side of citation is in the ChatGPT page, and the vocabulary this post leans on is defined under answer engine optimisation and generative engine optimisation. MDN's summary element reference, also last modified 24 April 2026, is the place to check the one structural rule that matters if you do build an FAQ this way: the summary may only be the first child of its details element. The wider set of counts taken from these same captures sits under research, and what the composite score is made of sits under AI visibility.
- Fetch the page without a browser and search the bytes for your answer text If the answers are in details elements they are in the first response. If a script injects them, they are not.
- Check whether the widgets sit inside nav, header, footer or aside 23 of the 31 in this corpus did, which makes their text chrome rather than document under a positional rule.
- Check whether the summary is the first child of the details element MDN states that is the only position the element may occupy, and the count here found 31 summaries for 31 details.
- Expect a score change from using the element Lantad has no check for details or summary. It is neither in DROP_TAGS nor rewarded anywhere in core/src.
Lantad
Published .
A disclosure widget is the one piece of hidden content that is not really hidden. Everything else a page tucks away costs something to retrieve: a tab panel injected on click, an accordion whose answers arrive from an endpoint, a modal that only exists after a script runs. The details element is different, because the HTML parser builds its contents whether or not the widget is open, and the collapsed state is a rendering instruction rather than a fetch. That distinction matters to anyone asking what an AI crawler receives, because a fetch-only client never applies the rendering instruction in the first place.
Common questions
Can an AI crawler read text inside a collapsed details element?
The text is present in the HTML whether the widget is open or closed, so a client that fetches the page and never runs a browser receives it. Across the five pages this scanner captured on 15 July 2026, the details element count and the word counts inside them were identical in the raw HTTP response and in the rendered DOM. That is a fact about the bytes. It is not evidence that any named crawler extracts, weights or cites that text, because no crawler was observed for this post.
Should I put my FAQ inside details elements?
This post cannot answer that, and says so rather than guessing. What it can report is that none of the 31 disclosure widgets in its corpus was an FAQ: not one summary label contained a question mark. The mechanical argument in favour is real, which is that a details element needs no JavaScript, so its content survives a fetch-only client in a way a scripted accordion does not. The argument that an answer engine specifically rewards the pattern has no measurement behind it here.
Does a closed details element hide content from search engines?
The open attribute controls display, not parsing. MDN's reference, last modified 24 April 2026, describes it as indicating whether the contents are currently visible, and the HTML Standard defines it as controlling whether the additional information is shown to the user. Neither specification attaches any retrieval or indexing behaviour to the attribute, and nothing in this post measured how any search or answer engine ranks collapsed text.
Does Lantad score the details element?
No. Read out of core/src/extract.ts on 26 August 2026, neither details nor summary appears in DROP_TAGS or BLOCK_BOUNDARY_TAGS, so their text is read as ordinary prose and neither element begins a new text block. There is no check anywhere in core/src that rewards or penalises a disclosure widget. Where the text lands in the score depends entirely on its ancestors, and 23 of the 31 widgets counted here sit inside a nav, header, footer or aside.
See what AI can read on your site
Run a free scan and get a graded report of exactly what AI crawlers can and cannot read, with ranked fixes.
1,395 of 2,729 text blocks were navigation, not main content
Counted on 25 August 2026 from five real pages this scanner captured and stored on 15 July 2026, the crawler view holds 16,636 visible words and 2,729 text blocks. 1,395 of those blocks sit inside nav, header, footer or aside, and between them they carry 2,920 words. More than half the blocks hold under a fifth of the text.
Three of five captured pages carried JSON-LD, and one held 96 of the 102 nodes
Parsed out of five real pages this scanner captured and stored on 15 July 2026, four JSON-LD blocks hold 26,299 bytes and 102 typed nodes. One page accounts for 24,865 of those bytes and 96 of those nodes, 39 of them describing a navigation menu.
Fourteen noscript elements on five pages, and not one held text
Counted with an HTML parser on 25 August 2026 over five real pages this scanner captured and stored on 15 July 2026, the initial HTTP responses hold 14 noscript elements. Between them they carry 11 img tags, one tag manager iframe, one CSS rule of 57 characters and zero characters of text. The one element HTML defines for a reader that does not run scripts is the one place on these pages where nobody wrote a sentence.
Three table elements on five real pages, and all three were navigation
Lantad's own component library states that a table is the shape an AI crawler extracts most reliably, so the claim was checked against the pages this scanner has actually stored. Counted with an HTML parser on 21 August 2026 over five real pages captured on 15 July 2026, the whole set holds three table elements, all three on one page, all three navigation boxes, and none of the five pages carries a single caption element.
Prose Parity
Prose Parity is Lantad's metric for the share of a page's rendered, human-visible text that is present in the raw HTML an AI crawler receives, where 100% means a crawler sees everything a human visitor sees.
AI crawler
An AI crawler is an automated bot, such as GPTBot, ClaudeBot, or PerplexityBot, that fetches web pages so an AI system can read, train on, or cite what those pages contain.
