Google’s FAQ rich result stopped appearing in search on 7 May 2026, which removed the reason most FAQ blocks on the web exist. They were installed to feed a validator that paid out a visible reward. The reward is gone; the blocks are still sitting at the foot of a few hundred thousand templates, maintained by nobody.
What survives is a narrower case and a better one. A question with a self-contained answer under it is the exact shape a retrieval system wants, and it costs nothing to produce. The trouble is that the same shape produced for the wrong reason is one of the cheapest ways to make a page worse. This is where the line falls, and the single test that decides which side a given question is on.
The practical reason to settle it is that FAQ blocks are almost never one page’s problem. They were installed template-wide, they are maintained by whoever inherited the template, and somebody will object to removing them on the grounds that FAQs are good for search. The sections below are the argument for that conversation, with the dates and the primary sources attached.
Key Takeaways
- The incentive that produced most FAQ sections is gone. FAQPage is still a valid schema.org type, and Google doesn’t ask anyone to remove it, but no feature is coming back to reward it.
- The case that survives is structural: a Q&A pair is a pre-chunked passage — a question that names its own subject and an answer that stands alone without it.
- The test: if a question belongs on the article’s spine, it should be an
##heading in the body with the answer under it. An FAQ is for real questions that have nowhere to live in a linear argument.- Filler is not neutral. Templated blocks read as furniture, restated answers split one question across two thinner passages, and markup describing questions a reader can’t see breaks Google’s own structured-data policy.
The reward is gone. The blocks aren’t.
The deprecation is complete and dated. Google’s notice states that the feature “will no longer appear in Google Search starting May 7, 2026,” and the documentation for it was removed outright on 15 June 2026 (Google Search Central, retrieved 2026-08-05).
Nothing replaced it, and Google has been explicit that nothing needs to. Its guidance on AI features says you “don’t need to create new machine readable files, AI text files, or markup to appear in these features,” and that “there’s also no special schema.org structured data that you need to add” (Google Search Central, retrieved 2026-08-05).
The type itself is untouched. schema.org still defines FAQPage as “a WebPage presenting one or more ‘Frequently asked questions’” (schema.org, retrieved 2026-08-05), and existing markup doesn’t need removing. What changed is that every argument for an FAQ section that ran through the markup now terminates nowhere. Whatever case you make for one has to run through the reader and the extractor instead.
A Q&A pair is a passage that already stands alone
A question with a short answer under it is already the unit retrieval works in, and that is the entire surviving case for an FAQ section. It doesn’t run through markup at any point.
Retrieval doesn’t operate on your page. “Passage ranking is an AI system we use to identify individual sections or ‘passages’ of a web page to better understand how relevant a page is to a search,” Google’s ranking documentation states (Google Search Central, retrieved 2026-08-05). Sections, scored on their own. Chunking covers what that does to ordinary prose: passages arrive without the paragraph before them, and anything load-bearing that stayed behind is simply gone.
A well-formed Q&A pair has, by accident of format, the three properties that prose usually has to be edited into having. The question names its own subject, so the passage says what it’s about. The answer is short enough to survive one cut. And there is nothing to refer backward to, because the pair began at the question. It is a chunk that was written as a chunk.
The second half is what those passages get matched against. AI Mode and AI Overviews “may use a ‘query fan-out’ technique — issuing multiple related searches across subtopics and data sources — to develop a response” (Google Search Central, AI features, retrieved 2026-08-05). Your page isn’t only competing on the question a person typed; it’s competing on the subtopics that question was decomposed into. A sixty-word answer to a genuine adjacent question that no section of your article was ever going to cover is an additional surface, and it requires no markup to be one.
That case is enough on its own. It also has a sharp edge, because every word of it applies just as well to a heading in the body.
The test: would this be better as a heading?
Take each question in your FAQ and ask whether the article would be better if that question were an ## heading in the body, in position, with the answer underneath it. Where the answer is yes, that’s where it goes.
A question on the spine gets things the FAQ can’t give it. It sits inside the document hierarchy, so a structure-aware splitter keeps the heading attached to its answer. It has the paragraph before it to set it up and the section after it to follow on. It can be as long as the answer needs. Question headings is the mechanism, and the 40–60 word answer block is what goes under one. An FAQ entry is the same content with the context stripped and the position discarded.
Which leaves a specific, smaller job for the FAQ: questions that are real but off the spine. Scope limits — does this apply to a single-page app, to a subdomain, to a site behind a login. Disambiguations between two things readers routinely confuse. The objection that would derail the argument if you answered it in paragraph nine. The compatibility edge case three people emailed about. These are worth answering and have nowhere to live in a linear piece of writing, and an FAQ section is exactly the right container for them.
Read the other way, the test is a diagnostic on the body rather than on the FAQ. An FAQ section that would dissolve cleanly into the article is not evidence that the FAQ is working. It’s evidence that the article’s headings are wrong.
What filler costs
Three costs, none of them zero.
It reads as furniture. Extraction keeps the main content block and strips repeated page structure — what an answer engine reads covers the mechanics. Six questions rendered identically on four hundred URLs are, by the only definition that matters here, repeated page structure. At best they’re discarded along with the nav. At worst they’re kept, and every one of those URLs now carries the same block of text as its neighbours.
It splits one question across two passages. An FAQ answer that restates a body section leaves the page offering two chunks for the same question, each thinner than one good passage would have been. You haven’t added an answer. You’ve divided one.
Markup can end up describing what isn’t there. Google’s structured-data policy is unambiguous: “Don’t mark up content that is not visible to readers of the page,” and “your structured data must be a true representation of the page content” (Google Search Central, retrieved 2026-08-05). The usual shape of this fault isn’t deceit, it’s an accordion: the reader clicks and sees the answer, while a crawler reading the fetched document sees only markup asserting an answer that isn’t in the response. The distinction is where the text lives, not whether anyone clicked — does content behind a tab or accordion get extracted sets out the CSS-hidden versus fetched-on-click split.
Checking it
Two of the three costs are mechanical, so run them rather than reading for them.
The templated-filler check, without a terminal. Add a custom extraction rule for //main//h2 | //main//h3 — scoped to the main content, for the reason the next paragraph gives — crawl, and export one row per heading with its URL. In the spreadsheet, keep the rows ending in a question mark and count how often each one appears across the whole export:
=COUNTIF(B:B, B2)Anything above 1 is a question repeated on more than one URL. Sort descending and the templated blocks surface at the top, with the count telling you how many pages carry them.
The same check from a terminal, against rendered HTML:
python3 - <<'EOF'
import re, glob, collections
sets = collections.defaultdict(list)
for f in glob.glob('dist/**/index.html', recursive=True):
h = open(f, encoding='utf-8').read()
qs = [re.sub('<[^>]+>', '', m).strip()
for m in re.findall(r'<h[23][^>]*>(.*?)</h[23]>', h, re.S)]
qs = [q for q in qs if q.endswith('?')]
if qs: sets[tuple(sorted(qs))].append(f)
for k, v in sets.items():
if len(v) > 1: print(len(v), 'URLs share', len(k), 'questions')
EOFRun across this site it reports one shared set across six URLs, and the finding is a false positive worth knowing about: the shared “question” is the title of a post, appearing in the card listings on the blog index and three tag pages. Scope the selector to the article body before you believe an output. Two of the thirteen posts here carry an FAQ section, plus the pricing page, and no two of them share a question.
The restatement check, without a terminal. This one doesn’t need to scale, because a page has five or six FAQ answers, not five hundred. Open the page, pick a distinctive six-word run out of each answer — a phrase with a noun in it, not “this is the case where” — and search the page for it with the browser’s find. Two hits means the answer restates something already in the body. Working through six questions takes about a minute, and it catches the same fault the command does.
The terminal version compares each answer against the rest of the page automatically. Five-word shingles are enough:
python3 - post.mdx <<'EOF'
import re, sys
src = open(sys.argv[1]).read()
i = src.index('## Frequently asked questions')
j = src.index('\n## ', i + 1) # the FAQ ends at the next H2
faq, body = src[i:j], src[:i] + src[j:]
norm = lambda t: re.sub(r'[^a-z0-9 ]', ' ',
re.sub(r'\[([^\]]+)\]\([^)]+\)', r'\1', t).lower()).split()
bw = norm(body)
bs = {tuple(bw[k:k+5]) for k in range(len(bw) - 4)}
for b in re.split(r'\n### ', faq)[1:]:
q, _, a = b.partition('\n')
aw = norm(a); sh = [tuple(aw[k:k+5]) for k in range(len(aw) - 4)]
print(f'{sum(s in bs for s in sh) / len(sh) * 100:5.1f}% {q.strip()}')
EOFAgainst the five questions at the foot of the AEO guide on this blog, 39 of 350 shingles appear elsewhere on the page — 11.1% overall, ranging from 0.0% to 22.7% by question. That passes, and the number is worth less than it looks. The lowest-scoring question that still fails the heading test is “how long should an answer block be?” at 8.6%: barely any reused phrasing, and it restates a body section anyway. The check finds copied wording. It cannot find a repeated idea, and the test in the previous section is still a judgment you make by reading.
The third cost has no check here because there’s nothing to measure: this site emits no FAQPage JSON-LD on any URL. Its visible FAQ sections are unmarked, deliberately, and by the argument above that’s a position rather than a gap — the Q&A structure is doing the work, and the markup would only add a second thing to keep true.
At scale this becomes two per-URL numbers rather than a verdict. GEOBee scores FAQ and Q&A structure as one of the eight answer-readiness signals, worth 15 points, with published weights. The findings worth acting on are never “this page has no FAQ” — they’re identical question sets repeating across a template, and FAQPage markup that disagrees with the visible page.
One limit holds here as everywhere. A question answered in a self-contained passage is one a machine can lift; whether anything lifts it depends on competition, trust, freshness, and how the question was asked, none of which are properties of your HTML. Answer Engine Optimization: a page-level guide sets out the seven signals this one sits alongside, and tables and lists that survive extraction is the same argument applied to the other structure people build for the machine and then forget to write for the reader.