FAQPage schema after the rich-result changes

FAQPage is the schema most likely to be added by habit. For years it was the reliable way to get a rich result: mark up a few questions, and the search result grew a list of expandable answers. Then Google restricted the rich result, and the markup was left in place on a lot of sites without anyone asking what it still does. This article is about what it still does, what it does not, and how to use it without producing the kind of markup that only exists to satisfy a checklist.

What changed

In August 2023, Google limited FAQ rich results to a small set of well-known authoritative government and health sites. For most sites the markup is still supported and still valid, but it no longer produces the expandable rich result that motivated it. Google’s FAQPage documentation is the place to confirm the current policy; the important part for a site owner is that "markup present" and "rich result shown" stopped being the same thing.

That does not make the markup worthless. It changes the reason to use it. If the only reason was the rich result, the reason is mostly gone. If the reason is that the page genuinely contains a set of buyer questions and answers, and stating that structure explicitly helps a machine parse it, the markup is still a cheap and honest signal.

What a FAQ page is actually good for now

• Extraction. A question followed by a direct answer is the shape an answer engine wants. The markup makes that boundary explicit instead of leaving it to a parser to infer from headings.
• Consistency. Writing the questions down as structured data forces the page to answer them in visible text. A FAQPage whose questions appear nowhere in the body is a claim the page cannot support.
• Support and documentation. On help pages, a real question list is useful to readers first; the markup is a description of that list, not a substitute.
• Small cost. A handful of Question/acceptedAnswer pairs is a few hundred bytes. The risk is not the size; it is the temptation to mark up questions no one asked.

The shape of a valid, honest FAQPage

The visible content comes first. The markup repeats what is already there, with the same wording, on the same page.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Does a FAQPage still produce a rich result?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "For most sites, no. Google restricted FAQ rich results in 2023 to a small set of authoritative government and health sites."
      }
    }
  ]
}

Three details matter more than the JSON syntax. One: one FAQPage per page, covering the questions on that page, not a copy of the site-wide FAQ on every URL. Two: the name and text should match the visible question and answer, including the qualifying sentence that stops the answer being over-read. Three: the questions should be ones a reader would actually ask — the test is whether the page is better because the answer is written down, not whether the markup validates.

What the scanner checks — and what it does not

The rule is faq, worth 3 points in the answer readiness dimension. The condition is a parsed FAQPage node. A page that uses <details>/<summary> without the schema gets a partial pass, because the Q&A structure exists but is not machine-labelled.

The rule page is explicit about the limit: a FAQPage with an empty mainEntity list, or one whose questions appear nowhere in the visible text, still passes. Comparing the markup with the page is a judgement the scanner does not make. That is the same trade as the other markup checks — cheap presence, honest note — and it is why a green check here means "there is a node", not "there is a useful FAQ".

What to do instead of adding FAQPage everywhere

Markup is not the first move. If a page has no real questions, adding FAQPage does not give it any; it gives it a structure with nothing behind it. The order that works is:

1. Find the questions people actually ask — from support mail, sales calls, search queries and the questions a buyer asks before paying. Five to ten is enough.
2. Write the answers on the page, in the same words the markup will use. Short, specific, with the limits stated.
3. Mark up those pairs, with one FAQPage node for the page.
4. Validate the markup and compare the visible questions with the schema; remove any pair that exists only in the JSON.

How to check a page you already have

# 1. Is there a FAQPage node in the server response?
curl -sS https://your-domain.com/page/ | grep -c 'FAQPage'

# 2. Count how many questions the markup claims
curl -sS https://your-domain.com/page/ \
  | python -c "import sys,json,re; html=sys.stdin.read(); \
      blocks=re.findall(r'<script[^>]*application/ld\\+json[^>]*>(.*?)</script>', html, re.S); \
      pages=[json.loads(b) for b in blocks]; \
      print(sum(len(p.get('mainEntity', [])) for p in pages))"

# 3. Count the visible question headings on the page (by hand is fine)
grep -o '<h[23][^>]*>[^<]*?</h[23]>' <<< "$(curl -sS https://your-domain.com/page/)" | wc -l

If the schema count is higher than the number of visible questions, the page is claiming more than it shows. That is the failure to look for; it does not show up in a validator, because the JSON is valid either way.

What FAQPage does not do

It does not restore the rich result for most sites, it does not make a page rank, and it does not guarantee that an AI engine reads or quotes the answers. What it does is describe a structure that is already useful when the questions are real. That is a small, honest benefit — which is exactly the right size for a markup property that costs a few hundred bytes.

The general rule from the rest of this series applies here too: add the markup because the page already earns it, not because a check expects it. A FAQ written for a check is a FAQ nobody asked.