FAQ schema: when it helps, when it does nothing, and the markup that validates

FAQ schema is a label, not a promotion. It tells a crawler, “these visible lines are questions, and these visible lines are their answers.” That is useful when the page really contains an FAQ. It does not guarantee a rich result, improve a thin answer or give a page permission to occupy more space in search.

That distinction matters because much of the advice about FAQ markup was written when expanded FAQ results were common. The visible reward changed. The basic job did not: accurate structured data still gives machines a cleaner description of the page they have fetched.

A valid FAQ schema example

This is the smallest useful JSON-LD shape for two questions:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How long does delivery take?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Standard delivery takes three to five working days."
      }
    },
    {
      "@type": "Question",
      "name": "Can I change my delivery address?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. Contact us before your order is dispatched."
      }
    }
  ]
}
</script>

The same two questions and answers must appear where a visitor can read them. An accordion is fine when its answers can be opened normally. A script block containing extra sales copy, links or questions absent from the page is not.

The eligibility question comes before the code

Before writing markup, ask what kind of page you have.

Use FAQPage when one publisher supplies the answers. A service page with a short “Common questions” section fits. A product page with answers written by the shop can fit. A community page where several people submit competing answers is a different content type and should not be forced into FAQ markup.

Do not mark up a question simply because its heading ends with a question mark. An article called “What is technical SEO?” is not automatically an FAQ page. The structured data should describe the page’s real form, not the query you hope it ranks for.

What FAQ schema can and cannot do

It can:

• identify the exact boundary between a question and its answer;
• preserve that relationship when the page layout contains accordions, cards or other surrounding elements;
• make concise answers easier for parsers to extract;
• expose mismatches between the visible page and the data your template emits.

It cannot:

• guarantee an FAQ rich result;
• make an unsupported claim trustworthy;
• rescue a page that does not satisfy the search intent;
• turn hidden keyword variants into visible content;
• replace useful headings and readable answers in the HTML.

The practical benefit is therefore smaller and steadier than “get a bigger search result.” It is clean publishing. If a question deserves a place on the page, expressing it accurately in the page’s data is reasonable. If the only reason for adding the question is the markup, leave both out.

Five FAQ schema errors worth checking

1. The marked-up answer differs from the page

This often happens after an editor changes the visible copy while a plugin or theme retains an older answer. Validation may still pass because the graph is syntactically perfect. Compare meaning, not merely field presence.

2. The same questions appear on every URL

“How do I contact you?” may belong on a central help page. Repeating it across every service and location page does not make each page more relevant. Put questions where the answer changes or where the reader genuinely needs it.

3. Several FAQPage blocks describe one section

Page builders and SEO plugins can both emit markup. The result is two graphs with overlapping questions. Choose one owner for the section and inspect the rendered HTML, not just the editor screen.

4. HTML inside the answer is broken or overdone

Simple links and formatting can be represented in answer text, but the value should still be a readable answer rather than a miniature landing page. Escape quotes correctly and keep promotional calls to action outside the answer when they are not part of it.

5. The page is blocked, canonicalised elsewhere or not indexable

Perfect schema on a URL a crawler cannot use is decoration. Check indexability and the canonical URL before debugging why a rich result does not appear.

A sensible workflow

1. Write the questions people actually ask at that point in the journey.
2. Answer each in the first sentence, then add only the detail needed.
3. Publish the section visibly in the HTML.
4. Generate one FAQPage graph from the same content source.
5. Validate the final rendered page.
6. Recheck after changing a template, plugin or page builder.

The safest implementation stores each question and answer once, then renders both the visible section and JSON-LD from that source. Maintaining two copies is how drift begins.

FAQ schema and AI answers

Structured data is not a private feed into an assistant. An assistant may ignore it, may use the visible text, or may never fetch the page. The useful part is alignment: a direct question, a self-contained answer and markup that confirms their relationship all describe the same thing.

That is also why verbose answers perform poorly here. The first sentence should stand on its own. If an answer needs qualifications, put them after the direct response rather than making a reader cross three clauses before learning “yes,” “no,” “three days” or “it depends on the plan.”

If you already have an FAQ section, use the FAQ schema prompt to turn its visible copy into a graph and a mismatch checklist. If you do not have the section yet, write that first. The schema is the final five per cent of the job.