Element Code: RI-027
What QAPage Schema Actually Is
QAPage is a schema.org type built for one specific page shape: a single question, followed by one or more answers, where users can submit their own answers and usually vote on which one is best. Think Stack Overflow, Quora, a forum thread, or a "community answers" section on a support site. The QAPage object wraps a single Question entity in its mainEntity property, and that Question holds an acceptedAnswer (the one marked correct or best) and optionally a list of suggestedAnswer entries for the rest of the responses.
This is not the same job as FAQPage. FAQPage is for a curated list of questions written by the site, like a support page with ten common questions stacked on top of each other. QAPage is for user-generated, single-topic threads where the page's whole reason for existing is that one question. If your page has five different questions on it, QAPage markup is invalid no matter how you nest the JSON-LD, because Google's spec requires exactly one Question as mainEntity.
An SEO audit tool like this one flags QAPage as an issue when it detects a Q&A style page, forum thread, or "ask the community" template with no matching schema, or when it finds QAPage markup that's malformed, incomplete, or applied to a page that clearly isn't a single-question Q&A. A common giveaway is QAPage schema stamped on every page of a ten-question FAQ, a mismatch that fails validation or just gets ignored.
The Correct Markup Structure
Here's a minimal, valid QAPage object in JSON-LD:
{
"@context": "https://schema.org",
"@type": "QAPage",
"mainEntity": {
"@type": "Question",
"name": "Why does my dryer trip the breaker but not other outlets?",
"text": "Full question text as posted by the user...",
"answerCount": 3,
"upvoteCount": 26,
"dateCreated": "2026-03-11T08:02:00-05:00",
"author": { "@type": "Person", "name": "user123" },
"acceptedAnswer": {
"@type": "Answer",
"text": "Full accepted answer text...",
"dateCreated": "2026-03-11T09:44:00-05:00",
"upvoteCount": 41,
"url": "https://example.com/thread/123#answer-4587",
"author": { "@type": "Person", "name": "electrician_dave" }
},
"suggestedAnswer": [
{
"@type": "Answer",
"text": "Full alternate answer text...",
"dateCreated": "2026-03-11T10:12:00-05:00",
"upvoteCount": 9,
"url": "https://example.com/thread/123#answer-4590",
"author": { "@type": "Person", "name": "diy_fan" }
}
]
}
}The properties that gate eligibility: mainEntity must be a single Question, that Question needs a name (the literal question text), an answerCount, and at least one of acceptedAnswer or suggestedAnswer. Each Answer needs a text property at minimum. Everything else, author, upvoteCount, dateCreated, url on the answer, is recommended, not required, but skipping them weakens the result. Google specifically calls out a url per answer as good practice so users land right on it.
The Property Tree
Why It Matters
When QAPage validates, eligible pages can pick up a Q&A rich result in search, showing the question and a snippet of the top answer directly on the results page, sometimes with an accordion for additional answers. That's real screen real estate above your organic snippet, and on forum or support content it tends to lift click-through because searchers see their exact question answered before they click.
Worth being straight about the current state: Google significantly tightened FAQPage and HowTo rich result eligibility in August 2023, cutting FAQ rich results down mostly to government and health sites and pulling most HowTo results from mobile search entirely (source: Google Search Central Blog, "Changes to HowTo and FAQ rich results," August 2023). That announcement did not include QAPage, and QAPage eligibility criteria are unchanged as of this writing. If you find blog posts claiming QAPage got killed off alongside FAQ, that's someone conflating three schema types that happen to rhyme.
None of that makes QAPage a free win. Google is picky about who actually gets the visual result even when the markup is perfect, and Q&A rich results have always leaned toward established Q&A platforms over a random blog bolting the markup onto a comments section. Treat the schema as a prerequisite for eligibility, not a guarantee.
How To Detect It
Four tools cover this well:
- Google Rich Results Test (search.google.com/test/rich-results): paste the URL or raw HTML and it tells you flat out whether the page is eligible for the Q&A rich result, flags missing required fields, and shows a preview of what the result would look like.
- Schema Markup Validator (validator.schema.org): checks the JSON-LD or microdata against the schema.org vocabulary itself, independent of Google's eligibility rules. Useful for catching syntax errors and wrong nesting that the Rich Results Test might just quietly ignore.
- Screaming Frog structured data extraction: crawl the site with structured data extraction enabled (Configuration > Spider > Extraction > Structured Data), export validation errors and warnings in bulk across every URL, and cross-reference against page templates so you know exactly which template is broken rather than checking pages one at a time.
- Search Console Enhancements report: once Google has crawled and processed the markup, the Q&A enhancement report shows valid, invalid, and eligible-with-warnings counts over time, which is the only way to see if what you shipped is actually holding up in Google's index versus just passing the test tool that one time.
How To Fix It, Step By Step
- Confirm the page actually qualifies. One question, one canonical URL, users can submit answers. If it doesn't meet that bar, stop, don't force QAPage onto it. Use FAQPage for curated multi-question content instead.
- Identify the accepted answer if your platform has a "best answer" or "verified answer" concept. Map that to acceptedAnswer. Map every other visible answer to a suggestedAnswer array item.
- Pull real data into the properties: exact question text into name, full question body into text, a live count into answerCount, actual vote totals into upvoteCount if you track them. Don't hardcode placeholder numbers, Google's validator won't catch a fake answerCount but it's a fast way to erode trust if anyone audits it later.
- Add a url property per answer pointing at the in-page anchor for that specific answer, so users land exactly where the content lives instead of the top of a long thread.
- Output the markup as JSON-LD in the page head or body, not microdata sprinkled through the visible HTML. JSON-LD is easier to maintain and easier to audit at scale.
- Validate with the Rich Results Test before it ships, then re-check Search Console's Q&A enhancement report a week or two after deploy to confirm Google parsed it the way you intended.
- If the template serves both single-question threads and multi-question list pages, branch the schema output by template type. Don't ship one schema partial and assume it fits every page variant.
What Good Looks Like
A clean implementation has exactly one Question per QAPage, real question text pulled from the actual page content, an accurate answerCount that updates as new answers come in, and per-answer URLs that anchor straight to each answer. Search Console shows zero errors and ideally zero warnings on the Q&A enhancement report, and spot-checking URLs in the Rich Results Test comes back eligible, not just valid.
QAPage vs FAQPage vs HowTo
| Property | QAPage | FAQPage | HowTo |
|---|---|---|---|
| Questions per page | Exactly one | Multiple | N/A, steps not questions |
| Answer source | User-submitted, votable | Site-authored | Site-authored |
| Typical page type | Forum thread, Q&A platform | Support/help page | Tutorial, instructions |
| Rich result eligibility, mid-2026 | Unchanged, still eligible | Restricted since Aug 2023 to mostly gov/health sites | Mostly removed from mobile since Aug 2023 |
| Required root property | mainEntity (single Question) | mainEntity (array of Question) | step (array of HowToStep) |
- Use QAPage only on true single-question, user-answerable pages
- Include a real, current answerCount
- Mark the actual accepted/best answer as acceptedAnswer
- Add a url per answer for in-page anchoring
- Re-validate after any template change
- Stamp QAPage on a page with five unrelated questions
- Reuse FAQPage content and just rename the type to QAPage
- Hardcode a fake answerCount or upvoteCount
- Leave out acceptedAnswer and suggestedAnswer both
- Assume valid markup guarantees the rich result will show
Common Mistakes
The number one mistake is confusing QAPage with FAQPage, usually because a template was built for one and later reused for the other without anyone checking the spec. The second is missing required properties, most often answerCount or a properly typed acceptedAnswer, because someone hand-wrote the JSON-LD once and never revisited it as the page changed. The third is applying QAPage to pages with multiple unrelated questions, like a support FAQ dressed up with Q&A styling. That's an FAQPage candidate, not QAPage, full stop.
FAQ
Can I use QAPage and FAQPage on the same site?
Does QAPage require users to actually be able to submit answers?
Was QAPage affected by the 2023 FAQ and HowTo rich result changes?
Is JSON-LD required or can I use microdata?
Why does my valid QAPage markup still not show a rich result?
Our Advanced SEO Audit reviews every schema type across your site, checks eligibility against current Google requirements, and hands you a prioritized fix list instead of a wall of validator errors.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
