QAPage vs FAQPage Schema: Pick the Right One

QAPage and FAQPage sound interchangeable and are constantly swapped, but they describe structurally different pages. FAQPage is for a page your site authored: a list of questions, each with exactly one official answer you wrote. QAPage is for a page built around one question that multiple users answered: a forum thread, a support-community post, a Stack Overflow-style page. If your marketing team wrote both the questions and the answers, FAQPage is correct and QAPage is wrong - full stop.

Getting this right matters more for AI search than the old rich-result debate suggests. AI engines parse structured data to understand what a page claims to be, and markup that misdescribes the page is a trust signal pointing the wrong way. Here is the structural difference, the eligibility rules, and clean JSON-LD for each.

The structural difference

The two types encode different social situations.

• FAQPage: one voice, many questions. The page owner asks and answers everything. Each Question has exactly one acceptedAnswer, and that answer is the site's official position. Think pricing FAQs, product documentation, policy pages.
• QAPage: one question, many voices. The page exists because somebody asked a single question and other people answered it. The markup carries one Question with an answerCount, optionally one acceptedAnswer chosen by the asker or moderators, and multiple suggestedAnswer entries from the community. Vote counts and per-answer authors are part of the model.

The tell is authorship. FAQPage answers have no meaningful author distinct from the site. QAPage answers do: each one belongs to a user, and the page's value is the aggregation of those users' contributions. That is why schema.org/QAPage models upvotes and answer counts while schema.org/FAQPage does not.

Google's eligibility rules

Google documents hard requirements for both types, and they are worth following even where the rich results no longer show, because the same rules describe what parsers expect.

For QAPage, the page must actually contain a question with user-submitted answers. One question per page, marked as the main entity. Pages where users cannot add answers are explicitly out of scope, and Google names the misuse directly: do not use QAPage for FAQ content where there is no way to submit alternative answers.

For FAQPage, the questions and answers must be written by the site, the full answer text must be visible on the page, and each question appears once with one answer. Google also restricted FAQ rich results in 2023 to a small set of authoritative government and health sites, so for most sites FAQPage markup no longer earns a visual rich result in Google's SERP. The markup itself remains valid and parseable, which is exactly why it still matters for AI engines.

The eligibility rules give you a two-question test. Did users write the answers? If yes, QAPage; if no, FAQPage. Is there more than one question on the page? If yes, QAPage is ineligible regardless of everything else.

What AI engines do with each type

Argue from mechanism here, not from magic. AI search engines retrieve pages, parse them (JSON-LD is the cheapest-to-parse content on any page), and select passages to ground answers. Both schema types hand the parser pre-segmented question-answer pairs with clean boundaries - which is precisely the shape an answer engine wants, since user prompts are questions and grounded answers need self-contained passages. We cover why that pairing lifts citation odds in FAQ schema: when it lifts citations.

The types carry different evidentiary weight, though. FAQPage says "this is the site's official answer", which fits brand, product, pricing, and policy questions: the site is the authority on itself. QAPage says "this is what a community concluded", which fits experience questions, and engines demonstrably draw on community sources for exactly those queries - it is the same mechanism that makes Reddit and forum threads such frequent citations. An acceptedAnswer with a high upvoteCount gives an engine a defensible reason to prefer that passage over the seventeen other replies in the thread.

What no engine rewards is markup that contradicts the page. Structured data is a claim about the page, and parsers can check claims against visible content. Marked-up answers that do not appear in the rendered HTML, or a "community" that is actually one marketing department, are detectable inconsistencies on a page asking to be trusted.

The common misuse: marketing FAQs dressed as QAPage

The most frequent mistake we see is sites marking ordinary FAQ sections as QAPage, usually chasing the richer-looking result format or hedging with both types at once. It fails the spec on two counts simultaneously: multiple questions on one page, and zero user-submitted answers. Google's documentation calls this out as a violation, and validators flag it.

The reverse mistake exists too. Forum platforms and support communities sometimes stamp FAQPage on thread pages because a plugin defaulted to it. That throws away the type's real advantages: the accepted-answer signal, vote counts, and per-answer attribution all have nowhere to live in FAQPage.

And do not double-mark. One page, one page-level type. If you run a support community and a marketing FAQ, those are two pages with two different types, linked to each other.

Implementation: clean JSON-LD for both

A minimal FAQPage, for a page your team wrote:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Does Citevera require access to my CMS?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "No. Audits run against your public site, so there is nothing to install for a first scan."
    }
  }, {
    "@type": "Question",
    "name": "How often should I re-audit?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Monthly for active sites. Re-audit after any template, schema, or robots.txt change."
    }
  }]
}

A minimal QAPage, for a community thread:

{
  "@context": "https://schema.org",
  "@type": "QAPage",
  "mainEntity": {
    "@type": "Question",
    "name": "How do I stop Cloudflare challenging GPTBot?",
    "text": "My robots.txt allows GPTBot but the logs show challenge pages. What setting is doing this?",
    "answerCount": 3,
    "upvoteCount": 12,
    "author": { "@type": "Person", "name": "jmartins" },
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Check Security > Bots. The AI crawler block runs before robots.txt is consulted.",
      "upvoteCount": 9,
      "author": { "@type": "Person", "name": "edge-admin" }
    },
    "suggestedAnswer": [{
      "@type": "Answer",
      "text": "Also review custom WAF rules that challenge datacenter ASNs.",
      "upvoteCount": 4,
      "author": { "@type": "Person", "name": "cwei" }
    }]
  }
}

Every marked-up answer must be visible on the page, and the vote counts should reflect real UI state, not decoration. Emit the block server-side in the page head so crawlers that skip JavaScript still see it, and generate it from the same data source that renders the visible Q&A - hand-maintained duplicates drift, and drift is the failure mode this whole post is about. On QAPage specifically, keep the counts current: a thread that gained twenty answers since the markup was generated is publishing a stale claim on every fetch.

Validate with the Rich Results Test before shipping; our schema validation tools roundup covers what each validator does and does not catch. Note that validators check syntax and required properties, not truth - "FAQPage on a forum thread" parses perfectly and is still wrong, so the two-question authorship test stays a human job.

Frequently asked questions

Can one page use both QAPage and FAQPage?

No. They are mutually exclusive page-level types describing what the page fundamentally is, and a page cannot simultaneously be a single community thread and an authored FAQ list. Pick the type that matches how the answers were produced, and keep one page-level type per page.

Does FAQPage markup still matter now that Google restricts FAQ rich results?

Yes, for a different consumer. The 2023 restriction changed what Google displays in its SERP, not what parsers extract. AI engines still read the markup as pre-segmented question-answer passages with the site's official stamp, and that extraction path is unaffected by rich-result eligibility.

My FAQ page has a comments section. Does that make it a QAPage?

No. The type follows the main entity of the page, not its appendages. If the substance is site-authored questions and answers, it is FAQPage; an open comment thread underneath does not turn your answers into community answers. QAPage requires the answers themselves to be user-submitted.

Should the answer text in JSON-LD match the visible text exactly?

Keep it materially identical. Trimming whitespace or dropping an inline image is fine; rewriting the answer into different claims is not. Divergence between markup and rendered content is the kind of inconsistency that costs trust with both Google and AI parsers, since both can compare the two.

Check what your markup claims

Mismatched Q&A markup is one of the most common findings in Citevera audits: QAPage on marketing FAQs, FAQPage on forum threads, or answers that exist in JSON-LD but not in the HTML. An audit flags each page-level type against what the page actually is and generates corrected markup you can paste in - see where schema sits in the AI-search priority order for how much of your score this covers. Match the type to the truth of the page and both Google and the answer engines can take your Q&A at face value.