Structured data has become one of the most misunderstood tools in SEO, largely because its actual function gets conflated with its potential outcome. Site owners add schema markup expecting a guaranteed star rating, FAQ dropdown, or product carousel, then get confused when nothing changes in the search results. The truth is more precise: structured data helps Google understand and classify a page’s content, and it can make that page eligible for enhanced display, but eligibility and appearance are two different things.
This article walks through what structured data genuinely does, where the eligibility-versus-guarantee confusion comes from, and how to validate markup in a way that actually matters.
Table of Contents
This distinction matters more in 2026 than it used to. Google has spent the past three years steadily narrowing which structured data types actually produce a visible feature in search results, retiring several entirely rather than just restricting them.
That pattern makes understanding the real mechanics of structured data, not just the syntax, essential for anyone maintaining a WordPress site with Rank Math or any other schema plugin. The sections below work through each layer: what structured data does, what it cannot promise, and how to implement it so it holds up over time.
What Structured Data Actually Does
At its core, structured data is a standardized way of labeling page content so search engines can parse it as discrete, meaningful pieces of information rather than unstructured text. On a recipe page, for example, markup can explicitly identify the ingredients, cook time, and calorie count, rather than leaving Google to infer that information from the surrounding paragraph.
Google uses this labeled data both to understand a page’s content and to gather broader information about entities like people, organizations, and products across the web. When implemented correctly, it can also make a page eligible for enhanced display formats known as rich results, as Google’s own introduction to structured data explains in detail.
Structured data can be written in one of three supported formats: JSON-LD, Microdata, or RDFa, all equally valid as long as the syntax is correct. Google recommends JSON-LD specifically because it lives in a single script tag rather than being woven through the visible HTML, which makes it easier to implement and maintain, especially for nested data like a venue’s address inside an event listing.
The markup needs to sit on the same page it describes, and Google recommends applying identical structured data across every duplicate of a page rather than only the canonical version. For most WordPress users, a plugin like Rank Math handles this placement automatically for supported content types.
The upside is well documented. Google’s own case studies report that Rotten Tomatoes saw a 25% higher click-through rate on pages using structured data, and the Food Network recorded a 35% increase in visits after converting the majority of its pages to support search features.
Rakuten found that users spent 1.5 times longer on structured-data pages, while Nestlé measured an 82% higher click-through rate on pages that achieved rich result display. These are real, measurable outcomes, but notice the qualifier in that last example: the benefit was tied to pages that achieved rich result status, not simply pages that included markup.
The Core Misconception: Eligibility Is Not a Guarantee
Google states this directly in its own developer documentation, and it is worth repeating because so much SEO advice glosses over it: structured data does not guarantee that a rich result will appear, even when a page is marked up correctly and passes validation.
Using structured data enables a feature to be considered, but Google’s ranking systems still decide, page by page and query by query, which format actually serves the user best. In some cases that means a rich result. In many others, it means a standard text result, even with flawless markup sitting in the page’s code.
Google names several specific reasons a rich result might not appear despite valid markup. Search algorithms personalize results by device, location, and search history, so a text result sometimes serves the user better than a visual one. Structured data that does not accurately represent a page’s main content, or that describes something hidden from view, can also be excluded, along with markup that fails checks the automated Rich Results Test cannot catch. Understanding these reasons reframes the goal: structured data should be treated as a way to become eligible, not a lever that directly produces a result.
Case in Point: The FAQ Rich Result Deprecation
No recent example illustrates the eligibility-versus-guarantee gap better than what happened to FAQ rich results. In August 2023, Google restricted the FAQ dropdown feature to a narrow set of well-known government and health websites, which meant the vast majority of sites with FAQPage markup stopped seeing the feature almost overnight, despite their schema remaining perfectly valid.
In May 2026, Google went further and retired the FAQ rich result entirely, removing it even for the previously eligible government and health sites. Support for the feature is being phased out of Search Console and the Rich Results Test through the middle of 2026 as well.
This matters because FAQPage schema itself was never deprecated and remains a perfectly valid schema.org type; only the visible search feature it once enabled was retired. Sites that keep FAQ markup on their pages will not see errors, penalties, or ranking changes as a result.
What they will not get, regardless of how well the markup validates, is the expandable dropdown that used to appear beneath organic listings. It is the clearest possible demonstration that a structured data type being valid, even implemented flawlessly, says nothing about whether Google will choose to display it as a rich result indefinitely.
Matching Markup to Visible Content
One of Google’s clearest, most consistently enforced rules is that structured data must describe content that is actually visible to a reader on the page. If JSON-LD markup identifies a specific performer, price, or rating, that same information needs to appear in the page’s visible HTML, not just in the script tag.
Marking up information that a user cannot see on the page, even if that information happens to be accurate, violates this rule and puts a page’s rich-result eligibility at risk. This requirement exists to stop structured data from misrepresenting what a real visitor actually sees.
Google’s guidelines give concrete examples of what this looks like in practice: a sports live-streaming site labeling its broadcasts as local events, or a woodworking site labeling its project instructions as recipes. Both cases involve markup that is technically well-formed but fundamentally misrepresents what the page is actually about.
Violations of this kind fall under what Google calls a structured data issue, and repeated or severe cases can trigger a manual action that strips rich-result eligibility from a page, even though it does not directly affect that page’s ranking in standard web search. Keeping markup tightly matched to visible, accurate page content, a full breakdown of which sits in Google’s structured data guidelines, is the simplest way to avoid this entirely.
Required vs. Recommended Properties: Why More Isn’t Always Better
Every structured data type has a mix of required and recommended properties, and the distinction matters more than most implementations reflect. Required properties are the baseline: a schema item missing even one required property is not eligible for rich result display at all, regardless of how complete the rest of the markup is.
Recommended properties, by contrast, generally improve the quality and competitiveness of a result without being strictly necessary for eligibility. The instinct to add every possible recommended property, though, can backfire if it comes at the cost of accuracy.
Google is explicit about this trade-off: it is better to supply fewer, complete, and accurate recommended properties than to pack in every possible field with data that is poorly formed or unreliable. A job posting with an honest, explicitly stated salary outperforms one stuffed with extra fields but missing that core detail users actually care about.
The same logic applies broadly, since quality and accuracy consistently outweigh sheer completeness in how these results are evaluated. Treating the required fields as the floor, and every additional field as optional polish, keeps markup both eligible and genuinely useful.
What Validation Actually Checks—and What It Misses
Passing Google’s Rich Results Test feels like confirmation that everything is correct, but the tool only verifies part of the picture. It checks technical guidelines: whether the format is supported, whether required properties are present, and whether the syntax parses correctly.
It cannot check whether the content is accurate or genuinely representative of the page, since Google classifies those as quality guidelines that automated tools aren’t built to catch. A page can pass validation with a perfect score and still lose rich-result eligibility over a quality issue the test never evaluated.
Two other tools round out a proper validation workflow. The URL Inspection tool in Search Console shows how Google actually rendered a live page, which catches templating or deployment issues the Rich Results Test alone might miss during development.
The Rich Result status reports, also in Search Console, track validity across a site over time and flag pages where markup has broken after a theme update, plugin change, or migration. Running all three, rather than relying on a single pre-launch check, is the closest thing to genuine ongoing validation that currently exists.
More Structured Data Misconceptions Worth Retiring
A handful of other misconceptions persist even among experienced site owners:
- “Structured data is a ranking factor.” It is not. It affects eligibility for enhanced display, not organic ranking position.
- “JSON-LD is required.” It is recommended, but Microdata and RDFa are equally valid formats as long as the markup is correct.
- “Every schema.org property is supported.” Google only supports specific properties documented for each feature; schema.org includes many attributes Google simply ignores.
- “Duplicate pages only need markup on the canonical version.” Google recommends applying the same structured data to every duplicate, not just the canonical page.
- “More schema types automatically mean more visibility.” Markup only helps if it reflects a genuine, distinct part of the page; adding unrelated types dilutes relevance rather than expanding it.
Each of these misconceptions shares a root cause: treating structured data as a checklist item rather than an accurate technical description of a page. Once that shift happens, from decoration to description, most implementation mistakes become obvious on their own. Markup should follow what is genuinely true and visible on a page, not what might unlock an additional search feature. That discipline is also what keeps a site safe as Google continues to reshape which features exist at all.
How to Implement Structured Data the Right Way
With the misconceptions cleared up, a practical implementation approach comes down to a short sequence:
- Choose structured data types that reflect content genuinely present and visible on the page, not types chosen purely to chase a rich result.
- Include every required property for that type, and prioritize accuracy over volume for recommended properties.
- Use JSON-LD where possible, since Google recommends it as the easiest format to implement and maintain at scale.
- Validate with the Rich Results Test during development, then confirm with the URL Inspection tool after deployment.
- Monitor the Rich Result status reports in Search Console on an ongoing basis, not just at launch.
- Revisit older markup periodically, since Google continues to narrow or retire specific rich result features over time.
Most WordPress sites running Rank Math or a similar plugin can automate steps one through three for common content types without writing raw JSON-LD by hand. The remaining steps, validation and ongoing monitoring, are where most sites fall short, since markup that was correct at launch can break silently after a theme update or content edit. Building a recurring check into a monthly or quarterly SEO routine catches these breaks before they affect rich-result eligibility.
The Bottom Line on Structured Data
Structured data does real, measurable work: it helps Google understand a page accurately and makes that page eligible for enhanced display formats that can meaningfully improve click-through rates. What it cannot do is guarantee a rich result appears, promise a feature will exist indefinitely, or substitute for content that is genuinely visible and accurate on the page.
The FAQ rich result deprecation proves that even flawless, long-standing implementations can lose their visual payoff overnight while the underlying schema stays completely valid. Treating structured data as an honest technical description, not a guaranteed shortcut to more visibility, is what keeps an implementation useful no matter which features Google keeps.
Frequently Asked Questions
What is structured data?
Structured data is a standardized code format, usually JSON-LD, that labels the specific pieces of information on a page, such as a recipe’s ingredients or a product’s price, so search engines can parse them precisely. It sits in the page’s code and describes content that also needs to be visible to a normal reader. Most Search structured data follows schema.org vocabulary, though Google only supports specific properties within it.
Does structured data improve Google rankings?
No. Structured data affects a page’s eligibility for enhanced display formats called rich results, not its position in standard search rankings. A page with excellent structured data but weak content will not outrank a page with strong content and no markup at all. Ranking and rich-result eligibility are evaluated separately.
Does adding structured data guarantee a rich result?
No, and Google states this explicitly in its own documentation. Structured data enables a page to be considered for a rich result, but Google’s algorithm still decides, per search and per user, whether that format actually serves them best. Even flawless, fully validated markup can result in a standard text listing instead.
Why did my rich result disappear even though my markup is still valid?
Google periodically restricts or fully retires specific rich result features, independent of whether a site’s markup remains technically correct. The FAQ rich result is the clearest recent example: Google fully deprecated it in May 2026 after years of narrowing eligibility, even though FAQPage schema itself was never deprecated. If a rich result disappears site-wide with no warning, check Google’s structured data documentation for a deprecation notice before assuming there’s an error in your code.
Is FAQ schema still worth using in 2026?
The Google SERP dropdown that FAQ schema used to trigger is gone as of May 2026, so it no longer functions as a rich-result visibility tactic. The schema type itself remains valid and won’t cause errors, and genuinely useful FAQ content can still support on-page clarity, internal linking, and how other search engines or AI systems parse a page. Adding FAQ schema purely to chase the old SERP feature, however, no longer makes sense.
What’s the difference between structured data eligibility and Google guaranteeing a result?
Eligibility means a page meets the technical and quality requirements needed to be considered for a rich result. A guarantee would mean that result always appears, which Google explicitly does not promise, since its ranking systems weigh personalization, device, and query context before deciding which format to show. Meeting every guideline makes a rich result possible, not automatic.
Can I mark up content that isn’t visible on the page?
No. Google’s structured data guidelines specifically prohibit marking up information that isn’t visible to a reader of the page, even if that information happens to be accurate. If JSON-LD describes a performer, price, or rating, that same detail needs to appear somewhere in the page’s visible content, not only in the script tag.
What happens if my structured data doesn’t match my visible content?
Mismatched markup is treated as a structured data issue under Google’s guidelines and can result in a manual action, which removes a page’s eligibility for rich results without directly affecting its ranking in standard search. Google gives specific examples of this kind of violation, such as a streaming site labeling broadcasts as local events. Keeping markup tightly aligned with visible, accurate content avoids this risk entirely.
What’s the difference between required and recommended properties?
Required properties are the minimum needed for a schema item to be eligible for rich result display at all; missing even one disqualifies the entire item. Recommended properties are optional additions that can improve the quality and competitiveness of a result once eligibility is already met. Google explicitly advises supplying fewer, accurate recommended properties over many incomplete or unreliable ones.
Does the Rich Results Test guarantee my page is fully compliant?
No. The Rich Results Test checks technical guidelines, such as valid syntax and the presence of required properties, but it cannot evaluate quality guidelines like whether markup accurately represents the page’s visible content. A page can pass the test perfectly and still be ineligible for a rich result over a quality issue the tool was never designed to catch.
What other tools should I use to validate structured data?
The URL Inspection tool in Search Console shows how Google actually rendered a live page, which catches deployment issues the Rich Results Test can miss during development. The Rich Result status reports track validity across an entire site over time and flag pages where markup has broken after a template or plugin change. Using both alongside the Rich Results Test gives a more complete validation picture.
Is JSON-LD required, or can I use another format?
JSON-LD is Google’s recommended format because it’s the easiest to implement and maintain at scale, but Microdata and RDFa are equally valid as long as the markup is correct and complete. Most WordPress SEO plugins, including Rank Math, generate JSON-LD by default for supported content types. Switching formats on an already-working implementation generally isn’t necessary.
Do I need structured data on every duplicate version of a page?
Yes. Google recommends placing the same structured data on every duplicate of a page, not only on the canonical version, since Google may still crawl and evaluate the duplicates independently. Leaving markup off duplicate pages can create inconsistent eligibility across otherwise identical content, particularly on large ecommerce or travel booking sites with many near-duplicate URLs.
Can too much structured data hurt a page?
Structured data itself doesn’t directly harm a page, but marking up types that don’t genuinely reflect distinct, visible content on the page dilutes relevance rather than expanding it. Google’s guidelines specifically warn against irrelevant or misleading markup, such as labeling unrelated content just to gain access to more search features. More schema is only useful when each type describes something real and specific to that page.
Does structured data help with AI Overviews or AI search results?
Google’s own generative AI guidance states that no special schema.org markup is required for AI Overviews or AI Mode specifically. Well-structured, clearly labeled content, including but not limited to schema markup, generally makes it easier for both traditional crawlers and AI systems to parse a page accurately. Treating structured data as a guaranteed AI-visibility lever isn’t currently supported by Google’s own documentation.
How often should I re-check structured data for issues?
A quarterly review is reasonable for most sites, checking the Rich Result status reports in Search Console for pages that have lost validity. Immediately after any theme update, plugin change, or major content migration is also a critical time to re-validate, since these are the most common causes of markup breaking silently. Sites with frequent content changes may benefit from monthly spot checks instead.
Can Rank Math generate structured data automatically?
Yes, Rank Math generates JSON-LD structured data automatically for many common content types, including articles, FAQs, breadcrumbs, and local business information, based on settings configured in the plugin. More specialized types not covered by the plugin’s built-in schema generator typically require custom JSON-LD added manually or through a code snippet. Validating the plugin’s output with the Rich Results Test is still worthwhile after major updates.
