FAQ schema: 83 of 1,078 sites still declare it, and 298 of 1,277 answers are not on the page

What is FAQ schema, and does anything still read it?

Three documents govern it and they now say something slightly odd when you put them next to each other.

schema.org, at release 30.1 dated 2026-09-16, defines a FAQPage as a WebPage "presenting one or more 'Frequently asked questions' (see also QAPage)". The same page carries a usage line reading "Usage: 1M - 10M Domains Based on monthly aggregations from Google's web index. (Google - August 2026)", so by Google's own count of the web the type is on somewhere between one and ten million domains as of last month. A Question is defined as "A specific question - e.g. from a user seeking answers online, or collected in a Frequently Asked Questions (FAQ) document", and its acceptedAnswer property as "The answer(s) that has been accepted as best, typically on a Question/Answer site". That is the whole vocabulary: a page type, a list of questions, an answer on each.

Google's structured data general guidelines, carrying Last updated 2026-07-10 UTC, are the only rule Google still publishes that reaches FAQ markup, because the feature-specific page is gone. They state "Don't mark up content that is not visible to readers of the page", give the example that "if the JSON-LD markup describes a performer, the HTML body must describe that same performer", and state that structured data "must be a true representation of the page content". That sentence is the whole of the test run below.

Then there is the type nobody used. Google's QAPage documentation, carrying Last updated 2026-09-08 UTC, describes a live rich result and says "Only use the QAPage markup if your page has information in a question and answer format, which is one question followed by its answers", adds that users "must be able to submit answers to the question", and instructs "Don't use QAPage markup for FAQ pages or pages where there are multiple questions per page". It does not mention FAQPage anywhere. So Google's current position is that an ordinary FAQ page has no rich result and QAPage is not a substitute for it. Lantad's own check is narrower still and it is a decision rather than a finding: SCHEMA_REQUIREMENTS in core/src/schema.ts lists FAQPage among five recognised types and requires exactly one property on it, mainEntity, which is where the questions live.

How many sites still declare it, and which kind of site?

92 of the 1,851 pages carried a FAQPage node, belonging to 83 distinct sites out of the 1,078 whose home page answered. 51 of those sites carried it on the home page, 32 carried it only on an interior FAQ or help page, and 9 carried it on both. Against the 984 pages that carried any JSON-LD at all, that leaves 892 pages publishing structured data and no question and answer block, which is unsurprising: most of them are describing an organisation, an article or a product instead, a distribution this blog has measured directly in finding that 103 of 385 pages with JSON-LD named no organization and that 141 of 382 home pages carried no structured data in the raw HTML.

The split by category is the sharpest this measurement has produced on any schema type, and it does not run the way a Google-feature story would predict. The three highest rates are SaaS marketing sites at 10 of 37, single page app startups at 9 of 45 and the broader SaaS category at 20 of 116. The three lowest, excluding the categories with too few sites to say anything, are government at 1 of 86, education at 1 of 104 and news at 0 of 60. Not one of the sixty news sites read carried a FAQPage, which is notable because news publishers are the constituency that chased every Google rich result while the features existed. The institutions that adopt structured data for durability skipped this type, and the companies that adopt it for marketing kept it after the feature it fed was removed.

Four pages carried more than one FAQPage block in the same document. wix.com publishes two four question blocks on its home page, truist.com publishes two seven question blocks on /contact, topodesigns.com publishes a 27 question block and a 24 question block on /pages/faq, and eatfishwife.com publishes three blocks of 12, 9 and 8 questions on the same page. Duplicated blocks are the signature of a marketing tag and a theme template both emitting markup without knowing about each other, the same class of defect this blog counted when it found 117 of 612 home pages with JSON-LD carried a defect. Separately, 26 of the 1,851 pages carried a JSON-LD block that did not parse as JSON at all, and whatever was in those is invisible to every consumer.

298 of 1,277 answers were not in the page the crawler was served

Here is the test, stated plainly enough to argue with. For each question in each block, the question text and the answer text were taken from the JSON-LD, stripped of any HTML tags they contained, lowercased and reduced to single spaces. The first sixty characters of each were then looked for in the visible text of the same page, meaning the served HTML with script, style, noscript and comment content removed and tags stripped. A question or answer shorter than the threshold for a meaningful match was not checked. 1,276 of the 1,277 questions and 1,274 of the answers were long enough to check.

1,156 of the 1,276 question texts were found in the page. 120 were not. On the answers the gap is much wider: 976 of 1,274 answer texts were found and 298 were not, which is 23.4 percent. Split by pair, 103 questions had neither their question nor their answer anywhere in the page text, and another 195 showed the question and withheld the answer, which is exactly the shape a collapsed accordion produces when the panel contents are built in the browser and the headings are not.

What this does and does not prove is worth being precise about. The visible text here is the served markup with scripts removed, so an answer hidden by CSS inside a closed accordion still counts as present: the bytes are there, a crawler can read them, and only a human needs to click. An answer counted as absent is genuinely not in the document the server sent. The test can still produce a false absence, because a page that renders the same answer with different punctuation, a different entity spelling or an editorial trim will not match on a sixty character prefix. Four cases were re-requested by hand and re-confirmed, and all four are named below. So treat 298 as an upper bound on the count and the fifteen all-absent blocks as the part that is solid.

The distinction matters for an AI crawler in a way it does not for a person, and it cuts both ways. A crawler that does not execute JavaScript reads the JSON-LD and the visible HTML from the same file, so an answer that exists only in the markup is still readable to it. This is the inverse of the usual failure, where the prose is in the bundle and the crawler gets nothing, which this blog measured when it found that 11 of 271 pages returned no words at all without JavaScript. But it is also a direct conflict with the single rule Google still publishes, and it means the page and its own description of itself disagree. The same divergence turned up when this blog checked marked-up values against the pages carrying them and found 70 of 146 values were not on the page.

The 15 blocks where not one answer appeared in the HTML

46 of the 97 nodes had every checkable answer present in the page. 36 were mixed. 15 had none at all, and those are the unambiguous cases, because a block where every single answer is missing is not a matching artefact.

They are agentplace.io with 14 questions, fibilaw.com with 12, sedai.io with 10, citi.com with 7, pollyreach.ai with 7, trially.ai with 7, asteroid.ai with 6, novavoice.app with 5, backmarket.fr with 4, temu.com with 4, askdialog.com with 3, predoc.ai with 3, getdianahr.com with 2, and one question each on alliantcreditunion.org and wagamama.com. Thirteen of the fifteen are on a home page. The concentration is obvious from the list: these are software companies and marketplaces running client-rendered marketing pages, the same population that showed the highest adoption rate in the previous section. The FAQ accordion is a component, the component receives its content at runtime, and the build step writes the same content into a JSON-LD block because a plugin offers to do it.

The mixed cases are larger and more interesting in aggregate. dishoom.com publishes 47 questions on its FAQ page and 41 of the answers are not in the served bytes. monday.com publishes the largest block in the corpus, 126 questions on /w/faqs, and 40 answers are absent. salesforce.com publishes 55 on /connections/faq with 31 absent, thewireguyelectric.com 28 with 15 absent, ama.com.au 12 with 11 absent, and superglue.ai 12 with 10 absent. A page that marks up 126 questions and renders 86 of the answers is not a page with a broken plugin. It is a page whose markup and whose rendering are drawing from the same source at different times.

One case is a defect of a different kind and it was re-fetched and confirmed byte for byte. temu.com serves a FAQPage on its home page whose answer text contains literal asterisks where words belong, reading in part "We aim to * our * with access to high-quality products and dream * at the best * value" and, in the next question's name, "How is Temu * offer such low prices compared with competitors?". Something in the publishing path is substituting a character for words, and the result is shipped as the machine-readable description of the business. Nothing in the vocabulary catches that, and nothing in Lantad's methodology catches it either, because the required property mainEntity is present and the strings are non-empty.

Two pages where the markup carried more prose than the page did

Two of the fifteen are worth pulling out because they invert the usual complaint about structured data being decoration on top of real content.

citi.com returned 255,746 bytes to this crawler on 23 September 2026 and eleven visible words. The eleven words are the title and a skip link: "Online Banking, Mortgages, Personal Loans, Investing | Citi.com Skip to Content". Everything else on the page is built in the browser. The same document carries one JSON-LD script containing a FAQPage with seven questions and 4,158 characters of answer prose, covering what account types Citi offers, what simplified banking is, and what is required to open an account online. For a crawler that does not run JavaScript, that block is not a supplement to the page. It is the page. pollyreach.ai is the same shape at a smaller scale: ten visible words in the served document and 1,299 characters of answer text inside the markup.

This is the reason a measurement of FAQ markup belongs on a site about prose parity rather than on a site about rich results. Two facts about citi.com are true at once. Its structured data violates the visibility rule in Google's general guidelines, because the content is emphatically not visible to a reader of the served page. And its structured data is simultaneously the only thing rescuing that URL from being blank to any consumer that does not render, a category that includes several of the crawlers behind AI answers. Which of those matters more depends entirely on who you are optimising for, and the honest answer is that a site should not have to choose, because the fix for both is the same: serve the text.

The generalisable version is dull and correct. If your FAQ answers are only in the markup, you have accidentally discovered that your page does not serve its own content, and the FAQ block is the symptom rather than the disease. Seeing what a bot is actually sent will show the rest of it. If the page is built in React or Next.js the specific remedies are in the React guide, and the broader question of what happens to text that only exists after hydration was measured when this blog found that hydration JSON scored the same as no text at all.

Not one page in the corpus used QAPage

Across 1,851 pages and 1,713 JSON-LD blocks, the count of QAPage nodes is zero. The count of FAQPage nodes is 97.

That is the inversion worth ending on. QAPage is the type Google still documents, still describes a rich result for, and updated as recently as 2026-09-08. FAQPage is the type whose feature was switched off four months earlier and whose documentation was deleted. The corpus uses the dead one exclusively. There is a reasonable explanation and it is not that site owners are confused: QAPage's own guidelines require that users "must be able to submit answers to the question", which makes it a type for forums and community sites rather than for a company's FAQ page, and almost nothing in this corpus is a forum. The two types are not substitutes, whatever their names suggest, and Google's documentation says so directly.

What follows from that is a narrow claim rather than a broad one. Adding FAQPage today buys no documented Google feature. Removing it costs no documented Google feature either. The 97 nodes in this corpus sit outside the feature economy entirely, and the only remaining arguments for them are that the text is machine-readable and that some consumer other than Google Search might use it. Lantad cannot settle the second argument. No AI crawler vendor documents what its fetcher does with a FAQPage node, this run sent no request from GPTBot, ClaudeBot or PerplexityBot, and there is no measurement on this site showing that a FAQ block has ever produced a citation anywhere. Anyone telling you otherwise is guessing, which is the same conclusion this blog reached about the relationship between answer engine optimization tactics and outcomes when it looked at what Google itself names as tactics to ignore.

The first argument survives, and it is modest. 1,277 questions written as plain strings with their answers attached is a clean machine-readable asset whatever reads it, which is more than can be said for the same content trapped in a JavaScript accordion. That is the case for keeping it, and the case is conditional on the answers actually being there, which on 298 of them they were not.

What this measurement does not show

Every figure above describes 1,419 hostnames on one day and nothing wider, and the route by which a page entered the sample shapes what the numbers can mean.

The corpus is an editorial sampling frame rather than a random draw of the web, so a rate here supports a statement about these hostnames and not about the internet. 330 home pages never answered 200 with HTML, 212 of them refusing this crawler with a 403, and those sites are not missing at random: a site that refuses an unknown user agent is likelier to refuse other automation, which is the selection effect this blog has run into repeatedly, most recently when 42 of 50 product pages declared Product schema on a denominator that had already been filtered the same way. Only one interior page was read per site, chosen by following the first FAQ, help or support shaped link the home page offered, so a site with its FAQ markup on a page this run never reached counts as absent. 608 home pages offered no such link at all. Every adoption count here is therefore a floor.

No JavaScript was executed anywhere in this run, which is deliberate and is the reason the visibility test means anything, but it also means a FAQPage injected client side was not seen. The same choice underlies the finding that only two of nine AI crawlers render JavaScript, and it is why the figures describe what a server sent rather than what a browser drew.

The visibility test itself has the limits set out above: a sixty character prefix match against tag-stripped text will report a false absence where a page renders the same answer with different wording or punctuation, so 298 is an upper bound and the 15 all-absent blocks are the floor. Finally, nothing here is a claim about ranking or citation. Lantad weights schema at a tenth of its overall score, which is a decision recorded in SCORE_WEIGHTS in core/src/config.ts rather than a measured finding about what matters, and the same caution applied when this blog reported on what 111 article pages declared about their authors and on how many of 93 SaaS pricing pages put a price in the markup. The values above are claims these sites made about themselves on 23 September 2026 and may have changed since.