FAQPage Schema Markup: Implementation Guide for 2026

FAQPage schema still works. The rich result mostly doesn’t.

In August 2023, Google restricted FAQ rich results to well-known government and health websites. If your site doesn’t fall into those categories, your FAQPage markup won’t generate the accordion dropdown in search results. That’s the reality most guides bury three paragraphs in.

“No rich result” doesn’t mean “no value.” FAQPage schema markup still declares explicit question-and-answer entities in machine-readable code. AI Overviews and answer engines parse that structure. Google still reads it for entity understanding. And if you do qualify, the implementation needs to be correct.

This guide covers Google’s current eligibility rules, production-ready JSON-LD, how to handle FAQPage alongside other schema types on the same page, validation specific to this type, and the mistakes that silently break it. FAQPage is one of roughly 30 types Google supports for rich results – our schema markup guide covers the full system. This article covers the one type.

What Is FAQPage Schema and Who Can Still Get Rich Results?

FAQPage is a Schema.org type – a subtype of WebPage – that describes a page containing a list of frequently asked questions and their answers. Google’s documentation says you can use FAQPage structured data when your page “has a list of questions and answers about a particular topic.” That includes dedicated FAQ pages and pages with FAQ sections – like a product page with a Q&A block or an article with an FAQ at the bottom. The markup describes the FAQ content on the page, not the page’s sole purpose.

The distinction between FAQPage and QAPage trips people up constantly. FAQPage is for questions the site owner writes and answers editorially. You control both sides. QAPage is for community-driven Q&A – a user posts a question, multiple people submit answers. Think Stack Overflow. The property difference is concrete: FAQPage uses acceptedAnswer (one definitive answer per question). QAPage supports suggestedAnswer for multiple community-submitted answers, and can also include an acceptedAnswer if one answer has been selected as best. Use the wrong type and your markup either fails validation or describes something your page isn’t.

Who Still Gets FAQ Rich Results?

In August 2023, Google restricted FAQ rich results to well-known, authoritative government and health websites. Before that update, any site with valid FAQPage markup could earn the accordion dropdown beneath its search result. That’s over.

If your site isn’t a recognized government or health authority, Google won’t display the FAQ rich result – regardless of how clean your markup is. The structured data still validates. Google still reads it. But the visual SERP feature won’t appear for most sites.

Why Implement FAQPage Markup Without the Rich Result?

Three reasons.

First, your site might qualify. If you operate a government portal, a public health organization, or an authoritative medical resource, FAQ rich results are still available. Implement and validate.

Second, FAQPage markup declares explicit entities. Each Question and Answer in your JSON-LD is a machine-readable entity declaration. Google uses this to understand what your page covers – which topics, which specific questions your content answers. That understanding feeds how Google indexes your page regardless of whether a rich result appears.

Third, the Q&A format is inherently easy for machines to parse. Answer engines and AI Overviews retrieve content from pages they can process with confidence. A question-answer pair declared in structured data is unambiguous in a way that the same pair buried in a paragraph is not.

Google’s FAQPage structured data documentation is the canonical reference for required properties and current guidelines. Everything in this guide aligns with that documentation.

The eligibility rules determine whether you get a SERP feature. The code determines whether your markup is valid in the first place. Here’s what correct FAQPage JSON-LD looks like.

What Does Correct FAQPage JSON-LD Look Like?

Here’s a production-ready FAQPage block with three questions. You can copy this, replace the content, and test it in the Rich Results Test immediately.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is FAQPage schema markup?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "FAQPage schema is structured data in JSON-LD format that describes a page containing frequently asked questions and their answers. It uses the Schema.org FAQPage type."
      }
    },
    {
      "@type": "Question",
      "name": "Does FAQ schema still generate rich results?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Since August 2023, Google restricts FAQ rich results to well-known government and health websites. Other sites can still implement valid FAQPage markup, but the accordion dropdown will not appear in search results."
      }
    },
    {
      "@type": "Question",
      "name": "How do you validate FAQPage structured data?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Use <a href=\"https://search.google.com/test/rich-results\">Google's Rich Results Test</a> to check whether your markup qualifies for FAQ features. Use the <a href=\"https://validator.schema.org/\">Schema Markup Validator</a> to check syntax against the full Schema.org specification."
      }
    }
  ]
}
</script>

Place that in your <head> or <body>. Both work. Google parses JSON-LD from either location.

Property-by-Property Breakdown

The structure is flat. No deep nesting. No optional layers to worry about.

@type: "FAQPage" declares the page type. This sits at the top level. You don’t nest it inside anything else at this stage. (Multi-schema pages are a separate problem. We’ll cover that next.)

mainEntity is an array of Question objects. Each question your page answers gets one entry. There’s no documented limit on how many questions you can include, but every question in the array must have a visible, matching question on the page itself. Don’t add questions to your JSON-LD that the user can’t see.

name on the Question object is the question text. Write it exactly as it appears on the page. Not a paraphrase. Not a shortened version. The exact string.

acceptedAnswer contains a single Answer object. One answer per question. This is what distinguishes FAQPage from QAPage – you provide the definitive answer, not a collection of suggestions.

text inside the Answer holds the answer content. This is a string, not a nested object. It accepts plain text or limited HTML. Google’s FAQPage documentation specifies the allowed HTML tags: <a>, <b>, <br>, <h2> through <h6>, <li>, <ol>, <p>, and <ul>. Google strips anything else. If you include <div>, <span>, <img>, or custom elements – gone. The third question in the example above uses <a> tags. That’s valid. An <iframe> would not be.

What About Required vs. Recommended Properties?

FAQPage is unusually clean. Every property listed above is required for rich result eligibility. There are no “recommended” properties that add optional detail – unlike Product schema, which has a long list of recommended fields. If your FAQPage JSON-LD includes @type, mainEntity, name, acceptedAnswer, and text, you’ve met every requirement Google specifies.

That simplicity is the good news. The bad news is there’s nothing optional to add that improves how the rich result displays. What you see above is the ceiling.

Using a CMS Plugin Instead of Hand-Coding

If you’re on WordPress, you don’t need to write JSON-LD by hand. Rank Math includes a dedicated FAQ block in the Gutenberg editor. Add the block, type your questions and answers, and Rank Math generates the FAQPage JSON-LD automatically – with the correct mainEntity array, Question types, and acceptedAnswer nesting. It also handles the visible HTML output, so your schema and your on-page content stay in sync by default. That eliminates the schema drift problem we cover in the mistakes section.

One thing to verify: after publishing, run the page through the Rich Results Test to confirm the plugin’s output matches what Google expects. Rank Math generates clean FAQPage markup, but theme conflicts or caching plugins can occasionally interfere with the JSON-LD output. Trust the validator, not the plugin’s preview.

For the full JSON-LD syntax including nesting rules and @id patterns, see our JSON-LD tutorial.

A standalone FAQPage block is straightforward. In practice, your FAQ section shares the page with Article schema, Organization schema, and BreadcrumbList. That’s where implementation gets interesting.

How Do You Implement FAQPage on Multi-Schema Pages?

In practice, FAQPage rarely lives alone. A blog post with an FAQ section carries Article schema, FAQPage schema, BreadcrumbList, and probably an Organization entity for the publisher. That’s four types on one page. You have two ways to handle it.

Using @graph to Combine Multiple Types

The first approach: a single <script type="application/ld+json"> block with a @graph array. Every entity on the page lives as a node in one JSON-LD object.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://example.com/page/#article",
      "headline": "How to Optimize Your FAQ Section",
      "author": {
        "@type": "Person",
        "name": "Jaan Koppel",
        "url": "https://squin.org/about/"
      },
      "datePublished": "2026-03-01T08:00:00+00:00",
      "dateModified": "2026-03-01T08:00:00+00:00",
      "publisher": {
        "@id": "https://example.com/#organization"
      }
    },
    {
      "@type": "FAQPage",
      "@id": "https://example.com/page/#faq",
      "isPartOf": {
        "@id": "https://example.com/page/#article"
      },
      "mainEntity": [
        {
          "@type": "Question",
          "name": "What does this product cost?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Pricing starts at $49 per month for the base plan."
          }
        },
        {
          "@type": "Question",
          "name": "Do you offer a free trial?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Yes. All plans include a 14-day free trial with no credit card required."
          }
        }
      ]
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Corp",
      "url": "https://example.com",
      "logo": {
        "@type": "ImageObject",
        "url": "https://example.com/logo.png"
      }
    }
  ]
}

Three entities. One script block. Each node has an @id that other nodes can reference. The Article’s publisher points to the Organization’s @id. The FAQPage’s isPartOf points to the Article’s @id – telling Google the FAQ belongs to this specific article, not the site in general. Everything connects.

The second approach: separate <script type="application/ld+json"> blocks, one per type. Google parses each block independently. This is simpler when your types don’t reference each other – BreadcrumbList, for example, rarely needs to point to your Article entity.

Both approaches are valid. Google processes them the same way. Use @graph when entities reference each other. Use separate blocks when they don’t.

How @id and isPartOf Connect Your Schema

The @graph example above uses two mechanisms to connect entities. @id assigns each node a unique identifier – a URI fragment like "https://example.com/page/#article". isPartOf on the FAQPage node references the Article’s @id, declaring that the FAQ section belongs to that article.

This level of precision is not required for rich result eligibility. Google parses FAQPage and Article as independent types and evaluates each on its own. But for entity resolution – helping Google understand that the FAQ covers the same topic as the article – explicit @id connections remove ambiguity that implicit page context doesn’t. The cost is a few extra lines of JSON.

Your markup is written. The next step is confirming it actually works before it goes live.

How Do You Validate FAQPage Markup?

Two stages. Testing before you publish catches syntax errors and missing properties. Monitoring after you publish catches everything else – broken markup from template changes, schema that validates but never generates a rich result, and drift between your JSON-LD and your visible content.

Testing Before You Publish

Start with Google’s Rich Results Test. Paste your URL or your raw JSON-LD code snippet. For FAQPage, the tool reports “FAQ” as the detected rich result type and lists each Question it found.

Here’s what FAQPage-specific errors look like in the Rich Results Test:

“Missing field acceptedAnswer” – You either forgot the Answer object inside your Question, or you used suggestedAnswer instead of acceptedAnswer. This is the FAQPage/QAPage confusion showing up as a validation error. Fix: replace suggestedAnswer with acceptedAnswer and make sure it contains an Answer object with a text property.

“Missing field text” – The Answer object exists but has no content. You declared "@type": "Answer" and then left it empty or used the wrong property name. The property is text, not content, not value, not description.

“Invalid value type for field mainEntity” – Your mainEntity contains something other than Question objects. This usually happens when you wrap the array in an extra object layer or pass a single Question without the array brackets.

If the test detects valid FAQ markup but shows a note about restricted eligibility, that’s the August 2023 policy. Your code is correct. Google just won’t display the rich result for your site. This is not an error. Don’t change your markup to try to fix it.

After the Rich Results Test, run your JSON-LD through the Schema Markup Validator. This tool checks syntax against the full Schema.org specification – not just the subset Google supports. It catches property-type mismatches the Rich Results Test sometimes ignores, like putting a number where a string is expected or using a property that doesn’t exist on the FAQPage type.

Use both tools. The Rich Results Test tells you whether Google can use your markup. The Schema Markup Validator tells you whether your markup is structurally correct against the vocabulary itself.

Monitoring After Deployment

Pre-publish testing tells you the markup is valid right now. Google Search Console tells you whether it stays valid after Googlebot crawls it.

Once Google processes your FAQPage markup, a “FAQ” report appears under the Enhancements section in GSC. It shows three categories: valid pages, pages with errors, and pages “valid with warnings.” For FAQPage specifically, “valid with warnings” is rare. The type has almost no optional properties – you either have the required fields or you don’t. If you see warnings, check whether a CMS plugin is injecting non-standard properties that Google doesn’t recognize.

The more useful signal is in the Performance report. Filter by search appearance and look for “FAQ rich results.” If you see zero impressions despite valid markup across multiple pages, your site doesn’t meet the August 2023 eligibility criteria. That’s expected. It confirms the markup is technically correct but your site isn’t in the qualifying category. Don’t remove the markup – the entity signals still apply.

For the complete GSC monitoring workflow across all schema types, see our guide to validating structured data in Google Search Console.

Valid markup that describes the wrong content is worse than no markup at all. The next section covers the mistakes that break FAQPage implementations – some silently, some with manual actions.

What Are the Most Common FAQPage Schema Mistakes?

Five mistakes. All avoidable. Each one either breaks your markup silently or puts you on a path toward a manual action.

1. Hidden FAQ content. Your JSON-LD declares questions and answers that don’t appear anywhere in the visible page. Maybe you added extra Q&A pairs to the schema hoping to capture more queries. Maybe the FAQ section got removed in a redesign but nobody updated the JSON-LD. Google’s structured data spam policies treat this as a misrepresentation of page content – and it can trigger a manual action that removes your eligibility for all rich results, not just FAQ. Every question in your mainEntity array needs a matching, visible question on the page.

2. Confusing FAQPage with QAPage. You used suggestedAnswer instead of acceptedAnswer. Your markup validates – suggestedAnswer is a real Schema.org property – but it’s the wrong property for the wrong type. FAQPage uses acceptedAnswer because you, the site owner, provide the definitive answer. suggestedAnswer is for QAPage, where multiple community members offer competing answers. The Rich Results Test flags this as a missing acceptedAnswer error because Google expects that property on FAQPage and ignores suggestedAnswer entirely in this context.

3. Using FAQPage on pages that aren’t FAQs. A product page with “Why is our product better than the competition?” and “What makes us different?” is not FAQ content. It’s marketing copy formatted as questions. Google’s FAQPage documentation states the content must be questions and answers. Promotional self-Q&A doesn’t qualify. The type describes informational FAQ content where users genuinely have those questions – not sales objections reframed with question marks.

4. Schema drift on dynamic FAQ sections. Your CMS manages the FAQ accordion. An editor adds two questions on Monday and removes one on Thursday. But the JSON-LD is hardcoded in the template – it still shows last week’s version. The visible content and the markup now describe different things. Schema drift is a systemic problem across all schema types, and it hits FAQPage constantly because FAQ sections change more often than most structured content. The solution is architectural: generate the JSON-LD from the same data source that populates the visible FAQ. If your CMS drives the accordion, your CMS should drive the schema. This is one reason plugin-based approaches like Rank Math’s FAQ block help – the visible content and the markup come from the same input, so they can’t diverge.

5. JavaScript-rendered FAQ with no server-side schema. Your FAQ accordion loads via a JavaScript component. The questions and answers only exist in the DOM after client-side rendering. Your JSON-LD references those questions, but if Googlebot crawls the page before JavaScript executes – or if the rendering queue delays execution – the schema describes content that doesn’t exist in the initial HTML. Google can render JavaScript, but it does so through a two-wave process with a delay between crawl and render. Inject the JSON-LD <script> block server-side so it’s present in the raw HTML response. If your FAQ component is client-rendered, at minimum ensure the structured data itself is not.

If you’re running FAQPage across multiple templates, a site-wide audit catches drift faster than checking pages one at a time – see our schema markup audit checklist (coming soon).

These mistakes break implementation. The next question is whether getting implementation right still matters – specifically for AI search, where the rules are different from traditional rich results.

Does FAQPage Schema Still Matter for AI Search?

Some guides claim FAQ schema has “the highest AI citation rate” or directly improves your chances of appearing in AI Overviews. Those claims don’t have sources. Google has not published documentation stating that FAQPage markup influences AI Overview source selection or citation. Any specific percentage you see is correlation, not causation.

What makes FAQPage relevant to AI systems is the format itself. A retrieval-augmented generation system that pulls content from your page gets a cleaner signal from an explicit question-answer pair in JSON-LD than from the same information scattered across paragraphs. The question is declared. The answer is declared. No extraction or inference required. That applies to Google’s AI Overviews, Bing’s Copilot, Perplexity, and any other system that retrieves web content to ground its responses.

The practical takeaway: don’t implement FAQPage schema as an AI search strategy. Implement it because your page contains real FAQ content and the markup accurately describes that content. If an AI system cites your page because your Q&A structure was unambiguous, that’s a side effect of correct implementation – not a separate tactic.

For the current list of schema types Google supports for rich results, check the Google Search Gallery. We cover the full relationship between structured data and generative search in AI Overviews and structured data (coming soon).

Frequently Asked Questions

Where This Fits

FAQPage is one schema type within a broader structured data strategy. For the full implementation framework – which types to prioritize, how to validate at scale, and where structured data fits in AI search – start with the schema markup guide. Next implementation step: our JSON-LD tutorial covers the syntax fundamentals every schema type depends on.