FAQ schema describes a page’s questions and answers in structured data. Google retired FAQ rich results on May 7, 2026. Useful answers can stay on your page regardless of whether you keep their markup. Check accuracy, what generates the code, and whether maintaining it serves a defined purpose before changing anything.
A vanished search feature can leave a maintenance question behind: should you remove the code that supported it? Start with one page. Separate the answers readers use, the markup describing them, and the component that produces that markup. Each can require a different decision.
Our recommendation is to preserve content that serves readers, correct misleading output, and give new schema work a reason to earn its place in the backlog.
What Is FAQ Schema?
FAQ schema usually refers to Schema.org’s FAQPage type: a way to describe a page containing frequently asked questions and their answers. It identifies which text is a question and which answer belongs to it. The vocabulary describes content; a search engine separately decides which features it supports. Schema.org’s FAQPage definition establishes the type.
You will encounter the information in formats such as JSON-LD, which places structured data in a script, or microdata, which attaches attributes to HTML elements. To read a basic FAQ implementation, follow this relationship:
FAQPage → mainEntity → Question → acceptedAnswer → Answer
The question’s name contains the question wording. The answer’s text contains its answer. You do not need to learn every Schema.org property to check whether those two pieces match the page.
FAQPage and QAPage describe different content patterns. Google’s QAPage guidance concerns a page focused on one question where users can submit answers. A business FAQ with several company-written answers does not meet that pattern. Changing the type label to QAPage is not a route around FAQ rich-result retirement. Google’s QAPage requirements explain the distinction.
For the broader choice of which structured data belongs on a page, use our schema markup guide.
What Changed for FAQ Rich Results?
Google’s documentation records that FAQ rich results stopped appearing on May 7, 2026. Its June 15 update removed the related documentation. A working FAQPage implementation therefore has no current Google FAQ rich-result feature to qualify for. The earlier government-and-health-site eligibility advice describes a previous policy. Google’s official update record supplies the effective date.
FAQPage remains in Schema.org. That distinction matters when someone says your schema has become “invalid.” A retired display feature and an invalid description are different problems, with different remedies.
There is no need to delete helpful answers to respond to the feature change. An existing block may still answer a buyer’s question about delivery, eligibility, or a service boundary. Assess that content on its usefulness and accuracy. Assess its markup on accuracy, purpose, and maintenance cost.
Inspect a Public FAQ Example
Follow one visible question into the page’s actual structured data. Record what matches and what remains unknown. Searching for the word FAQPage alone is insufficient: a tutorial can contain that word in a displayed code sample without emitting the corresponding structured data.
We inspected the BrowserBugs public microdata demonstration on October 11, 2026. It is a teaching demo with car-related questions. It supplies no business outcome or J6 implementation evidence. The browser showed the questions and answers; its live HTML also contained the corresponding microdata attributes, separately from the printed code listing.
One visible question asks, “Why does a VW Beetle have no legs?” Its answer identifies the Beetle as a Volkswagen car. Following that pair through the HTML gives this map:
| Part of the Page | Observed Markup | What We Can Check |
|---|---|---|
| Page body | itemtype="https://schema.org/FAQPage" |
The page declares the FAQPage type. |
| First question section | itemprop="mainEntity" with type Question |
This question is connected to the FAQ page. |
| Question heading | itemprop="name" |
The marked question is the visible question. |
| Answer container | itemprop="acceptedAnswer" with type Answer |
The answer is attached to that question. |
| Text inside the answer | itemprop="text" |
The marked answer contains the visible response. |
This is an observed content-to-markup match for the inspected pair. We did not test ranking effects, AI citations, or every property on the page. The public output also does not establish which editor, plugin, or template produced it.
Our initial recommendation: leave the inspected output unchanged while checking its producer and dependencies. No mismatch was found in this pair. Markup producer and downstream use remain unverified; this was a read-only inspection.
On your own site, inspect one pair that matters to the business, especially an answer containing a changing price, restriction, or service promise. Compare the complete meaning, including qualifications. A stale answer in structured data can misdescribe an otherwise updated page.
Then find the source in your CMS, theme, plugin, or custom code. For example, Yoast’s FAQ block creates both visible FAQ content and FAQPage structured data. That coupling makes “delete the FAQ block” a different request from “stop emitting FAQPage.” Confirm the effect of the available setting or code change before using it; the public HTML alone cannot identify the safe control.
Open the mobile-friendly diagram for a larger, vertically arranged version.
Decide What to Keep, Fix, Remove, or Defer
Choose an action from the evidence on the page and the cost of maintaining it. Google’s retirement removes a former feature objective. It does not, by itself, establish that accurate FAQ markup harms the page or that every implementation deserves ongoing investment.
The following is our suggested maintenance framework, rather than a Google requirement.
| What You Find | Check Before Acting | Recommended Action and Reason |
|---|---|---|
| Accurate output maintained automatically with the visible answers | Confirm it stays synchronized and creates no known conflict | Keep for now. Removal has no demonstrated priority solely because the rich result ended. Review if the producer or content changes. |
| The visible answer is current, but markup contains an older claim | Find the emitting component and whether another component also outputs an answer | Fix the source. If accurate output cannot be maintained, consider removing that FAQ output while preserving the visible answer. |
| Two components produce conflicting answers | Identify the intended owner and inspect their other schema responsibilities | Resolve ownership. Keep one maintained source for that answer; do not disable a whole SEO plugin to remove one conflicting output. |
| Maintaining a separate FAQ data source takes work and no current consumer or purpose has been identified | Check integrations and dependencies with their owners; confirm output can be isolated | Consider removal. Retire the unnecessary FAQ output with a backup and regression checks. Keep valuable visible content and unrelated structured data. |
| Someone proposes new FAQ markup solely to obtain Google’s former FAQ display | Confirm whether there is a different, documented use | Defer the build. The stated Google feature objective is unavailable. Spend the effort on answers customers need or a better-supported priority. |
“Unknown” needs an investigation owner. It cannot silently become “unused.” A site may have an internal integration that reads structured data; establish that dependency before changing its output.
For an article page, take particular care around a shared schema graph. Its FAQ information may sit alongside article, author, organization, or breadcrumb information. A request to remove one type should preserve the appropriate relationships elsewhere. Our Article and Blog Schema guide explains the article-specific fields that still need to reflect the post.
Check the Answer, the Markup, and the Remaining Page
Verification should show that the intended change happened and the protected content survived. Check visible content, emitted structured data, and the remaining page separately. A successful parser result answers only part of that question.
- 1Read the visible answer. Confirm it is accurate, complete, and usable on desktop and mobile. Open any accordion. If you removed only markup, confirm the question and answer still appear.
- 2Inspect the emitted data. Fetch or inspect the updated page, including rendered output where scripts generate it. Confirm the intended answer changed or the targeted output disappeared. Check for another plugin or template still producing the old answer.
- 3Check what should remain. Verify the page layout, links, and other appropriate structured data. Retain a before-and-after copy so an unintended change can be traced and reversed.
Use tools for the question each can answer:
| Check | Useful For | Limit |
|---|---|---|
| Schema.org Validator | Checking structured-data syntax and its use of the vocabulary | It cannot establish whether the answer is true, useful, or commercially valuable. |
| Google’s Rich Results Test | Inspecting supported Google rich-result types on the page | An absent FAQ feature is not evidence that the Schema.org FAQPage type has ceased to exist. |
| Page and source comparison | Checking that visible answers and emitted descriptions correspond | A correct match does not measure ranking or citation impact. |
The Schema.org Validator documentation describes its extraction and syntax checks. We inspected the demo’s HTML without running a validator; use the checks above for your own implementation.
If the investigation reveals a wider template or indexing problem, expand it into an SEO audit with its own scope. Keep this maintenance task focused while its evidence remains page-specific.
Does FAQ Schema Help AI Visibility?
Google says its generative AI search features do not require special Schema.org markup. That rules out treating FAQ schema as a required ticket into those features. It does not establish that every AI system handles structured data identically. Google’s AI optimization guidance is the relevant primary source.
A clear explanation of who a service suits or how a process works helps a reader evaluate it. That content decision stands without a promise of AI citation gains from an added schema type.
If someone recommends FAQ markup for AI visibility, ask them to name the system, the proposed mechanism, and the evidence behind the claim. Separate an observed citation from a causal claim about markup. A single before-and-after comparison that changes text and schema together cannot isolate which change mattered.
For a business owner, the immediate decision is practical: maintain accurate low-effort output where appropriate, and require a defined use before funding new work. Speculation about AI should not turn a retired Google feature into an open-ended maintenance commitment.
Give the Next Owner a Clear Decision
The handoff should name the page, the observed issue, the component to change, and what must survive. It also defines a check that closes the task. “Fix FAQ schema” leaves too much room for someone to remove the answers, the wrong emitter, or an entire schema graph.
Use this short record for the actual page you inspected:
- Observation: Which question and answer did you compare, and what matched or differed?
- Source: Which block, plugin, template, or code owner generates the output? Record unverified sources as unknown.
- Decision: Keep, fix, remove, or defer, with the evidence and purpose behind that choice.
- Protected content: Which visible answers and other structured data must remain?
- Completion check: What must the rendered page and emitted data show after the change?
- Owner and review: Who will complete the task, and when will the result be checked?
A Filled Investigation Request
Our proposed, unsent handoff for the public demonstration:
- Page and observation: BrowserBugs FAQ demo, first question inspected October 11, 2026. The visible question and answer correspond to the inspected microdata.
- Decision: Leave that output unchanged while investigating its source. Retirement alone supplies no correction to make to this pair.
- Investigation: Ask the site maintainer which component generates it, whether anything consumes it, and whether it creates a maintenance burden. These answers are currently unknown.
- Protect: Retain the visible question and answer and any unrelated page data during investigation.
- Finish line: The maintainer identifies the producer and dependencies, then records either a reason to retain the output or a separately scoped change with before-and-after checks. No work is assigned and no completion date is claimed here.
For a small site, this can be a short check with whoever maintains its CMS. A larger site may need a plugin or template owner. The point is to identify the responsible source before editing it.
Pick one important FAQ pair and complete that record before commissioning a site-wide cleanup. The work earns its place when it corrects a misdescription, removes an unnecessary maintenance burden, or serves a system that uses the data.