FAQ content that answer engines pick up (and why FAQPage rich results went away)

What changed, and what did not

The FAQ rich result — the expandable question-and-answer block that used to appear under a Google listing — went away in two steps.

On 8 August 2023, Google's Search Central blog announced that FAQ rich results would "only be shown for well-known, authoritative government and health websites"; for every other site the rich result "will no longer be shown regularly". The same post said there was no need to remove the markup: "structured data that's not being used does not cause problems for Search, but also has no visible effects in Google Search."

On 8 May 2026, Google's documentation changelog added a deprecation notice stating that the feature "will no longer appear in Google Search starting May 7, 2026". In June 2026 the changelog recorded that the FAQ rich result documentation had been removed altogether.

That is the whole story of the rich result. Three things did not change.

• FAQPage is still a valid schema.org type. schema.org/FAQPage defines it as "a WebPage presenting one or more 'Frequently asked questions'", a subtype of WebPage. The vocabulary is unchanged and anything that parses JSON-LD can still read it.
• Question-and-answer pairs are still the tidiest passage a retrieval system can extract. Answer engines split pages into chunks and score each chunk against a query. A heading that is the question, followed by a paragraph that is the answer, is a chunk that needs no context from anywhere else on the page.
• Visible text is still what counts. Google's documentation for 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". The requirement is that the page is indexed and eligible to be shown with a snippet.

So the job of an FAQ section moved. It used to be a search-result decoration. Now it is a set of quotable passages that also carry a machine-readable label.

Find the questions people actually ask

An FAQ written from inside the company answers questions nobody asked. An FAQ that gets cited answers the questions people type into a search box or an assistant. There are four cheap places to find them.

1. People Also Ask. Search for your main query in Google and expand the People Also Ask box; each expansion reveals further questions, phrased the way searchers phrase them.
2. Forum phrasing. Reddit threads, Stack Overflow, GitHub issues and product forums show the question with its constraints attached: "does X still work if I…".
3. Assistant-style prompts. Questions put to ChatGPT, Claude or Perplexity are longer and more conversational than search queries, and often carry a situation ("I run a Next.js site and…"). Write at least one question in that register.
4. Your own data. Search Console queries containing "how", "why", "can", "does" and "vs"; support tickets; sales call notes.

Keep the phrasing: the heading should read the way the question is asked, not the way a marketing team would rewrite it.

One question per item. "How do I install it and what does it cost?" is two chunks fighting over one heading.

Write answers that stand on their own

An answer engine will lift the answer paragraph out of your page and drop it into a context where the heading, the previous paragraph and the product name may all be missing. Write for that context.

• Name the entity in the first sentence. "FAQPage markup is still valid schema.org" travels; "Yes, it still works" does not.
• Answer, then qualify. The first sentence is the answer. The second and third add the condition, the exception or the number. Nothing comes before the answer.
• Stay within 40–80 words. Long enough for an answer and one qualification, short enough to be quoted whole. An answer that wants 300 words is a section or a page; write the short answer here and link to the long one.
• Put one verifiable thing in it. A date, a version, a named source, a number with a unit. The GEO study by Aggarwal et al. found that adding citations, quotations and statistics raised a source's visibility in generated answers substantially.
• No back-references. No "as mentioned above", no "this" without a noun, no "the tool" when you mean the product name.

Put the answers in the HTML with native details

The most common way FAQ sections fail is an accordion that renders the question in HTML and fetches the answer only on click. A crawler with a small rendering budget sees questions with nothing under them.

The fix is the platform's own disclosure widget. MDN describes <details> as a widget "in which information is visible only when the widget is toggled into an open state", and the content stays in the DOM whether the widget is open or closed. A group of <details> elements that share a name attribute behaves as an exclusive accordion — "only one of the grouped <details> elements can be open at a time" — with no script at all.

<section aria-labelledby="faq-heading">
  <h2 id="faq-heading">Frequently asked questions</h2>

  <details name="faq" open>
    <summary>
      <h3>Should I remove FAQPage markup now that the rich result is gone?</h3>
    </summary>
    <p>No. Google's 2023 announcement said there was no need to remove it,
    and unused structured data does not cause problems for Search…</p>
  </details>

  <details name="faq">
    <summary>
      <h3>How long should an FAQ answer be?</h3>
    </summary>
    <p>Aim for 40–80 words…</p>
  </details>
</section>

Three details matter.

• Open the first item by default. Google's general structured data guidelines say "don't mark up content that is not visible to readers of the page". An open first answer leaves no room for argument.
• Keep the heading outline intact. Each question is an <h3> under the FAQ <h2>, so a chunker gets one heading-plus-paragraph unit per item.
• Do not fetch on demand. If the answer text is not in the initial HTML response, assume it is not in the index.

Generate FAQPage JSON-LD from the same fields

The shape Google documented while the rich result existed, and which schema.org still defines, is small: a FAQPage whose mainEntity is an array of Question, each Question with a name and an acceptedAnswer, and each Answer with text. That is the whole schema. Google's general guidelines require markup to describe what the HTML body shows, so generate it from the same fields that render the visible FAQ, never from a second copy.

// lib/faq-jsonld.ts
export interface FaqItem {
  question: string;
  answer: string; // plain text, or minimal HTML
}

export function faqPageJsonLd(items: FaqItem[]) {
  return {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    mainEntity: items.map((item) => ({
      "@type": "Question",
      name: item.question,
      acceptedAnswer: { "@type": "Answer", text: item.answer },
    })),
  };
}

In a Next.js App Router page, pass the same items array to the visible <Faq> component and to a <script type="application/ld+json"> tag rendered from faqPageJsonLd(items). One source, two outputs.

Two things not to do:

• Do not use QAPage for an FAQ. Google's QAPage documentation is explicit: "Don't use QAPage markup for FAQ pages or pages where there are multiple questions per page." QAPage is for a single question with user-submitted answers, such as a forum thread.
• Do not mark up a question whose answer is on another page. The text of each Answer must be the answer, on this page; "see our pricing page" is a link, not an answer.

A dedicated FAQ page or an FAQ inside the article

Both work; they do different jobs.

Two rules cut across both.

1. One question per URL when the question is big. If a question needs more than a paragraph, it has become a guide. Give it a page with the question in the title and H1, and leave a short answer plus a link in the FAQ.
2. Never duplicate the main answer in the FAQ. If the article's opening paragraph answers "what is X", the FAQ should not ask "what is X" again. Two near-identical passages on one page compete in retrieval and dilute both.