FAQ schema markup guide

What FAQPage describes and what it does not

FAQPage is a Schema.org type for a WebPage that presents one or more frequently asked questions. A question is represented as a Question entity, with its name and an acceptedAnswer; an answer can be represented as an Answer with text. In plain terms, the page tells software, “these are the questions this page answers, and this is the answer shown to readers.” The type describes content; it does not certify that the answer is correct, establish the publisher’s expertise, or promise a search appearance.

See the Schema.org FAQPage and Question definitions for the vocabulary itself.

The critical editorial rule is that markup must describe what a reader can actually see. If a page contains four visible questions and answers, the structured representation should express those same questions and answers, not a longer hidden version written only for crawlers. Do not mark up answers that contradict the article, append claims that the visible FAQ omits, or add fictional questions because a template expects a certain count.

Google’s general structured data policies explicitly require relevant, representative markup and prohibit marking up hidden content. A faithful FAQ can still be valuable as an accessible way to organize clarifications even when no search feature is attached to it.

Google FAQ rich results are retired; set expectations accordingly

The current status matters before anyone spends time implementing a schema type for a hoped for search display. Google’s Search Central change log records that the FAQ rich result feature stopped appearing in Google Search starting May 7, 2026; Google later removed the FAQ rich result documentation because the feature was no longer shown. That is different from saying the Schema.org type has ceased to exist. Schema.org still defines FAQPage, but a valid vocabulary type and a Google search feature are not the same thing.

Check the dated entry in Google’s official update log rather than relying on older tutorials or screenshots that still describe FAQ dropdowns in results.

Do not sell, forecast, or report FAQPage as a way to raise rankings, earn a special snippet, or secure a citation. Google’s broader policies state that correct structured data does not guarantee a rich result, and the FAQ display itself has been retired. For Google AI Overviews and AI Mode, Google says there are no special schema requirements; the usual search eligibility and helpful content fundamentals apply, and meeting requirements does not guarantee crawling, indexing, or inclusion.

That makes FAQ markup, at most, a precise description of page structure not a shortcut into an AI answer. Read Google’s AI feature guidance alongside its structured data policies when advising a client.

Choose FAQPage, QAPage, or no question markup

Choose the type from the way the page works for readers, not from the fact that it contains question marks. FAQPage fits a page that publishes a curated set of questions with answers supplied by the site or editorial owner. A user forum where people submit answers and discuss a question has a different information model. Schema.org describes QAPage as a page focused on a specific question and its answer or answers; its Question vocabulary can express accepted and suggested answers.

A page that simply includes a useful explanatory paragraph may need no FAQ specific markup at all. Consult the Schema.org QAPage definition rather than treating FAQPage and QAPage as interchangeable labels.

This choice is a content model decision, not a way to unlock a deprecated rich result. For a clinic, an editor written page explaining appointment preparation might have a concise FAQPage section if it visibly answers common patient questions. A support community where people ask a particular question and multiple members reply is not the same editorial pattern. If no question set adds useful context, omit FAQ markup and focus on the page’s primary type.

The broader structured data for AEO guide explains how page type markup should support not replace the visible information architecture.

Build an FAQ around real reader needs

Write the questions before writing the JSON LD. Useful inputs include customer support tickets, sales calls, search queries, onsite search, product documentation, and recurring points of confusion in the main article. Group near duplicates and choose only the questions that resolve a meaningful uncertainty for this page. A guide about schema implementation might clarify whether the markup must match the page, how a validator differs from a search feature test, or what to do with an existing FAQ block. It should not repeat generic “What is our company?”

questions simply because they can be copied across every URL.

Answer each selected question directly, then state the condition or exception that keeps the answer accurate. For example, “Does JSON LD have to be used?” should distinguish a preferred workflow from a platform requirement: Google supports JSON LD, Microdata, and RDFa and generally recommends JSON LD where a site’s setup allows it. A short answer can say that plainly, then note that teams should use the format they can maintain correctly.

Link to the JSON LD templates for AEO for implementation patterns, but do not imply that a particular format produces a ranking advantage. Google’s introduction to structured data documents supported formats and its recommendation.

Treat the FAQ as part of the article, not a detached keyword appendix. Place it where it helps readers, use descriptive question headings, and keep each answer self contained enough to make sense when scanned. Do not hide it in collapsed content inaccessible to users or use it to smuggle promotional claims onto a page. Before publication, assign an owner for claims that can change such as platform policies and record the source and review date.

When an official feature changes, update both the prose and any code example rather than letting old markup guidance linger.

Implement JSON LD only after the visible FAQ is final

JSON LD keeps the structured description separate from the HTML text, which can make it convenient to maintain. Google supports it and generally recommends it when a site can implement it reliably; the choice is still about maintainability, not a special ranking benefit. In a production page, place the JSON LD in an application/ld+json script element and include one Question object per visible FAQ. The small example below mirrors the first two question and answer pairs in this guide’s visible FAQs.

If you reuse it elsewhere, replace both the questions and answers with the exact visible copy on that destination page; do not deploy sample text as if it were a real FAQ.

The sample uses the basic relationship: a FAQPage contains a mainEntity list of Questions; each Question has a name and an acceptedAnswer represented as an Answer with text. It deliberately omits optional decoration. Add properties only when they are accurate, supported by the vocabulary, and useful to describe the page. Be especially careful with a CMS or plugin that generates markup automatically: inspect the rendered page to see whether it duplicates questions, exposes stale answers, or marks up text that is no longer visible.

Google’s structured data introduction explains JSON LD and the other supported formats; Schema.org’s FAQPage and Question pages define the vocabulary.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Does FAQPage schema guarantee a Google rich result?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Google’s Search updates say FAQ rich results stopped appearing on May 7, 2026; valid structured data is not a guarantee of appearance under Google’s general policies."
      }
    },
    {
      "@type": "Question",
      "name": "Is FAQPage markup required for Google AI Overviews?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Google’s AI feature guidance says there are no special schema requirements for AI Overviews; pages must meet normal eligibility and inclusion isn’t guaranteed."
      }
    }
  ]
}

Verify both the data and the page people receive

Validation has two separate questions: is the JSON LD syntactically and semantically understandable, and does the deployed page accurately represent it? Start by parsing the script as JSON, then compare every question and answer against the rendered HTML, including punctuation, conditions, and any changes introduced by a publishing template. Check the page on desktop and mobile, confirm that the FAQ is readable without relying on structured data, and inspect a page after a CMS update rather than trusting an editor preview.

A test can find some defects; no tool can judge whether an answer is useful, honest, or sufficiently qualified for the reader.

Google distinguishes its Rich Results Test, which checks for Google rich result features, from the Schema Markup Validator, which checks Schema.org markup without Google specific feature warnings. Since Google retired FAQ rich results, do not interpret the absence of an FAQ rich result preview or FAQ feature status as evidence that the FAQPage vocabulary is invalid.

Use the Schema Markup Validator for generic vocabulary checks, and consult Google’s structured data testing overview for the scope of each tool. For site specific deployment checks, pair that review with URL inspection and a comparison of rendered content. Rankwox’s schema validation guide provides a broader validation workflow.

Decide whether to add, retain, or remove existing markup

For a new page, add FAQPage only when a visible, editor controlled FAQ is part of the page’s purpose and the data can be kept in sync. For an existing page, do not rush into a sitewide removal merely because Google no longer shows FAQ rich results. First determine whether another consumer depends on the structured description, whether it is accurate, whether the visible FAQ is still useful, and whether the maintenance cost is justified.

Keep markup that serves a legitimate descriptive purpose and is correct; revise markup that is stale or out of step with the page; remove it when the FAQ itself has been removed or the page no longer fits the type. Schema.org’s vocabulary can have uses beyond a specific Google feature, but do not assume that any particular external platform consumes it.

The highest value fix is often editorial rather than technical: consolidate duplicate questions, remove an obsolete answer, clarify the exception, or link to a more complete explanation. If an answer has become part of a regulated, financial, medical, or product decision, route the revision to an appropriate subject matter reviewer. Keep a brief change log with URL, old and new wording, source checked, deployment date, and reviewer.

That provides an audit trail when a future platform change prompts a reassessment, without mistaking the presence of JSON LD for proof that users or search systems have benefited.

Measure usefulness without promising search display

Measure the page’s purpose, not a feature Google has retired. Useful checks include whether readers reach the FAQ from the relevant article, whether support teams see fewer repeated misunderstandings, whether the answers resolve the query without a second search, and whether readers continue to the next relevant resource. Use analytics or support records only where collection is appropriate, and define the measure before changing the page.

A before and after comparison can reveal a pattern, but it does not prove that FAQPage markup alone caused it; other content, product, seasonality, or distribution changes may also matter.

For Google search visibility, review ordinary Search Console performance and qualified visits rather than expecting an FAQ rich result report. Google says AI Overview and AI Mode traffic is included in the overall Search Console Performance report under Web search; that reporting does not mean a FAQ schema caused an inclusion. If a team manually samples AI answers, record the exact query, market, date, platform, cited URL, and answer accuracy, then compare like with like and describe the limits.

Google’s AI feature documentation explains eligibility and the reporting scope; it also makes clear that inclusion is not guaranteed. The AEO implementation hub connects structured data with content, internal linking, and measurement, which is a more defensible program than treating a schema type as a standalone KPI.

1. 01Record the current visible FAQ, its intended audience, and the outcome it is meant to support.
2. 02Document any markup change separately from editorial, design, and distribution changes.
3. 03After release, verify the rendered page, JSON LD, and internal links on the live URL.
4. 04Compare the same reader or search measures over an appropriate period and note outside changes.
5. 05Report results as observed associations, not as guaranteed rankings, rich results, or AI citations.