Skip to content
pageinspection

FAQPage schema: how to mark up an FAQ, and whether it still pays

Google narrowed FAQ rich results to a short list of authoritative site types, and a lot of people concluded FAQPage markup was dead. What actually happened is that its purpose moved: it stopped being a way to take up more room on a results page and went back to being a way to state, unambiguously, that this text is a question and that text is its answer.

The short answer

Google restricted FAQ rich results to government and health sites in 2023, so most sites will not see a rich result from FAQPage markup. It is still worth adding where the page genuinely has questions and answers, because the markup is how a question and its answer stay paired when a machine reads the page. The rule that gets it ignored is marking up content the visitor cannot see.

ImportantAudit check · FAQ Schema

What changed, and what it means for you now

FAQ rich results, the expandable question list under a search result, were widely available and then deliberately restricted to well-known authoritative government and health sites. For everyone else the visual reward disappeared. The markup remained valid, supported and parsed.

That distinction matters because it changes who should bother. If your reason for adding FAQPage was owning more vertical space on a results page, that reason is gone and you should stop. If your reason is that machines other than Google's result renderer read structured data, the change did nothing to you, and there are now more of those machines than there were.

The markup lost a feature. It did not lose its meaning.

What counts as a pass here

Valid JSON-LD on the page with @type: "FAQPage", containing at least one Question with an acceptedAnswer. Parse failures are reported as failures rather than as absence, because a block of JSON-LD with a trailing comma is worse than no block at all: you think you have markup and no parser can read it.

Crucially, this check does not fire on every page that lacks FAQPage. Most pages should not have it. It is reported against pages built around a question-and-answer structure, and a missing FAQPage on a product listing is correct rather than an oversight.

Check one page for FAQPage markup

Paste a URL. This reports which schema types the page declares and whether FAQPage is among them.

Check one page for FAQPage markup

No signup required. Each free search audits one page, paste any URL to see it in action.

The markup, in full

One script tag in the head or body, one object, one array of questions. Answers may contain HTML, which is the part people miss and the reason a linked answer does not have to be flattened to plain text.

faq-schema.html
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Do the free limits reset every month?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Every 30 days, counted from your first
                 audit rather than from the 1st of the
                 month. All three counters reset together."
      }
    },
    {
      "@type": "Question",
      "name": "Can I audit a site behind a login?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Not by crawling it. The crawler is an
                 anonymous visitor and holds no
                 credentials, so use the
                 <a href=\"/audit\">pasted-HTML</a>
                 route for pages that need a session."
      }
    }
  ]
}
</script>

Three details that decide whether it validates. name holds the question and is plain text only, so markup inside it is invalid. text holds the answer and may contain a limited set of HTML, with the quotes escaped as above. And there is exactly one FAQPage per page: two blocks each declaring FAQPage is a conflict, not an addition.

The rule that gets markup ignored, or worse

Every question and answer in the markup must be visible on the page to the user. Not paraphrased, not summarised, not present in a collapsed accordion that never loads the content. The same text, readable.

This is the rule that gets broken most often, and the breach is usually well-intentioned: someone writes twelve richly detailed answers in the JSON-LD and shows six short ones on the page, reasoning that the machine can have the long version. That is structured data that contradicts the page, which is a manual-action risk rather than a missed opportunity.

An accordion is fine. An accordion that fetches its answers on click is not.

Collapsed content counts as visible as long as the text is in the HTML and expanding is a CSS state change. If the answer arrives from an API when the user clicks, it is not on the page as far as a parser is concerned, and your markup is describing content that is not there.

Who still gets something out of it

Worth being concrete, because the answer is not everyone.

  • Sites in the remaining eligible categories. Government and health authorities can still get the rich result. If that is you, nothing changed at all.
  • Anyone whose answers get read by a machine. Voice assistants, retrieval pipelines and any tool consuming schema.org get an explicit question-answer pairing rather than having to infer one from your headings.
  • Sites with genuine FAQ content and a search box. Your own site search, and any internal tool consuming your pages, can use the same structure. This is the benefit nobody counts and the one you fully control.
  • Nobody chasing snippet real estate. If the plan was to make your result taller, the plan no longer works and adding markup will not change that.

Why additive markup caps out at Important

Because it is additive. A page with real questions and no FAQPage markup still ranks, still answers the question, and still gets read: you have declined to state the structure explicitly, and a parser has to infer it from your headings instead. Inference usually works.

It sits above Refinement because the inference sometimes fails, and because the failure mode of the alternative, a machine guessing which of your paragraphs answers which of your headings, is exactly what a broken outline makes worse. The two checks compound, which is why they are related.

Confirming it parses

Run the page through Google's Rich Results Test, which reports parse errors and missing required properties, and remember that "valid" there means the syntax is correct rather than that a rich result will appear. For a plain syntax check the Schema.org validator is faster and does not imply anything about eligibility.

Then do the check no tool performs: put the markup and the rendered page side by side and confirm every question in the JSON-LD appears on the page, in words, as text a person can read. That is the requirement most likely to be violated and the only one with a penalty attached.

Questions this check raises

Is FAQ schema still worth adding after the 2023 change?
For the rich result, no, unless you are a government or health site. For everything else that reads structured data, yes: the markup pairs a question with its answer in a form that survives extraction, which is the cheapest thing in a document for a retrieval system to lift whole.
Can I mark up FAQs that are hidden behind an accordion?
Yes, provided the content is present in the HTML and reachable by clicking. Hidden by default is fine; not present on the page at all is not. Marking up questions and answers that appear nowhere in the visible page is the violation that gets the markup ignored, and at scale it is a manual action risk.
Should every page have an FAQ section?
No. Adding a question section to a page that does not naturally raise questions produces filler, and the markup then describes filler. Use it where the questions are ones readers actually ask, and where you would want the section on the page even if no markup existed.