Plenty of sites still ship FAQPage JSON-LD and wait for an accordion to unfold in the search results. In 2026, that accordion never comes. Google stopped showing FAQ rich results entirely as of May 7, 2026.
Here's where I part ways with the obvious reaction. "Rich results are gone, so rip out the FAQPage markup" is not the right call. The death of the rich result and the death of the Q&A structure are two different things, and this post is about keeping them separate. I ran FAQPage JSON-LD through an offline validator to see the exact spot where "the schema passes" and "nothing shows up" diverge, then worked out what to change in code and content, grounded in Google's own docs.
FAQPage vs QAPage: what were they, exactly
Foundations first. I'll assume you're new to structured data.
Structured data is a separate layer of machine-readable meaning that sits on top of the HTML humans read. schema.org defines the vocabulary, and you usually drop it into the page as a <script type="application/ld+json"> block. Search engines may use these hints to build a special appearance (a rich result) in the results. The operative word is may, not will. That single distinction is the whole story today.
FAQPage represents a page where each question has one official answer, written by the publisher. Product help, pricing pages, shipping policy pages are the classic cases. Its cousin, QAPage, is a different animal: it's for community pages where users post multiple answers and one gets accepted, like a forum or a Q&A board. Publisher's single answer means FAQPage; multiple user answers mean QAPage. That distinction still holds, and what died is the FAQPage rich result specifically.
The minimal skeleton of FAQPage JSON-LD looks like this:
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "How long does shipping take?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Two to three business days."
}
}
]
}
The required fields are simple. Under FAQPage, a mainEntity array; each item is a Question with name (the question text) and acceptedAnswer (an Answer with text). That skeleton hasn't changed since it launched in 2019. What changed is the work Google does when you add it.
What actually happened: the 2023 cut, the 2026 shutdown
This wasn't Google's first pass at FAQ rich results. Here's the timeline.
In August 2023, Google announced changes to HowTo and FAQ rich results. The official wording: FAQ rich results would show only for "well-known, authoritative government and health websites," and would no longer appear regularly for anyone else. HowTo rich results were dropped altogether. By that point, the FAQ accordion had already vanished from most ordinary sites.
Then in 2026 the remaining steps landed. Pulling the deprecation notes straight from the FAQPage docs:
| Date | What was retired |
|---|---|
| 2023-08 | FAQ rich results limited to authoritative gov/health sites; HowTo removed entirely |
| 2026-01 | FAQ support dropped from Search Console rich result reporting, the Rich Results Test, and search appearance filters |
| 2026-05-07 | FAQ rich results stop appearing in Google Search completely |
| 2026-06-15 | FAQ rich result documentation removed |
Net result: no site can get a results-page accordion from FAQPage JSON-LD anymore. Even the testing tools no longer report the type.
One official limit is worth nailing down here. Google has always stated that structured data doesn't guarantee a rich result or a ranking. The fall of FAQPage is that principle taken to its extreme. You can implement it perfectly to spec, and whether it shows is entirely the search engine's call. For reference, one industry analysis (SearchEngineLand, not official) counted FAQ rich result presence dropping from roughly 54% of SERPs to about 17% right after the 2023 cut. Treat the number as a reference point, but the direction matches the official shutdown.
Passing the validator doesn't buy you visibility. I measured it
Saying "passing is pointless" without proof is hollow. So in a throwaway sandbox I ran FAQPage JSON-LD through an offline validator: a ~40-line Node script that checks only the schema.org required structure, no network. I fed it one clean sample and one deliberately broken one.
The core of the check:
function validateFaqPage(doc) {
const errors = [];
if (doc["@type"] !== "FAQPage") errors.push('@type is not "FAQPage"');
const items = Array.isArray(doc.mainEntity) ? doc.mainEntity : [];
if (items.length === 0) errors.push("mainEntity has no Question");
items.forEach((q, i) => {
if (!q.name?.trim()) errors.push(`mainEntity[${i}] missing name (required)`);
const a = q.acceptedAnswer;
if (!a) errors.push(`mainEntity[${i}] missing acceptedAnswer (required)`);
else if (!a.text?.trim()) errors.push(`mainEntity[${i}] missing answer.text (required)`);
});
return errors;
}
The run came back like this:
[faqpage-sample.jsonld]
schema-structure : PASS
google-rich-result : DEPRECATED (feature removed 2026-05-07)
[faqpage-broken.jsonld]
schema-structure : FAIL
google-rich-result : DEPRECATED (feature removed 2026-05-07)
- mainEntity[0] missing acceptedAnswer (required)
- mainEntity[1] missing name (required)
The clean sample passes the structural check (PASS). The line right next to it says DEPRECATED. However green your validator turns, the stage where Google Search would render that has already closed. That's the one-line summary: schema validity and visibility are separate axes, and a CI gate only sees the first one. Anyone running a CI pipeline that auto-validates structured data should keep this blind spot in mind. A passing gate does not mean traffic value attaches.
There's a second thing to notice in the broken sample. The validator still catches missing required fields precisely. The structural check itself isn't dead. What died is the Google rich-result reward that used to ride on top of it. That distinction drives the next decision.
So do you delete it or keep it? Google's answer and mine
The most common question: "Rich results are gone, so should I strip out all the FAQPage markup?"
Google's official guidance is clear. There's no need to proactively remove it. Structured data that isn't being used doesn't cause problems for Search, but it also has no visible effect. Keeping it does no harm; deleting it costs you nothing. On the Google-rich-result axis alone, FAQPage JSON-LD is now neutral dead code.
For new pages, I won't invest fresh effort adding FAQPage JSON-LD for Google's benefit. There's no reason to grow my maintenance surface with markup that pays zero visual dividend. On the flip side, if a legacy site already has it embedded at scale, I won't rush a sweeping migration to strip it either. Google said it's harmless, and the removal work itself introduces regression risk. Honestly, this is one of those rare cases where actively doing nothing is the best move.
One condition, though. "Don't delete" refers to the JSON-LD block. The Q&A content inside it follows a completely different fate. If anything, it's about to matter more.
Where rich results died, AI is reading
This is the real reason I wrote the piece.
The results-page space that FAQ rich results left behind is filling fast with AI Overviews and other generative answers. And the way an AI answer engine pulls information off a page is fundamentally different from a Google rich result. Rich results read a separate channel called JSON-LD. Most AI crawlers, by contrast, extract meaning from the rendered HTML body itself. And a "clear question → short, self-contained answer" pattern is the most quotable shape a machine can find.
So the real asset in FAQPage was never the JSON-LD type name. It was the discipline it forced: a sharp question, and an answer that resolves on the spot. Don't lock that discipline inside JSON-LD. Pull it out into visible, semantic HTML. That's the move now. Concretely:
- Mark up questions as real heading elements (
<h2>/<h3>) or a definition list (<dl><dt>). AI crawlers read them straight from the body. - Make the answer self-contained in the paragraph right after the question. An answer that leans on context ("as explained above") falls apart the moment it's sliced into an extraction unit.
- One question, one answer. Keep FAQPage's original character — (the publisher's single authoritative answer) at the content level.
Now the honest limit. That AI engines actually quote this structure more readily is my practitioner's judgment plus a synthesis of observations, not an official number Google has guaranteed (reference, not official). The selection logic behind AI Overviews is undisclosed, and I don't make claims about the internals of ranking systems. What I will state flatly is this: the channel machines read has moved from JSON-LD to the rendered body, so it's rational to move your investment there too.
The takeaway: the call to make in front of FAQ markup
Compressed to one line: FAQPage JSON-LD aimed at Google rich results is over, but the Q&A content structure is appreciating in the AI era.
I'll close with a checklist you can apply now.
- New pages: don't add FAQPage JSON-LD for the sake of Google rich results. The visual payoff is zero.
- Existing JSON-LD: don't rush to strip it. Google calls it harmless, and removal is the bigger regression risk. Keep it if you want Bing/other engines or schema.org completeness.
-
Q&A content: don't hide it inside JSON-LD. Expose it in rendered semantic HTML (
<h2>,<dl>). That's the channel AI crawlers read. - Answer shape: resolve it in the paragraph right after the question. Context-dependent answers break on extraction.
- Validation gate: your CI schema check only guarantees structural validity. Make it explicit to the team that visibility and citation value are a separate axis.
- Expectations: structured data guarantees neither ranking nor visibility (Google, official). FAQPage is the living proof.
I take on private consulting and implementation work for getting structured data out server-side reliably, and for auditing a site's Q&A structure and schema against the rich-result shutdown and the shift toward AI citation. If you need a call on which markup to keep and which to promote into content, my contact is on the profile.
Top comments (0)