The confusion between FAQPage and QAPage schema is understandable because both deal with questions and answers. The distinction comes down to who authored the answers and how many answers each question has. Getting this wrong does not just cause a validation warning — it means you are describing your content inaccurately to Google, which can affect how it is interpreted and whether it qualifies for rich results.

FAQPage: one question, one definitive answer

FAQPage is intended for pages where the site owner has written both the questions and the authoritative answers. There is one answer per question, and that answer is not open to community contribution or voting. A classic use case is a support FAQ page where the company answers the same questions customers ask repeatedly. Each question-answer pair is marked up with a Question entity containing an acceptedAnswer property.

{
  '@context': 'https://schema.org',
  '@type': 'FAQPage',
  'mainEntity': [
    {
      '@type': 'Question',
      'name': 'What is schema markup?',
      'acceptedAnswer': {
        '@type': 'Answer',
        'text': 'Schema markup is structured data added to a page to help search engines understand the content.'
      }
    },
    {
      '@type': 'Question',
      'name': 'Does schema markup affect ranking?',
      'acceptedAnswer': {
        '@type': 'Answer',
        'text': 'Schema markup does not directly affect ranking, but it can improve how your content appears in results.'
      }
    }
  ]
}

QAPage: community-driven answers

QAPage is for pages where a question has been posted and multiple users can submit answers — think Stack Overflow, Quora, Reddit threads, or a community forum. The markup includes one Question entity, and that question can have multiple suggestedAnswer values. One answer can be flagged as the acceptedAnswer if the original poster or moderator selected it.

A minimal QAPage block looks like this. Notice that the @type on the page is QAPage, the top-level mainEntity is a single Question, and answers are listed under suggestedAnswer — not nested inside an FAQPage-style acceptedAnswer array:

{
  '@context': 'https://schema.org',
  '@type': 'QAPage',
  'mainEntity': {
    '@type': 'Question',
    'name': 'How long does a schema audit take?',
    'answerCount': 2,
    'upvoteCount': 14,
    'acceptedAnswer': {
      '@type': 'Answer',
      'text': 'For a site under 500 pages, a thorough schema audit typically takes 3-5 business days.',
      'upvoteCount': 11,
      'url': 'https://example.com/forum/schema-audit-time#answer-1'
    },
    'suggestedAnswer': [
      {
        '@type': 'Answer',
        'text': 'Depends on the site size, but expect at least a week for large e-commerce catalogs.',
        'upvoteCount': 3,
        'url': 'https://example.com/forum/schema-audit-time#answer-2'
      }
    ]
  }
}

How to choose between the two

If you wrote the questions and you wrote the answers and the answers are not community-submitted, use FAQPage. If the content is structured as a question that users or community members answer, use QAPage. A blog post that includes a FAQ section at the bottom falls under FAQPage, not QAPage, because the author controls all the content. A public forum thread where someone asked a question and got multiple replies is a QAPage.

One edge case worth flagging: if you run a knowledge base where you write the official answer but also allow comments or community responses below it, the page type should match the primary content model. If the authoritative answer is what users came for and community comments are secondary, use FAQPage. If the user-generated answers are the main value, use QAPage. You cannot mix both types on one page block.

The role of @context and @type in machine understanding

Both FAQPage and QAPage are nodes in the Schema.org vocabulary, which Google’s parsers use to build an understanding of your content as entities — not just keywords. The @context property (https://schema.org) tells the parser which vocabulary to apply. The @type tells it what kind of thing this page describes. When you set @type to FAQPage, Google’s knowledge graph processing treats the page as a canonical source of authoritative Q&A authored by the site owner. When you set it to QAPage, it expects crowd-sourced signal patterns — upvote counts, multiple contributors, an answer hierarchy.

This matters for AI Overviews and LLM-based answer systems. These systems increasingly rely on structured data as a machine-readable signal of content authorship and confidence. FAQPage markup sends a clearer entity signal for single-answer Q&A content: one question, one authoritative answer, published by the site owner. That signal is more useful for an AI system that needs to attribute an answer to a specific source. QAPage is less common in AI Overview attribution because the multi-contributor model introduces ambiguity about which answer is authoritative.

Google rich result eligibility

FAQPage markup has historically triggered accordion-style FAQ rich results in Google search. Google has scaled back when these appear, but they still show for some queries and site types. QAPage rich results are less common in standard web search but are used in Google’s AI-driven answer features. Either way, having the correct type applied is better than using the wrong one and hoping the parser overlooks it.

What happens when you apply the wrong type? Google does not penalize you in the traditional ranking sense — you are not going to lose positions because you used FAQPage on a forum thread. But you will fail rich result eligibility, and the structured data may be ignored entirely during processing. I have seen sites spend hours troubleshooting why their FAQ rich results stopped showing, only to find they had applied suggestedAnswer inside an FAQPage block — a property that belongs to QAPage, not FAQPage. Google’s Rich Results Test will flag this, and the Schema Markup Validator at validator.schema.org will show the property mismatch clearly.

Testing with Schema Markup Validator and Rich Results Test

There are two distinct checks to run on any FAQ or QA markup. The Schema Markup Validator (validator.schema.org) checks conformance against the Schema.org specification — whether your @type and properties are syntactically and semantically correct according to the vocabulary. The Google Rich Results Test (search.google.com/test/rich-results) checks whether your implementation qualifies for Google’s specific rich result features. These are not the same test. You can pass the Schema Markup Validator and still fail the Rich Results Test if you are missing a Google-required property, or if the content in the markup does not match what is visible on the page.

For FAQPage, run both. The most common Rich Results Test failure I see is a mismatch between the text value in acceptedAnswer and the answer visible on the page — often because a CMS truncated the answer string or stripped HTML from it during export.

Common mistakes

  • Applying FAQPage to a forum or community Q&A page where answers are user-submitted.
  • Applying QAPage to a standard FAQ page written entirely by the site owner.
  • Using suggestedAnswer on an FAQPage type instead of acceptedAnswer.
  • Including more than one Question entity in a QAPage block — QAPage describes a single question with multiple answers, not multiple questions.
  • Nesting the answer as a plain text string instead of an Answer entity with a text property.

If you have FAQ sections across multiple pages and are not sure whether the markup is consistent or correct, a schema audit will identify the discrepancies quickly. For more on article-specific structured data types, see BlogPosting Schema Markup. My schema markup consulting page covers how I handle content-type schema decisions for larger sites.