Is Structured Data Still Worth It After FAQ Rich Results?

Structured data is still worth maintaining when it accurately describes your business and supports a feature relevant to the page. It is not worth buying as a promise that Google will show stars, expandable answers or an AI citation. The decision starts with the page and the supported feature, not with how many schema types a plugin can generate.

Google stopped showing FAQ rich results on 7 May 2026. That changes the case for adding FAQ markup to a business website, but it does not make product information, article details or organisation data pointless.

For an Indian business deciding where to spend its next development budget, the useful question is specific: what can this implementation help a customer or search system understand, and how will we check that it stays correct? A proposal that cannot answer that deserves more scrutiny than a reassuring green score from a validator.

What did Google retire, and when?

Google's Search documentation changelog records a deprecation notice on 8 May 2026, stating that FAQ rich results would no longer appear from 7 May. On 15 June, Google removed the feature's documentation because those results were no longer shown.

This followed an earlier restriction. Google's August 2023 announcement, updated that September, had limited FAQ rich results to authoritative government and health sites. The same post's September update says HowTo rich results stopped appearing on desktop on 13 September 2023, completing their removal from Search. HowTo is not an unresolved retirement question.

Keep two different things separate. Google's support for a search presentation is one thing; the existence of a vocabulary term is another. FAQPage remains a Schema.org type for a page presenting frequently asked questions. A vocabulary validator recognising that type does not mean Google still offers the former FAQ display.

Nor should the visible answers disappear. If customers need to know your service area, delivery terms or booking process, a useful FAQ section remains useful content. Remove the expectation of a particular search decoration, not information people need to make a decision.

What is structured data actually for now?

Google's introduction to structured data describes using it to understand page content and gather information about entities such as people and organisations. Supported markup can also make a page eligible for particular search features.

That gives you two practical reasons to do the work: represent real information consistently, and support an applicable feature. Neither is a guarantee of a ranking increase. Do not turn a potential improvement in presentation into a forecast of clicks or sales.

Before approving an implementation, ask for the intended page type, the relevant documentation and the information the website will supply. “We will add schema across every page” does not tell you whether a product's stock status will remain accurate or whether the business name is consistent.

For a small brochure site, the appropriate scope may be modest. A store with changing offers or a publisher with many authors has a different maintenance problem. The count of markup blocks is a poor way to compare those projects.

Which types should a business prioritise?

Start with Google's current structured-data gallery, then read the instructions for the specific feature. The examples below are a shortlist for evaluation, not a package every website needs.

Page or business need	Markup to evaluate	The question to settle first
Identify the organisation	Organization or a suitable subtype	Are the name, logo and business details correct?
Explain a real product	Product, with the appropriate product feature	Is this a purchasable offer, a review or another product page?
Describe an editorial article	Article or BlogPosting	Are authorship, images and dates accurate?
Show a navigational path	BreadcrumbList	Does the path reflect how readers navigate?
Present eligible reviews	Review or AggregateRating under the relevant rules	Is the reviewed entity and review source eligible?
Answer common customer questions	Useful visible FAQ content	Does it answer a real question, independently of markup?

Google's Organization guidance says the information can help disambiguate an organisation and influence details such as its logo. It recommends the home page or one page describing the organisation; it does not require copying the same standalone block onto every page. Use relevant, truthful properties rather than filling every available field.

For articles, Google's Article documentation describes helping it understand details such as title, images, dates and author. Generate those details from the actual article record. Do not invent an expert author or refresh the modified date merely because a build ran.

Breadcrumbs need similar care. Google's breadcrumb guidance recommends a typical user path rather than simply mirroring the URL structure. You do not need to redesign your URLs to make a breadcrumb implementation look tidier.

Do product and review rules change the decision?

Yes. Two shortcuts in schema advice regularly lead to the wrong implementation: treating every product page as a merchant listing, and treating every testimonial as eligible for stars.

Google's Product introduction distinguishes product snippets for pages where visitors cannot directly purchase from merchant listings for pages where they can. Read the requirements for your actual use case. A legitimate editorial product page is not automatically excluded because there is no checkout button.

On a store, use the same catalogue data for visible prices, currency, availability and the corresponding markup. If a product becomes unavailable, both representations should change together. Shared data reduces mismatches; it does not eliminate the need to test variants, discounts and cached pages.

Reviews require a separate policy check. Google's review-snippet guidelines exclude self-serving reviews for LocalBusiness and Organization, including reviews shown through an embedded third-party widget. A real customer testimonial on your own business page does not automatically qualify that business for review stars.

Keep genuine testimonials if they help readers. Do not relabel the business as another entity type merely to try to get around the restriction. And never copy a rating or review count into markup when it does not describe the visible, relevant review content.

Does schema improve AI Overviews or AI Mode visibility?

Google's AI features guidance says there is no special schema required for AI Overviews or AI Mode. It points website owners towards ordinary search fundamentals, including crawl access, internal links, useful textual content and structured data matching visible information.

It also says a supporting page must be indexed and eligible to appear in Search with a snippet. Meeting those conditions does not guarantee inclusion. An additional “AI schema” package is not a documented shortcut around them.

Be precise about the conclusion. Not required does not mean Google never uses structured information. Nor does Google's documentation establish the behaviour of every other AI search service. Claims about ChatGPT or Perplexity need evidence specific to those systems; a Google rich-result test cannot demonstrate their citation behaviour.

For a buyer, the sensible response is to ask what the supplier will actually deliver and measure. Clear business information and technically accessible pages are inspectable deliverables. A guarantee that an assistant will cite your business is a different claim.

Our guide to measuring AI search traffic in GA4 addresses measurement separately. Do not treat the presence of a markup block as evidence that customers found you through AI search.

How do you check whether markup is working?

Use a sequence of checks rather than a single pass/fail badge. First inspect what the public page actually outputs, not just the editor or plugin settings. Then compare the structured information with the visible page and the current feature documentation.

Google's general structured-data guidelines recommend technical testing with the Rich Results Test and URL Inspection. They also explain that correct markup does not guarantee a rich result and that automated tests do not catch every quality or policy issue.

Keep these distinctions in the report:

Check	What it establishes	What it does not establish
Vocabulary and syntax validation	The markup can be interpreted and uses recognised terms	A supported Google feature or policy compliance
Feature-specific technical test	Detected technical requirements for a supported feature	Guaranteed search appearance
Public-page inspection	The deployed page contains the expected data	That Google has crawled or indexed that version
Search Console and search performance	What Google reports for the available period and pages	That markup alone caused any change

If the page is unknown to Google, say so. Public availability, indexing and rich-result appearance are separate states. Do not describe a newly published page as successfully indexed merely because it returns HTTP 200.

After a deployment, check representative pages from each affected template, including awkward cases. For a store that could mean an unavailable item and a variant; for a publisher, an article with multiple authors or a changed headline. One successful example does not prove the whole template stays accurate.

What should you stop doing?

Stop adding FAQPage purely to recover the retired Google FAQ display. Stop purchasing a fixed number of schema types as if quantity were a search signal. And stop adding invisible ratings, invented business locations or unsupported claims to satisfy a plugin checklist.

Inspect existing output before installing another generator. Multiple blocks can describe different legitimate entities; the problem is conflicting or misleading descriptions, not simply having more than one block. Identify which component owns the information before changing it.

Do not make removal of accurate legacy markup an urgent redesign project without a concrete reason. Google's 2023 announcement explained that unused structured data need not be proactively removed. If another consumer genuinely uses it, consider that dependency as well. Correct false information promptly; prioritise optional cleanup according to its real maintenance cost.

Finally, do not assume a schema task is always tiny or always expensive. A straightforward article template and a catalogue with inconsistent variant data are different jobs. Ask for a written scope covering data sources, supported features, validation and maintenance, rather than accepting a blanket promise or rejecting a quote by its label.

What should you ask a supplier to deliver?

Request a page-type inventory, a mapping to currently documented features, and examples showing the deployed output against the visible content. Ask who owns future updates when a price, author, business address or Google requirement changes.

Then agree how performance will be assessed over comparable completed periods. Keep track of other changes to content and presentation so a rise in clicks is not automatically credited to markup. Do not promise a percentage improvement before there is evidence.

For SEO work, structured data belongs alongside content quality, technical access and measurement. For web development, it should be generated from maintained source data and checked after release. Neither service should depend on pretending a retired feature still exists.

Ask us to review what your site outputs if you are unsure which work matters. The useful answer may be to fix one inaccurate template and leave the rest alone.