FAQ Schema Is Not Dead. It Just Stopped Being About Rich Results

Short version, because it is the whole argument: FAQ schema stopped being a way to win extra pixels in a blue-link result, and became a way to format content so a machine can lift it cleanly. Those are different jobs. The first one Google largely took away. The second one got more valuable, because the number of systems that answer questions by quoting passages from web pages went from roughly one to roughly a dozen.

If you deleted your FAQ blocks when the rich results dried up, you optimised for the wrong layer.

What actually changed with FAQ rich results

Google significantly scaled back the display of FAQ rich results in ordinary search listings, narrowing eligibility so that the expandable question-and-answer snippets most sites used to earn largely stopped appearing for them. Sites that had built FAQ blocks to occupy more vertical space on the results page watched that space disappear.

What is not safe to assert is the precise present-day state — which site categories remain eligible, what the exact display conditions are, or whether any of it has shifted again since. Rich result support changes without much ceremony, and a post stating a hard current rule will be wrong within a year. Before making a decision that depends on it, check the FAQPage structured data documentation in Google Search Central. That is the only source current by definition.

What passage retrieval means, and why it changes the writing

Passage retrieval is the process by which a system breaks documents into chunks, stores them, and pulls back individual chunks that match a query — rather than returning the whole document and hoping the reader finds the relevant part.

When an AI assistant answers using web sources, it is not reading your 2,400-word article end to end. Something upstream has already cut your page into pieces. The retrieval step scores those pieces against the user's question, a handful of the highest-scoring pieces get handed to the model, and the model writes an answer out of what it was handed.

Your page did not compete. A chunk of your page competed. Three consequences follow:

• Context does not travel. Everything established in paragraph two is gone by the time paragraph nineteen is evaluated alone. A chunk saying "this is the more expensive of the two" is useless, because the two are not in the chunk.
• Boundaries are not yours to choose. Systems chunk differently — by token count, by heading, by paragraph, by semantic similarity. Writing in self-contained units is how you stay coherent wherever the cut lands.
• A question is a free relevance signal. Retrieval scoring compares a user's query to your text. A heading that is literally the question a user would type, with the answer directly beneath it, is about as close a match as a document can offer without gaming anything.

A question-and-answer pair is structurally a pre-chunked document: obvious boundaries, short unit, and the context carried inside. That is why the format outlived the rich result. More on the mechanics of being quoted in how to get cited by ChatGPT and Perplexity.

The anatomy of a retrievable answer

A retrievable answer is a passage that still answers the question when it is removed from the page and read with no surrounding text. That is the entire test, and almost everything below follows from it.

Length: roughly 40 to 80 words

This is a rule of thumb, not a published threshold. Under about 40 words you usually have an assertion without enough substance to be worth quoting over a competitor's fuller answer. Over about 80 you start bundling several ideas together, which matches a broad set of queries less precisely and gives a model more to compress. Write the direct answer inside that band, then continue underneath with nuance and examples for the human reader.

Self-containment: no references pointing outside the chunk

Hunt down and remove:

• "As mentioned above", "as we saw earlier", "see the previous section" — the chunk has no above, earlier or previous.
• Pronouns with antecedents elsewhere — "it", "they", "this approach", "the former". If the noun is not in the chunk, put it back in.
• "The first option", "that second method" — ordinals referencing a list the chunk cannot see.
• "Here", "below", "in the table" — spatial references to a layout that no longer exists once the text is lifted.

Restate the question's words in the answer

If the heading asks "How long should a meta description be?", the answer should not open with "Around 150 to 160 characters." It should open with "A meta description should be around 150 to 160 characters." Slightly redundant to read; far more useful when the sentence stands alone with no heading attached, which is common — retrieval systems frequently score and return answer text independently of its heading.

One claim per sentence, and front-load it

Three-clause compound sentences are harder to verify, harder to quote partially without distortion, and easier for a model to render inaccurately. Short declarative sentences survive summarisation better. Then say the thing in sentence one and qualify in sentence two: building context and delivering the conclusion at the end is good essay writing and bad retrieval writing, because a truncated chunk keeps the beginning and loses the end.

Before and after: a weak answer made retrievable

Here is the same FAQ answer written both ways. The question is "Do I need an SSL certificate for SEO?"

Count what changed. The rewrite names its subject in the first sentence instead of saying "this". It answers "Yes" rather than making the reader infer one. It has no "previous section" and no "we covered above". Each sentence makes one claim. It runs 63 words. And crucially — lift that right-hand cell out, paste it anywhere, and it still means exactly what it meant on the page. The left-hand cell becomes gibberish the moment you move it.

Why the markup and the visible copy must match

Structured data is a description of the page, not an addition to it. Every major search engine's guidelines say a version of the same thing: content you describe in markup must be visible to a user on that page.

People break this in three ordinary, non-malicious ways. The FAQ block was removed in a redesign and the JSON-LD stayed, so the markup now describes a section that does not exist. Or the visible copy was tightened and the schema was not, so two versions of the same answer disagree. Or questions were added to the markup "for coverage" that were never on the page at all — that one is not an accident.

The risk is not theoretical. Structured data describing content a user cannot see sits squarely within what search engines treat as a spam policy violation, and the remedy — a manual action against structured data — removes rich result eligibility for the whole site, not the one page.

There is a subtler cost too. If a retrieval system takes your marked-up answer at face value and a user clicks through to a page where that answer is not present, you have created exactly the experience these systems are being tuned to avoid. Getting cited once and being wrong is worse than not being cited.

The practical rule: generate the JSON-LD from the same source as the rendered answer. In a CMS, that means FAQ entries are structured records in the database and both the HTML and the schema are templated from them. Schema hand-maintained in a separate field will drift — not because your team is careless, but because two copies of anything always drift. The templating pattern is covered in schema markup for AI search citations.

Where FAQ blocks belong — and where they are padding

The honest position is that most FAQ sections on the web should not exist. They were bolted on to earn a rich result, they repeat what the page already said, and they answer questions nobody asked. A retrieval system has no more appetite for that than a reader has.

The test for whether a question belongs: did a real person ask it? Sales call transcripts, support tickets, the site search log and the "People also ask" box are four sources of genuine questions. Questions reverse-engineered from a keyword tool because they had volume are the ones that read as filler.

The schema types that deserve more of your attention

If FAQPage has been absorbing your structured data effort, here is where it is better spent. Each of these does something specific, and none is a rich-result lottery ticket.

Notice the pattern. The types worth your time state facts about the page and the entity behind it — who wrote this, when, who published it, what it costs. That is what a system needs to decide whether to trust a passage. FAQPage was never that. It was a formatting hint, and its real value was always the content shape it encouraged.

How to test whether your passages survive extraction

You do not need a tool for this. You need ten minutes and a willingness to be unimpressed by your own writing.

Common questions

Should I remove FAQ schema from my pages? No, provided the FAQ content is genuinely on the page and answers real questions. FAQPage markup that accurately describes visible content costs nothing to keep and continues to communicate structure to any parser reading your page. Remove it only where the visible FAQ block no longer exists, because markup describing absent content is a spam policy violation regardless of whether a rich result is available.

Do FAQ rich results still appear in Google? Google sharply reduced FAQ rich result display, and most sites that once earned those expandable snippets no longer see them. The precise current eligibility rules change over time, so check the FAQPage documentation in Google Search Central rather than trusting any blog post, including this one, for the present state. Plan your content on the assumption that the rich result is not coming back.

How long should an answer be for AI assistants to use it? Roughly 40 to 80 words works well as a rule of thumb. That range is long enough to make a substantive, quotable claim and short enough to stay a single coherent idea when a retrieval system chunks your page. Put the direct answer in that band at the top, then add nuance and examples in following paragraphs for human readers who want the detail.

What does "self-contained" actually mean for a passage? A self-contained passage still makes complete sense when it is cut out of the page and read alone. It names its own subject instead of using a pronoun, contains no phrases like "as mentioned above" or "the first option", and does not depend on a heading or a nearby table to be understood. The test is simple: paste it somewhere empty and read it.

Can schema markup make an AI assistant cite me? No. Structured data describes your content accurately and makes facts machine-readable, which helps a system parse and attribute what you published. It does not create authority and it will not get a thin page quoted. Citation follows from being a clear, accurate, well-formatted source on a topic you can credibly speak about; markup makes that easier to detect, not truer.

Does an llms.txt file help with any of this? Not currently in any measurable way. Passage retrieval works from your rendered pages, so the returns come from how those pages are written and structured, not from an extra file at the root. We set out the reasoning in why llms.txt is not what your site needs.