Schema Markup and Structured Data: What Still Earns Its Place in 2026
In May, Google added a deprecation notice to its FAQ structured data documentation, confirming that FAQ rich results would no longer appear in Search. The documentation and related validation and reporting surfaces were subsequently removed, followed by Search Console API support. This was the final step in a longer retreat: Google had already restricted FAQ rich results largely to authoritative government and health sites. For years, the standard pitch for schema markup had emphasized a visible payoff—mark up a page, earn a richer listing, and potentially win more clicks. Its most widely deployed example is now gone.
The conclusion most teams drew was that structured data stopped mattering. The opposite is closer to true. What ended was the era of marking up pages to decorate a search result. What replaced it is quieter and harder to demo in a slide: schema is now a declaration layer that tells machine readers what your entities are and how they relate. That job only holds up if the markup is generated from your content model instead of hand-added page by page, which is why this is an architecture question before it is an SEO one.
The FAQ Rich Result Case Is Gone but Structured Data Still Has Visible Uses
FAQ markup was the entry drug. It was easy to add, it worked on any page with a question on it, and it produced a visibly bigger listing. Most enterprise schema programs started there and never got much further.
That path closed in stages, and the FAQ deprecation was the end of it rather than the start.
| Date | What changed | Practical effect |
|---|---|---|
| August 2023 | FAQ rich results restricted to government and health sites | Commercial sites lost the visible benefit, kept the markup |
| May 7, 2026 | FAQ rich results stop appearing in Google Search entirely | The remaining eligible sites lose it too |
| June 2026 | Google removed the FAQ rich-result documentation and associated feature support from its Search documentation and tooling | FAQ-specific monitoring and validation were retired; general JSON-LD and schema.org validation remained available elsewhere |
| August 2026 | Search Console API support for FAQ rich results removed | Automated monitoring breaks |
The distinction needs to be stated precisely. FAQPage remains a valid schema.org type, but Google no longer supports an FAQ rich result in Search. Existing markup does not need to be treated as an emergency removal project, provided it accurately represents visible page content. It should no longer be justified as a way to earn an FAQ search treatment, and teams should not assume an additional Google benefit that the company has not documented.
Two things follow. First, if the business case for an FAQ implementation depended on rich-result impressions, that case needs to be retired with the feature. Second, any agency or platform still selling FAQPage markup as a dependable visibility tactic is relying on a benefit that had already disappeared for most commercial sites well before Google removed the feature entirely.
What Machines Actually Do With Your Markup
Here is where the honest version of this argument diverges from the marketing version.
Microsoft representatives have publicly encouraged the use of structured data to help Bing interpret page content in AI-driven search experiences. That supports a named benefit within the Bing ecosystem, although it should not be expanded into a claim about every Microsoft Copilot product. Google uses its existing Search infrastructure for AI Overviews and AI Mode, but it has not announced special structured-data requirements or a measurable AI-visibility lift. For Google, the defensible position is that accurate structured data remains part of sound search implementation—not that it independently increases inclusion in an AI answer.
OpenAI, Anthropic, and Perplexity do not currently document schema.org markup as a direct criterion for citation or inclusion in their answers. Their public crawler documentation explains how site owners can manage search, retrieval, and training access, but not which page elements their indexing and answer systems prioritize. That means a citation-rate improvement cannot responsibly be attributed to schema alone without controlled testing. Implement structured data for supported search features, entity clarity, consistency, and future machine use—not on the promise of a guaranteed ChatGPT, Claude, or Perplexity citation lift.
So the defensible position sits between the two claims:
| Claim | Status | What to do about it |
|---|---|---|
| Schema can establish eligibility for supported search features | Retired for FAQ in Google Search but still active across multiple documented types | Implement types tied to a supported feature or a clear entity and content-model use case |
| Structured data can help Bing interpret content for AI-driven search | Supported by public Microsoft statements; not a blanket claim about every Copilot product | Treat it as a Bing ecosystem benefit without forecasting a citation lift |
| Schema may contribute to Google’s general understanding of eligible pages | Reasonable inference from Google Search infrastructure, but not a documented AI Overview advantage | Follow Google’s supported structured-data guidance; do not claim an AI-specific lift |
| Schema causes ChatGPT or Perplexity citations | Unconfirmed by any of those vendors | Do not build a business case on it |
| Schema is a ranking factor | No, and it never was | Stop presenting it as one |
The practical read is that structured data does entity disambiguation, not persuasion. It answers what this page is, which organization published it, which product it describes, and how that entity connects to others. It does not make weak content citable. If the prose on the page does not contain a clean, extractable answer in the body text, no amount of JSON-LD compensates, because the systems that skip your markup are reading the prose.
FAQ content itself did not lose its usefulness when the rich result disappeared. Clear questions followed by concise, factual answers remain easy for readers and machine systems to interpret. The important requirement is that the answer be accessible in the page’s rendered content rather than hidden behind a failed request, blocked script, or interaction that a crawler cannot execute. The rich result disappeared; the value of a well-written answer did not.
The Types That Still Earn Their Place
Most enterprise schema audits find the same pattern: markup on the pages that were easy, nothing on the pages that matter, and three conflicting Organization blocks because two agencies and a plugin all added one.
A short, consistently deployed list usually creates more value than a long, uneven implementation. For Google features, omitting required properties can make an item ineligible for that specific search treatment. Outside those supported features, incomplete markup may still be understood by some consumers, but its value becomes harder to verify. Prioritize accurate coverage of the types that support a defined business or search use case.
| Type | Where it belongs | Why it survives |
|---|---|---|
| Organization | Home page, one canonical block, site-wide | The root entity every other declaration hangs off. Carries sameAs links that connect you to your own profiles elsewhere |
| Article or BlogPosting | Editorial and insight pages | Declares author, publisher, and dates. The author link is what connects a byline to a real person entity |
| Product and Offer | Commerce and pricing pages | Still produces rich results, still the most reliably parsed commercial markup |
| Service | Genuine service and capability pages | Useful for expressing what an organization provides, although Google does not document a general Service rich result; use it for entity clarity rather than a promised search treatment |
| BreadcrumbList | Every page below the root | Cheap, stable, and still rendered. Also declares hierarchy to crawlers |
| Event | Anything with a date, location, and registration | One of the few types where the rich result remains visually distinct |
| Dataset | Pages presenting a genuine downloadable or queryable dataset | Can help eligible data assets appear in Google Dataset Search; Google has clarified that this markup is not used for a standard Google Search rich result |
Three particularly useful properties are sameAs, isPartOf, and author, because each expresses a relationship that would otherwise need to be inferred. sameAs can connect an organization or person to authoritative profiles representing the same entity. isPartOf can describe a page’s relationship to a larger creative work or website. author associates editorial content with a person or organization. These properties improve explicit entity and content relationships, but they should not be presented as guaranteed ranking or citation signals.
What to stop doing: adding FAQPage solely for a discontinued rich result, marking up content that users cannot access on the page, publishing conflicting Organization entities, and adding types with no supported feature or useful relationship to declare. Use a stable @id so page-level nodes can reference one canonical organization entity without duplicating contradictory names, URLs, logos, or profiles.
Schema Markup You Add By Hand Is Schema Markup You Will Lose
Every one of the decisions above is trivial on ten pages and unmanageable on four thousand.
This is the failure mode that separates a schema project from a schema capability. A team runs a markup initiative, hits eighty percent coverage, and declares it done. Eighteen months later a template has been redesigned, a plugin has been updated, two agencies have shipped competing implementations, and the person who understood the JSON-LD has left. Nobody knows which pages are covered, because there was never a system that knew.
The distinction is where the markup comes from.
| Dimension | Hand-added schema | Model-generated schema |
|---|---|---|
| Source of truth | Markup maintained on individual pages | Governed CMS fields and references |
| Coverage on a new page | Depends on an editor or plugin action | Can be inherited from the content type and template |
| Effect of a redesign | Easy to omit or leave stale | More resilient, but still requires regression testing |
| Correcting a shared value | May require multiple page edits | Can update every dependent output from one governed field |
| Auditability | Usually requires crawling rendered pages | Can combine model queries, automated tests, and production crawls |
Generated schema means the markup is a function of typed content fields, not a block someone pastes in. A structured content model already holds the author as a reference, the publish date as a date field, the parent pillar as a relationship, and the product name as a string. Rendering valid JSON-LD from that is a template concern. Change the pillar reference on one entry and the isPartOf declaration updates everywhere it appears.
A well-modeled headless CMS makes this pattern easier to sustain because reusable content types, reference fields, and delivery APIs can provide a consistent source for the schema graph. The front end can then generate JSON-LD from the same fields used to render the page, keeping structured data separate from visual layout while tying it to governed content. Headless is not a requirement a coupled CMS can implement the same pattern through templates, fields, and disciplined ownership but composable architectures make the separation between content, presentation, and machine-readable output explicit. In eight25’s work moving Qlik from Sitecore to Contentful, the estate included thousands of pages and 19 languages. At that scale, generation is an operating requirement: editors should manage the underlying facts while the delivery layer assembles the corresponding schema consistently across templates and locales.
There is a quick way to test which one you have. Pick a fact that appears in your markup on more than one page, change it in a single place, and see how many pages update. If the answer is one, your structured data is decoration, and it will decay on the same schedule as everything else nobody owns.
Migration Is Where Structured Data Silently Dies
A replatform is the single most common moment structured data breaks, and almost nothing in a standard migration QA checklist catches it.
The reason is that schema is invisible. A missing hero image gets reported in the first hour of UAT. A missing Organization block gets reported never, because no human looking at the page can tell. The failures cluster in predictable places.
| Failure | How it happens | Where to catch it |
|---|---|---|
| Markup not ported | The old platform generated it from a plugin nobody inventoried | Pre-migration structured data crawl of the legacy site |
| Available only after client-side execution | The front end injects JSON-LD after JavaScript runs, so consumers that do not render the page may miss it | Check both the initial HTML response and rendered DOM; prefer server-rendered or statically generated JSON-LD when broad crawler compatibility matters |
| Conflicting Organization entities | A legacy template, plugin, and new implementation publish different names, URLs, logos, or identifiers for the same organization | Crawl all Organization nodes, confirm they resolve to a canonical @id, and investigate contradictory values |
| Stale absolute URLs | sameAs, url, and logo still point at the old domain or CDN | Diff every URL in every JSON-LD payload against the new domain |
| Author references broken | People existed as free text before and as entities now | Validate author resolves on a sample of every content type |
| Blocked from retrieval bots | Inherited robots.txt or tightened CDN rules stop the bots reaching the page at all | Server log check that retrieval crawlers get a 200 |
The last row can make the schema work irrelevant to a particular system. If OAI-SearchBot, PerplexityBot, or Claude-SearchBot cannot access a URL, that page’s visibility in the corresponding search experience may be reduced or eliminated. User-initiated fetchers—including ChatGPT-User, Perplexity-User, and Claude-User—are separate and may follow different access rules. Training crawlers such as GPTBot and ClaudeBot serve another purpose again. Audit robots.txt, CDN rules, WAF behavior, status codes, and published crawler IP ranges separately for search, user retrieval, and model-training access rather than applying a single blanket AI-bot policy.
In eight25’s headless and composable CMS work, structured-data requirements can be mapped during discovery to the content model, templates, and migration inventory, then tested again at cutover alongside redirects, canonicals, hreflang, crawler access, and status codes. Treating schema as part of platform architecture—not as a post-launch SEO patch—reduces the risk of a new site shipping with less machine-readable context than the platform it replaced.
Where This Leaves Your Schema Program
Structured data is becoming a more disciplined practice than the version often sold as a shortcut to larger search listings. Some visible features remain valuable, while others—including FAQ rich results—have disappeared. Microsoft has publicly connected structured information with AI-driven search understanding, but OpenAI, Anthropic, Perplexity, and Google do not promise citation or AI-visibility gains from schema.org markup alone. The durable opportunity is operational: generate accurate declarations from governed content and maintain them as part of the web platform.
Three questions reveal whether you have a structured-data capability or a collection of tags. Can you identify which content types and URLs generate each declaration? Will automated tests detect a schema regression when a template changes? Can the search and retrieval systems you care about access the resulting pages? Strong implementations answer all three through a governed content model, generation rules, deployment tests, and production crawling. That is where a composable architecture earns its advantage: not by producing JSON-LD automatically, but by giving content, code, and QA a shared contract.
For teams working through the wider question of how AI answer engines read a site, the distinction between SEO, GEO, and AEO covers the strategy layer that sits above this implementation detail.
Frequently Asked Questions
Should we remove FAQPage markup from our pages now that Google dropped the rich result?
No. Google’s documentation states that unused structured data does not cause problems for Search and that FAQPage remains a valid schema.org type. Removing it is unnecessary work. What should change is your expectation: it will not produce a rich result, so it should not appear in a business case. Keep the FAQ content itself as HTML body text, because question and answer pairs remain highly extractable regardless of markup.
Is schema markup a Google ranking factor?
Google does not document structured data as a general ranking factor. It can establish eligibility for supported search features and help Google interpret page content and entities, but valid markup does not guarantee that a rich result will appear or that a page will rank higher. Ranking depends on many query-, content-, site-, and system-level signals, so structured data should be treated as implementation infrastructure rather than a standalone ranking lever.
Does schema markup get our content cited by ChatGPT or Perplexity?
There is no confirmation from OpenAI, Anthropic, or Perplexity that their retrieval systems parse schema.org markup. Microsoft has publicly confirmed that schema helps its models understand content, which covers Copilot. The honest position is that structured data is confirmed useful for some AI systems and unproven for others, so implement it for entity clarity and build your extractability strategy in the body prose where every system will read it.
How many schema types should an enterprise site implement?
Most enterprise sites should begin with a small set mapped to real content and search use cases—for example, Organization, Article or BlogPosting, BreadcrumbList, Product where appropriate, and Event when the eligibility requirements are met. The right list depends on the site. For Google-supported features, missing required properties can make an item ineligible for that treatment, so reliable coverage of a few relevant types is generally more valuable than superficial coverage of many.
What is the difference between hand-added and generated schema markup?
Hand-added markup is maintained directly on individual pages, which makes coverage and shared-value changes difficult to govern. Generated markup is assembled from structured fields and references, allowing new entries to inherit appropriate declarations and shared facts to be corrected centrally. Generation does not make schema immune to redesigns—the templates and delivery code still require testing—but it reduces page-level drift. This pattern is especially natural in a headless CMS, where the content model and front-end rendering logic already have defined responsibilities.
When during a CMS migration should structured data be checked?
Twice. Inventory the legacy site’s structured data during discovery, before the content model is fixed, so schema requirements shape the typed fields rather than getting retrofitted onto them. Then validate again at cutover, comparing raw HTML against the rendered DOM to confirm the markup is server rendered, and check server logs to confirm retrieval bots are receiving a 200 on the URLs that matter.