Google Retired FAQ Rich Results: What to Do With FAQPage Markup Now

Google has retired FAQ rich results in Search, but that does not automatically mean every site should delete FAQPage markup. This review explains what changed in Google Search, what still remains valid in Schema.org, when keeping FAQ markup is defensible, when removal is cleaner, and why replacing editorial FAQs with QAPage is usually the wrong shortcut.

Practical default: stop treating FAQPage as a Google FAQ-snippet optimization. Keep it only where the page is genuinely an FAQ, the questions and answers are visible to users, the content is maintained, and the markup remains useful as machine-readable structured data. Remove or refactor stale, duplicated, hidden, or semantically misleading FAQ schema.

Executive summary

Google’s notice is significant, but it is easy to overread it. As of May 7, 2026, Google says FAQ rich results no longer appear in Google Search. Google also says it will remove the FAQ search appearance, the FAQ rich result report, and FAQ support in the Rich Results Test in June 2026, and remove FAQ rich result support from the Search Console API in August 2026. Search Console’s anomaly log also confirms that FAQ impressions in the relevant reports drop from May 7 onward because the feature is no longer shown.

That does not automatically mean FAQPage has become a bad schema type, or that every site should rush to delete it. What has clearly ended is a Google Search appearance. The broader Schema.org FAQPage type still exists, Google still describes structured data as a way to help machines understand page meaning, and Google’s own structured data documentation notes that Schema.org elements not required by Google may still be useful for other search engines, services, tools, and platforms.

The best post-deprecation response is not a universal “delete” or a universal “keep.” It is a classification exercise. Site owners should separate standalone editorial FAQ pages, product or article pages with supporting FAQ sections, repeated boilerplate FAQ blocks, forum-style Q&A pages, and Search Console reporting pipelines. Each category has a different answer.

The most important warning is this: QAPage is not a general replacement for FAQPage. Google’s Q&A structured data documentation is explicit that QAPage is for one-question pages where users can submit answers, not for normal site-authored FAQ pages with multiple questions and one canonical answer per question.

What Google has actually deprecated

The cleanest reading is this: Google has retired the visible FAQ enhancement in Google Search and is cleaning up the surrounding tools and reporting. The deprecation affects four operational areas:

• the FAQ rich result in Google Search;
• the FAQ search appearance in Search Console reporting;
• FAQ enhancement-style diagnostics in Search Console and Rich Results Test;
• related Search Console API support for FAQ rich-result data.

This is the end of a longer trend. In August 2023, Google had already reduced FAQ rich results so they were shown only for well-known, authoritative health and government sites. At that time, Google also said site owners could remove the markup but did not need to proactively do so, because unused structured data did not cause problems for Search. The 2026 notice goes one step further: FAQ rich results are now gone from Google Search entirely.

One detail matters for implementation teams. Lower on Google’s FAQPage documentation, older explanatory text may still describe historical eligibility for health and government sites. But the top deprecation notice on that same page, together with the Search Console anomaly page, is the current operational statement: as of May 7, 2026, FAQ rich results are no longer appearing in Google Search. For practical SEO decisions, that top-level notice should control the decision.

Why FAQPage is not dead outside Google

FAQPage still exists in Schema.org as an official type under WebPage, defined as a page presenting one or more frequently asked questions. In other words, Google has deprecated a feature, but Schema.org has not deprecated the type itself.

Google’s structured data documentation also supports a wider view. Google says structured data helps it understand page content and gather information about the web and the world more generally. The same documentation explains that there are Schema.org attributes and objects Google does not require, but that may still be useful for other search engines, services, tools, and platforms. That is an important line for site owners: Google is telling publishers that the value of structured data is broader than one Google rich result.

Schema.org makes the same point from the standards side. It describes itself as a vocabulary for structured data on the internet, on web pages, in email messages, and beyond. The Schema.org documentation also says its schemas enable webmasters to embed structured data for use by search engines and other applications. Yandex’s official materials make the practical implication even more explicit: data marked up according to Schema.org becomes public and can be extracted or used by any service, and Yandex’s structured data validator recognizes Schema.org among other markup formats.

The practical conclusion is simple: if FAQPage is accurate, maintained, visible, and helpful as machine-readable content, it can still have value outside Google’s old FAQ snippet. What should stop is treating it as a tactic for winning Google FAQ SERP space, because that part is over.

When keeping FAQPage still makes sense

For many sites, the best answer is not “delete everything,” but “stop expecting Google FAQ rich results and decide whether the markup still earns its keep as structured content.” That is especially true for pages that are genuinely editorial FAQs owned by the site, with one authoritative answer per question, visible to users, and maintained as part of normal content operations.

Keeping FAQPage is strongest in three cases:

• A real FAQ hub page. The page exists primarily to answer recurring user questions, not merely to add a search feature to another page type.
• A site that values machine-readability beyond Google rich results. This may include broader search ecosystem compatibility, internal knowledge extraction, downstream tools, or other machine consumers.
• A site with clean schema governance. The FAQ markup stays synchronized with visible page content and therefore does not create maintenance debt.

These recommendations are an operational inference from Google’s earlier no-need-to-remove stance, Schema.org’s continuing support for FAQPage, and Google’s statement that non-Google-required schema may still help other platforms.

There are also cases where removal is the smarter choice. If the FAQ markup is stale, partially hidden, copied everywhere, or no longer reflects the page’s main visible content, it is better to remove or refactor it than to keep dead weight. Google’s general structured data guidelines warn against markup that is not representative of the main content, not visible to users, or misleading. Such problems can lead to ineligibility for rich-result features or structured data manual actions where applicable.

Google’s FAQPage guide also says that repetitive FAQ content appearing across many pages should be marked up only once across the site. That point matters more after deprecation, because the old incentive to mark every instance for a FAQ result is gone. If the same shipping, returns, warranty, or account questions are stamped onto hundreds of templates, the cleanest move is usually to consolidate those repeated questions into a maintained FAQ page and mark up only that primary instance.

Validation workflow after FAQ leaves Google tools

The tooling changes with the feature. Once FAQ support disappears from the Rich Results Test, the absence of a Google FAQ result will not mean the Schema.org markup is invalid. It will simply mean Google no longer supports that feature in that Google-specific tool.

Google recommends the Rich Results Test for Google-specific rich-result validation and the Schema Markup Validator for generic Schema.org validation. If Yandex matters in the site’s market mix, Yandex also offers an official structured data validator that checks whether metadata is recognized and whether it meets Yandex requirements.

If the implementation is being touched anyway, Google still recommends JSON-LD as the easiest structured data format to implement and maintain at scale. There is no urgent reason to rewrite working FAQ microdata purely because Google retired FAQ rich results, but if templates are already being refactored, moving from brittle inline microdata to JSON-LD can be a sensible maintenance upgrade.

Why swapping FAQPage for QAPage is the wrong shortcut

This is the most important trap to avoid. QAPage is not a general replacement for FAQPage. Google’s Q&A page documentation is explicit: use QAPage only when a page contains one question followed by its answers, and users must be able to submit answers. Google also explicitly says not to use QAPage for FAQ pages, for pages with multiple questions on one page, for how-to guides, blog posts, essays, or any page that has only one site-written answer with no alternative user answers.

That is not only a Google rule of thumb; it reflects the underlying Schema.org semantics. In Schema.org, QAPage is a page focused on a specific Question and its answer or answers. Its acceptedAnswer property means the answer accepted as best, typically on a question-and-answer site, and suggestedAnswer means one of several possible answers that may even be incorrect. This is the language of community Q&A systems, moderation, voting, and alternative replies. It is not the language of a brand-owned editorial FAQ with one canonical answer.

Replacing FAQPage with QAPage creates a semantic lie. You would be telling parsers that your page is a single-question answer thread with user-submitted or multi-answer dynamics, when in reality it is an editorial FAQ block. Google’s quality guidelines specifically warn that structured data must be a true representation of page content and must not be misleading. Misusing QAPage therefore risks at least three bad outcomes: the markup is ignored, the page becomes ineligible for the intended feature, or the markup is treated as deceptive structured data.

There is one narrow exception in Google’s Q&A documentation: education-related Q&A pages may qualify for a special carousel even when a single top answer is selected by in-house experts rather than users. That is a specific exception for a specific content pattern. It does not turn ordinary FAQ pages into QAPage candidates.

The practical rule is straightforward: if the content is a site-authored FAQ, keep it as FAQ-shaped data or remove it. Do not camouflage it as QAPage just because Google retired FAQ rich results.

If FAQPage is nested under mainEntity

If the current schema looks like WebPage → mainEntity → FAQPage, it is worth cleaning up. In Schema.org, mainEntity means the primary entity described in a page or other CreativeWork. Separately, FAQPage itself is already a subtype of WebPage. A page whose mainEntity is another FAQPage is therefore usually modeling the page as primarily describing another page. That is redundant at best and confusing at worst.

Google’s FAQPage guide shows the simpler and clearer model: the page itself is typed as FAQPage, and its mainEntity property contains an array of Question items. Google explicitly requires FAQPage.mainEntity to hold the answered Question elements the page is about. If the page really is an FAQ page, the cleanup is straightforward: make the page @type FAQPage and place the questions inside mainEntity.

A simplified correct model for a standalone FAQ page looks like this:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Can I still keep FAQPage markup?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes, if the FAQ content is visible, accurate, maintained, and useful as structured content beyond Google FAQ rich results."
      }
    }
  ]
}

A pattern that is often unnecessarily confusing is this:

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "mainEntity": {
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "Example question?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Example answer."
        }
      }
    ]
  }
}

If the page’s main focus is not an FAQ page, the answer is different. Google’s general structured data guidelines tell site owners to include the main type of structured data that reflects the page’s main focus, and explain that pages can contain multiple structured data items as long as the main purpose of the page is represented clearly and the markup matches visible content. So if the page is mainly a product page, article, recipe, service page, or another primary entity, that entity should stay central. In that situation, wrapping the whole page as FAQPage or making FAQPage the page’s main semantic identity is usually the wrong model unless the page genuinely functions as a standalone FAQ page.

The practical rule is easy to remember. If the page is fundamentally a frequently asked questions page, type the page as FAQPage. If the FAQ is only a supporting section on another page type, do not promote that supporting section into the page’s main semantic identity unless that really reflects what the page is.

Decision table for existing FAQ markup

Page or implementation pattern	Recommended action	Why it matters
Standalone editorial FAQ page with visible questions and one authoritative answer per question	Keeping FAQPage is still defensible, but stop expecting Google FAQ rich results.	The schema still accurately describes the page and may remain useful for non-Google machine consumers.
Product, service, category, or article page with a small supporting FAQ block	Keep the primary schema for the page’s real purpose; remove or keep the FAQ section only if it is accurate, visible, and worth maintaining.	The main schema type should reflect the page’s main focus, not a secondary FAQ block.
Repeated boilerplate FAQ copied across hundreds of pages	Usually consolidate to one maintained FAQ page and mark up only the primary instance.	Google’s FAQ guidance warns against marking the same repetitive FAQ content across many pages.
Forum, support thread, or UGC answer page with one question and user-submitted answers	Consider QAPage if the content genuinely matches Q&A semantics.	QAPage is for single-question pages with answer submissions or Q&A dynamics, not normal FAQs.
Editorial FAQ disguised as QAPage	Do not use QAPage. Keep valid FAQ-shaped data or remove the markup.	Mislabeling the content creates misleading structured data.
WebPage → mainEntity → FAQPage nesting	Clean up the model based on page intent.	For a real FAQ page, type the page as FAQPage. For another primary page type, avoid making FAQ the main identity unless it truly is.
Search Console dashboard or API pipeline expecting FAQ appearance data	Annotate May 7, 2026 and remove FAQ-specific reporting assumptions before API support disappears.	The reporting drop is a feature retirement, not necessarily a generic SEO collapse.

Action plans by team and scenario

Standalone editorial FAQ page

If the page is a true, site-authored FAQ page with visible questions and one authoritative answer per question, keeping FAQPage is still a defensible choice for machine-readability even though Google will no longer show FAQ rich results. Validate it with the Schema Markup Validator, keep it synchronized with visible content, and stop treating it as a Google rich-result optimization. If the same FAQ appears elsewhere, mark up only the main maintained instance.

Product, service, category, or article page with a small FAQ block

If the FAQ is only a supporting section, first ask whether that extra schema is worth the maintenance overhead. Google says markup must represent the page’s main content, and the main type should reflect the main focus of the page. In many cases, the better move is to keep the primary schema for the page’s real purpose and remove the page-level FAQPage layer, especially if the FAQ block is repetitive or hard to maintain.

Forum, support thread, or UGC answer page

Use QAPage only if the page is truly a single-question page with user-submitted answers or another Q&A pattern that matches Google’s and Schema.org’s semantics. Do not switch editorial FAQs to QAPage. If the page allows users to answer one question, QAPage may be correct; if it does not, it is the wrong type.

Implementation where FAQPage sits inside mainEntity

If FAQPage is currently used as the value of mainEntity, clean it up based on page intent. For a real FAQ page, flatten the model so the page itself is FAQPage, with Question objects in FAQPage.mainEntity. For a page whose main entity is something else, keep that primary type and avoid making FAQPage the page’s main semantic identity unless the page truly is an FAQ page.

SEO and analytics teams using Search Console reports or API pipelines

Treat May 7, 2026 as the break point for FAQ-rich-result visibility in Google Search. In reports and dashboards, annotate that date so stakeholders do not misread the drop as a generic SEO collapse. If you query Search Console by searchAppearance, plan to remove logic that expects FAQ search appearance data before August 2026, because Google has said FAQ support in the Search Console API will be removed then. Replace FAQ-appearance monitoring with page-, query-, device-, and country-level analyses, and use URL Inspection plus generic schema validation for quality control.

Teams refactoring templates anyway

Do not refactor just because Google removed FAQ snippets. Refactor only if the current implementation is fragile, duplicated, misleading, or expensive to maintain. If you do refactor, Google recommends JSON-LD as the easiest format to maintain at scale, while Schema Markup Validator remains the right generic validation tool once FAQ leaves the Rich Results Test.

Checklist for FAQPage cleanup

• [ ] Confirm whether the page is primarily an FAQ page or another page type with a supporting FAQ section.
• [ ] Remove expectations of Google FAQ rich-result visibility from SEO forecasts, dashboards, and stakeholder reports.
• [ ] Annotate May 7, 2026 in Search Console reporting so the FAQ impression drop is not mistaken for a generic ranking or indexing failure.
• [ ] Remove or revise Search Console API logic that depends on FAQ rich-result support before Google removes API support in August 2026.
• [ ] Keep FAQPage only where visible FAQ content is accurate, maintained, and semantically central enough to justify markup.
• [ ] Consolidate repeated shipping, returns, warranty, account, or policy FAQs into one maintained page where practical.
• [ ] Do not replace editorial FAQ content with QAPage unless the page is truly a single-question Q&A page with answer-submission dynamics.
• [ ] Validate generic Schema.org syntax with Schema Markup Validator, not only with Google rich-result tools.
• [ ] If refactoring templates, prefer JSON-LD for maintainability and keep the markup synchronized with visible content.

Bottom line

Google has retired the FAQ rich result, not the idea of machine-readable FAQs. For Google-only SERP gain, FAQPage no longer has the old payoff. But for clean structured content, other search engines and services, and future-proof machine readability, FAQPage can still be worth keeping when it is truthful, visible, maintained, and not abused as a shortcut to something it is not.

The worst reaction is not keeping it. The worst reaction is mislabeling editorial FAQ content as QAPage or letting stale schema drift away from the page users actually see. After the deprecation, structured data work should become less tactical and more semantic: describe the page accurately, validate it generically, and remove markup that no longer represents the content.

Methodology and sources

This article is based on a review of Google Search Central documentation, Google Search Console anomaly notes, Google’s 2023 FAQ and HowTo rich-result update, Schema.org type and property definitions, Schema.org documentation, Yandex Webmaster documentation, and the source research brief supplied for publication. The review focuses on practical SEO, structured data governance, Search Console reporting, and schema semantics for production websites.

• Google Search Central: FAQPage structured data
• Google Search Console: data anomalies
• Google Search Central Blog: Changes to HowTo and FAQ rich results
• Google Search Central: Intro to how structured data markup works
• Google Search Central: General structured data guidelines
• Google Search Central: Q&A page structured data
• Google Search Central: Schema markup testing tools
• Schema.org: FAQPage
• Schema.org: QAPage
• Schema.org: mainEntity
• Schema.org documentation
• Schema Markup Validator
• Yandex Webmaster: Schema.org
• Yandex Webmaster: Structured data validator

This article is for technical and operational information only. metricfixer is not affiliated with Google, Search Console, Schema.org, Yandex, or other third-party platforms and publishers mentioned in the article. Search-engine documentation, structured-data support, reporting surfaces, testing tools, and rich-result eligibility rules may change after publication. Always validate the current implementation against the live documentation and the site’s actual rendered content.