# 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.

- Canonical page: https://lantad.co/blog/thirty-one-disclosure-widgets-held-no-faq
- This file: https://lantad.co/blog/thirty-one-disclosure-widgets-held-no-faq.md
- Last substantive update: 2026-08-26

## Key facts

- **Published:** 2026-08-26
- **Category:** Findings
- **Author:** Lantad
- **Length:** 3384 words
- **Takeaway 1:** 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.
- **Takeaway 2:** 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.
- **Takeaway 3:** 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.
- **Takeaway 4:** 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.
- **Takeaway 5:** 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.

## Summary

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](https://lantad.co/glossary/ai-crawler) receives, because a fetch-only client never applies the rendering instruction in the first place.

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.

## 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](https://lantad.co/blog/half-the-text-blocks-were-navigation) and classified 1,395 of 2,729 as navigation, and the same pattern that turned up when [every table element on these pages](https://lantad.co/blog/three-tables-on-five-pages-all-navigation) 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](https://lantad.co/glossary/prose-parity) 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](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/details), 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.

## Collapsed is not hidden: the text arrived in the first response

Every figure in this post is identical in the raw HTTP response and in the rendered DOM, on all five pages, with no exceptions. Six details elements on astro.build in both views, three on gymshark.com in both, ten on the MDN reference in both, twelve on webflow.com in both, none on the Wikipedia article in either. The word counts match too: 1,834 words of body text in the crawler view and 1,834 in the browser view.

This is the part of the finding that cuts against the intuition most people carry about hidden content, so it is worth being precise about why. The HTML specification at html.spec.whatwg.org/multipage/interactive-elements.html defines the open attribute as controlling whether the additional information is shown to the user, and says that when the element is created with the attribute absent the additional information should be hidden. That is a statement about display. It says nothing about parsing, and nothing about what any client does with the text once it has it. The contents are ordinary markup either way, which is exactly why the counts do not move between the two views.

The practical consequence runs the opposite way to the usual warning. A frequently asked questions block built from details elements survives a client that never opens a browser, because there is nothing to open. A frequently asked questions block built from a JavaScript accordion that injects its answers on click does not, and that is the ordinary [two-layer problem](https://lantad.co/blog/two-layers-decide-if-ai-can-read-your-site) this site keeps returning to. Related shapes have been measured here before: text sitting in a hydration payload [scored the same as no text at all](https://lantad.co/blog/hydration-json-scored-the-same-as-no-text), and running a browser over these same five pages [added no new crawl paths](https://lantad.co/blog/javascript-added-no-new-crawl-paths) while dropping nine locale links. If you want to see which of the two shapes your own page is, the direct way is to [fetch it as a named crawler and read what came back](https://lantad.co/tools/what-gptbot-sees) rather than to reason about it.

## 23 of the 31 sat inside navigation, and the extractor treats that as boilerplate

Position decides what the text counts as, and here the position is lopsided. Of the 31 widgets, 23 have a nav, header, footer or aside ancestor and 8 sit inside a main or article element. None sits outside both. All 8 of the main-content ones are on webflow.com. Every details element on astro.build, on gymshark.com and on the MDN reference is inside page chrome.

That mapping is not incidental to how this scanner reads a page. Read out of core/src/extract.ts on 26 August 2026, BOILERPLATE_TAGS holds exactly nav, header, footer and aside, and anything inside one of them is classified as boilerplate regardless of what else it qualifies as. So 23 of the 31 disclosure widgets, and the 334 words of anchor text they contain, land in the part of the corpus that [the methodology](https://lantad.co/methodology) treats as shared chrome rather than as the document.

The more useful thing in that file is what is not there. Neither details nor summary appears in DROP_TAGS, which holds script, style, noscript, template, svg and iframe, so unlike a [noscript element, whose subtree is discarded entirely](https://lantad.co/blog/fourteen-noscript-elements-held-no-text), collapsed text is read. Neither appears in BLOCK_BOUNDARY_TAGS either, so neither element starts a new text block on its own and any flush comes from whatever container sits inside it. The blunt summary of both facts is that Lantad has no check for this element whatsoever. It does not reward a details element, does not penalise one, and does not know the difference between a disclosure widget holding an answer and a div holding the same words. That is a gap in the product and not a considered position, and it is more honest to write it down than to imply the scanner has an opinion it does not have.

## 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](https://lantad.co/glossary/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](https://lantad.co/blog/three-of-five-pages-carried-json-ld), 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](https://lantad.co/blog/seven-schema-nodes-named-an-author). 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.

## 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](https://schema.org/FAQPage) describing them is then a description of content that client never received. The [robots.txt tester](https://lantad.co/tools/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](https://lantad.co/fix/nextjs) and the [Shopify guide](https://lantad.co/fix/shopify), the platform-specific side of citation is in [the ChatGPT page](https://lantad.co/how-to-get-cited/chatgpt), and the vocabulary this post leans on is defined under [answer engine optimisation](https://lantad.co/glossary/aeo) and [generative engine optimisation](https://lantad.co/glossary/geo). [MDN's summary element reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/summary), 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](https://lantad.co/research), and what the composite score is made of sits under [AI visibility](https://lantad.co/glossary/ai-visibility).

## Questions and answers

**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.

---

Lantad measures whether AI crawlers can actually read a page: it fetches as a non-rendering
crawler, renders as a browser, and reports the gap. Free scan, one URL, no signup.

Method and weights: https://lantad.co/methodology | All pages as markdown: https://lantad.co/md | Crawler policy: https://lantad.co/bot