Most teams paste FAQPage everywhere — and most of them are wrong

Here’s the pattern we see on nine out of ten audits. The team added an FAQ block to a blog post, slapped @type: FAQPage on it, validated it in Google Rich Results Test, ticked the box, moved on. That was a defensible move in 2020. It’s a citation leak in 2026.

LLM extractors got picky. ChatGPT, Perplexity and Gemini each have their own preferences for how a Q&A block should be structured, and the wrong wrapper schema sends the page into the “summarise, don’t cite” bucket. The page has the answer. The AI quotes a competitor.

Three patterns matter — FAQPage, QAPage, and Article-with-FAQ-section. Each has a different correct use case. Below is what each one actually is, when to deploy it, and the JSON-LD that extracts cleanly.

FAQPage — what it is and where it belongs

FAQPage is a page-level type that says “this page is a curated FAQ”. The mainEntity array is a list of Question objects, each with one acceptedAnswer. There’s no concept of competing answers, voting, or community contribution — it’s editorial Q&A authored by the site.

The right home for FAQPage is a service page, a product page, a pricing page, a help-centre article — somewhere with five to ten stable questions the team curated and stands behind. The page exists to answer those questions; the FAQ is the page’s primary content, not a supplement.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "@id": "https://answerly.agency/services/aeo-starter-audit#faq",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How fast do we see results from an AEO audit?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "First citation lift typically appears 14–60 days after deploying the punch-list. Full effect lands by month 3."
      }
    },
    {
      "@type": "Question",
      "name": "Does the audit include implementation?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Starter is audit-only — your team or another agency ships the punch-list. Growth and Scale include implementation."
      }
    }
  ]
}

That’s a clean FAQPage. One acceptedAnswer per Question. No AnswerCount field, no upvoteCount, no suggestedAnswer. Those belong on QAPage.

A note on the Google rich-result side. Google retired the FAQ rich result for most sites in August 2023 — only well-known authoritative health and government domains still get it. So if your reason for using FAQPage was “to get the rich snippet”, that reason is gone. The reason to use it now is LLM extraction, and that goal has different rules.

QAPage — what it is and where it belongs

QAPage models a different shape. One user asked one question. The page collects an accepted answer plus zero or more suggested answers. Voting, AnswerCount, dateCreated on each answer — these all make sense because the page is a forum thread, not editorial copy.

If you’ve ever looked at the JSON-LD on a Stack Overflow question, you’ve seen QAPage in the wild. That’s the canonical use case. Reddit, Quora, community forums, support boards where users post questions and other users (or the brand’s CX team) post answers.

{
  "@context": "https://schema.org",
  "@type": "QAPage",
  "mainEntity": {
    "@type": "Question",
    "name": "How do I migrate FAQPage schema from a WordPress site to Astro without losing citations?",
    "text": "I have 40 service pages on WP with FAQPage schema embedded by Yoast. Moving to Astro. Need the migration to not tank the citation lift we got over the last 6 months. What's the safest path?",
    "answerCount": 3,
    "upvoteCount": 12,
    "dateCreated": "2026-05-01T09:14:00Z",
    "author": { "@type": "Person", "name": "Asker Username" },
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Generate the FAQPage JSON-LD at build time from the same markdown frontmatter Yoast was reading. Keep the @id stable across the migration. Validate every URL in Schema Markup Validator before flipping DNS.",
      "upvoteCount": 8,
      "dateCreated": "2026-05-01T11:42:00Z",
      "author": { "@type": "Person", "name": "Responder Username" }
    },
    "suggestedAnswer": [
      {
        "@type": "Answer",
        "text": "I'd also recommend running a 301 map and re-submitting the sitemap to Bing/IndexNow on cutover day.",
        "upvoteCount": 3,
        "author": { "@type": "Person", "name": "Other Responder" }
      }
    ]
  }
}

That’s a QAPage. Single Question wrapped in mainEntity. AnswerCount, upvoteCount, dateCreated, multiple Answer objects — the works.

If your blog post is not a forum thread, this is not your schema. Don’t use QAPage for editorial Q&A no matter how tempting “QA” sounds in the type name.

The third option — Article with FAQ section

Here’s the pattern most blog posts should actually use. The page is an article. Article is the wrapper schema. The FAQ at the bottom is supplementary content — useful, citation-worthy, but not the primary entity of the page.

In that case, FAQPage at the page level is wrong (the page isn’t a curated FAQ — it’s an article that happens to end with one). QAPage is wrong (the page isn’t a community thread). The clean answer is to keep Article as the page-level type and embed Question objects inside the Article’s hasPart or as a separate @graph node.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://answerly.agency/blog/faqpage-vs-qapage-schema#article",
      "headline": "FAQPage vs QAPage: which schema AI citers actually trust",
      "datePublished": "2026-05-08",
      "dateModified": "2026-05-08",
      "author": { "@type": "Person", "name": "Dmytro Popryadukhin" },
      "publisher": {
        "@type": "Organization",
        "name": "Answerly Agency",
        "url": "https://answerly.agency"
      },
      "mainEntityOfPage": {
        "@type": "WebPage",
        "@id": "https://answerly.agency/blog/faqpage-vs-qapage-schema"
      }
    },
    {
      "@type": "FAQPage",
      "@id": "https://answerly.agency/blog/faqpage-vs-qapage-schema#faq",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "Can a single page emit both Article and FAQPage schema?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Yes — use a @graph with two top-level nodes and distinct @id values. The Article describes the page; the FAQPage describes the FAQ section."
          }
        }
      ]
    }
  ]
}

Two nodes, both top-level, distinct @id values, one wrapper object. The Article schema makes the page eligible for Article-style citation; the embedded FAQPage gives the LLM a clean Q&A block to extract from. Best of both — and it’s what we ship on every blog post in this collection.

How each LLM citer parses these patterns

The three big LLM-side citers behave differently. What we measure in our own tracking — and what we hear from teams running their own prompt panels — is consistent enough to be operational guidance.

ChatGPT extracts FAQPage cleanly when it’s the primary entity of a service or product page. On blog posts it slightly prefers the Article-with-embedded-FAQPage @graph pattern — it picks up the article context first, then quotes the Q&A. Single-Q&A QAPage rarely surfaces in ChatGPT citations unless the page is from a recognised forum domain.

Perplexity historically over-cites Q&A patterns — meaning it leans heavily on FAQPage even when an Article wrapper would be more appropriate. That’s fine if you want Perplexity volume; just don’t be surprised when it quotes only the FAQ rows and ignores the rest of the page. Perplexity is also the one citer that occasionally surfaces QAPage-shaped pages from non-forum domains, so the type still has a small operational role even outside Stack Overflow / Reddit.

Gemini prefers structured Article + FAQ section. The @graph pattern with both top-level nodes is what extracts cleanest in our tracking. Gemini tends to read the Article context, validate it against the entity graph, then quote from the FAQ block. A page with FAQPage at the root and no Article wrapper sometimes gets parsed as “this page is a list of FAQs” and the article body is under-weighted.

That’s the simplification — your panel may differ, and the behaviour shifts as models iterate. But the rule of thumb holds: if the page is editorially an article, wrap it as Article and embed the FAQ as a node, not as the root.

Common mistakes we see in audits

FAQPage on a thin page. Three Q&A pairs of 12 words each. The page has no body, no Quick Facts, no author. LLMs read it as low-density content and skip it. Floor is five Q&As of meaningful depth, and the page itself needs to be more than the FAQ.

Wrong @id or no @id at all. Every JSON-LD node should have a stable @id. Without one, LLMs (and Google) can’t tell whether two schema blocks describe the same entity or two different entities, and the de-duplication logic gets unpredictable.

mainEntity vs about confusion. mainEntity is “the page is principally about this thing — and this thing is the page’s content.” about is “the page mentions this thing.” On FAQPage, mainEntity is the array of Questions — not about. On Article, mainEntity is usually the article itself; the FAQ block lives under a separate node, not under Article’s mainEntity.

AnswerCount on FAQPage. This is the giveaway. AnswerCount belongs on QAPage’s Question (because a QAPage Question genuinely has multiple answers — accepted plus suggested). On FAQPage there’s exactly one acceptedAnswer per Question; AnswerCount is meaningless. If you see it in your output, your schema generator is wrong.

Multiple acceptedAnswer on one Question. Same problem from the other direction. Each Question gets exactly one acceptedAnswer. If you have multiple “accepted” answers, you need QAPage with suggestedAnswer for the others.

Hidden FAQ content. The Q&A in your JSON-LD must match what’s visible on the page. Schema-only FAQs that don’t appear in the rendered HTML are a Google guideline violation and an LLM trust signal you don’t want to throw away.

Validation — schema, rich result, and the LLM check

Three gates before deploy.

Schema Markup Validator (validator.schema.org). This is the structural check — does the JSON-LD parse, do the types resolve, do the required fields exist. Run on every page before merge.

Google Rich Results Test. Less useful than it used to be (FAQ rich result is mostly retired) but still flags malformed types and surfaces what Google’s parser actually sees. Treat warnings as deployment blockers.

The LLM check. Paste your URL into ChatGPT and ask it to summarise the FAQs on the page. Then ask Perplexity. Then Gemini. If any of them can’t extract the Q&A pairs cleanly — wrong wrapper, missing context, ambiguous entity graph — you have a real-world problem the validators didn’t catch. This is the test that matters most for the citation goal, and it’s the one teams skip.

The 2026 take

FAQPage became the default “I added schema” move sometime around 2018. In 2026 it’s also the default “I added schema wrong” move. The format you need depends on what the page actually IS — service page with stable curated Q&A, community thread with one question and many answers, or article that happens to end with a FAQ. Three different shapes, three different schemas.

Pick the one that matches the page. Validate. Test it against the three big LLM citers. Then ship.

If you want this done across your whole site at once: the Growth engagement deploys schema correctly on every priority page, with the @graph pattern wired into your CMS so editors can’t break it.