Schema.org vs. Google Rich Results: Why Valid JSON-LD Doesn’t Guarantee Display

A developer writes the JSON-LD carefully. Every required property is present. The Schema Markup Validator shows green. Google’s Rich Results Test even reports the page as eligible for a supported feature. The team ships it. Weeks later, the SERP still looks like every other plain blue result.

This is the structured-data paradox most engineering teams eventually run into. The markup is technically correct, the tools say it is fine, and yet the visible rich result — the stars, the FAQs, the price, the breadcrumb trail — never appears.

The confusion is almost always caused by collapsing three very different concepts into one: Schema.org validity, Google eligibility, and actual SERP display. These are separate layers with separate rules, and debugging missing rich results requires knowing which layer has the real problem.

Eliminate syntax mistakes first. Use the CodeAva Schema JSON-LD Generator to produce clean, structured JSON-LD so you can debug the real reason rich results are missing — not a stray comma.

Schema.org vs. Google Search: vocabulary vs. product

Schema.org is a shared, open vocabulary maintained by a community of search engines and web stakeholders. It defines entity types (Article, Product, Event, Organization, Recipe, Person, and many more) and the properties that describe them. Its job is to give the web a common way to express meaning.

Google Search is a private product built by Google. It chooses which structured-data features it supports, how to render them, and when to show them. Google’s feature set is a curated subset of the Schema.org vocabulary, with additional feature-specific requirements on top.

These two things are not the same.

• A type existing in Schema.org does not automatically mean Google will use it for a visible rich result.
• A property being valid in Schema.org does not mean Google requires or rewards it for a specific rich result.
• Schema.org markup can still help search engines understand your content even when it does not map to a visible SERP feature.

Treating Schema.org and Google Search as the same thing is the single most common source of confusion when rich results do not appear.

Eligible is not guaranteed: the single most important concept

When debugging missing rich results, the first reframe you need is this:

• Valid means the markup parses correctly and follows Schema.org conventions.
• Eligible means the markup satisfies the requirements for a Google-supported feature and could qualify for display.
• Showndepends on Google’s final decision in real search results, which includes many signals beyond markup.

Keep this hierarchy in mind for the rest of this guide. Every other reason rich results go missing sits inside one of these three layers.

Reason 1: Google only supports certain rich-result types

Google publishes a defined list of structured-data features for Search — Product, Recipe, Event, Article, JobPosting, BreadcrumbList, Organization, and others. Each has its own requirements, recommended properties, and content guidelines.

A Schema.org type that is not in that list can still be valid, but it will not produce a visible rich result on its own. The markup is not wrong — it simply does not map to a feature Google renders in its interface.

This is why the Rich Results Test is organized around supported features, not around every Schema.org type. A page can have perfectly valid JSON-LD that the Rich Results Test does not treat as eligible for anything, because there is no corresponding supported feature for that type.

“Unsupported by Google for a rich result” is not the same as “useless.” Well-modeled structured data helps search engines understand entities and relationships on your pages regardless of whether it triggers a visible SERP treatment.

Reason 2: visible-content mismatch and hidden markup

Google’s guidelines consistently require that structured data describe content users can actually find on the page. Marking up information that is missing, misleading, or invisible to visitors creates a compliance problem, even when the JSON-LD itself is perfectly formatted.

A concrete, common failure mode:

1. A page has FAQPage JSON-LD injected into the <head>.
2. The body of the page contains no visible FAQ content — no question headings, no expandable answers, nothing a user can read.
3. The markup validates cleanly. The Rich Results Test shows eligibility.
4. Google still does not show the FAQ rich result — and if patterns like this are widespread on the site, it may be flagged as a spam signal.

The same pattern applies to Product schema without visible prices, Review schema without visible reviews, Recipe schema without a visible recipe, and so on. The rule of thumb is simple: if a human cannot see it on the page, do not claim it in structured data.

Reason 3: the Rich Results Test cannot catch every real-world problem

Testing tools are excellent at what they are designed for: parsing issues, missing required properties, malformed nesting, and supported-feature eligibility. They are not designed to simulate every quality, trust, indexing, or policy-related decision Google makes in production.

A page can pass the Rich Results Test and still miss rich-result display because of issues that no syntax tool can detect:

• Spammy markup usage across the site, such as repeated FAQ or Review markup that does not match visible content.
• Manual actions applied to the site or to structured-data usage specifically.
• Unsupported feature assumptions, where the team is hoping for a SERP treatment that Google no longer shows for the relevant query or content type.
• Indexing problems, including pages that are not indexed, pages canonicalized to a different URL, or pages served from a URL Google has not chosen as canonical.
• Content-quality or trust issues that are beyond markup syntax: thin content, scraped content, or a site-level reputation that makes Google cautious about enhanced presentations.

If the Rich Results Test is green and the page is still missing rich results, the problem is almost never syntax. It is somewhere in this list.

Reason 4: query context and SERP choice

Google decides how to present results on a per-query basis. Not every query produces the same treatment, even for the same URL. Device, location, search history, intent classification, and the rest of the results on the page all feed into which features are shown.

Practical consequences:

• A page with perfectly valid, eligible Product markup may not show rich results for all queries that land on it.
• Mobile SERPs and desktop SERPs can display different feature sets for the same URL.
• A feature that appears on one day’s search may not appear the next, because Google is choosing the best presentation for the current query context.

This is not randomness. It is Google choosing the result layout it believes best matches intent. Treating rich-result display as context-sensitive, rather than guaranteed, is the correct mental model.

Reason 5: feature-specific restrictions changed the landscape

Some rich-result features have become more restricted over time as Google refined which content types benefit from enhanced presentation. FAQ rich results, in particular, are now shown in much narrower circumstances than they used to be — the feature has not disappeared, but the eligibility envelope is smaller.

If a site that used to show FAQ snippets no longer does, the explanation is usually not broken JSON-LD. It is a change in which sites, content types, and queries qualify for the feature.

This matters for debugging:

• Do not assume “rich result missing” equals “markup broken.”
• Always check whether the feature is still broadly shown for your content category before chasing syntax issues.
• Feature-specific changes are published in Google’s developer documentation and in search-status updates.

Not every feature has been reduced, and structured data for many types still produces rich results reliably. But the assumption that whatever worked in a 2019 case study is still guaranteed in 2026 is the source of many “my FAQ snippet disappeared” debugging threads.

The debugging workflow that actually works

When rich results are missing and the markup is valid, follow this workflow in order. Each step eliminates a category of suspects so the real cause surfaces faster.

1. Confirm the page is indexable and indexed. A non-indexed page cannot earn rich results. Check robots rules, noindex tags, server responses, and Search Console coverage. See Discovered – Currently Not Indexed and Crawled – Currently Not Indexed for the common indexing causes.
2. Confirm the page is canonicalized as expected. If Google chose a different canonical, your structured data may be effectively invisible because the URL you tested is not the URL Google uses.
3. Validate the JSON-LD syntax. Use the Schema JSON-LD Generator to rebuild or audit the markup, then remove syntax from the list of suspects.
4. Check the Rich Results Test. Confirm the page is eligible for the specific supported feature you expect. If it is not eligible, the test will explain what is missing.
5. Confirm the marked-up content is visible. Every FAQ question, price, review, event detail, and so on should appear in the rendered page the same way it does in JSON-LD.
6. Review feature-specific Google guidelines. Each supported feature has its own content and policy rules on top of Schema.org requirements. Read them for the specific feature you are targeting.
7. Check Search Console. Look for enhancement reports, manual actions, and structured-data-specific issues. Valid-item trends over time are more informative than a single URL test.
8. Check whether the feature is still broadly shown. For categories affected by feature-specific restrictions (notably FAQ), confirm that the feature is currently available for your site or query type before assuming the markup is at fault.
9. Give Google time, then reassess. Rich-result indexing is not instantaneous. Give changes time to propagate, then recheck live queries and Search Console rather than relying on a single post-deploy test.

If you want an extra layer of eligibility-focused auditing, the Structured Data Validator & Rich Result Gap Checker highlights missing required and recommended properties for Google-focused rich-result types.

Common developer mistakes

The same anti-patterns show up again and again in rich-result debugging sessions. If any of these describe your current workflow, fix them before hunting for more exotic causes.

• Assuming “valid JSON-LD” means “guaranteed SERP treatment.” Validity is the floor, not the product decision.
• Using Schema.org types Google does not support for visible rich results and expecting a snippet anyway. Support is feature-specific and product-specific.
• Marking up content that users cannot actually see. If the page does not render the FAQ, the price, or the review, do not claim it in JSON-LD.
• Copying competitor schema without matching page content or quality. The markup on a trusted, content-rich page does not automatically produce the same result on a thin, duplicated, or low-trust page.
• Debugging only inside validators. Never checking indexing, canonicalization, or Search Console means you are debugging a small part of the actual system.
• Assuming FAQ or HowTo behavior from old screenshots. Feature-specific changes have redrawn the map for some types. Always confirm current eligibility, not historical eligibility.
• Injecting markup on pages that cannot earn enhanced presentation. Thin, duplicated, scraped, or low-trust pages rarely qualify for rich results regardless of how clean the structured data is.

Syntax vs. eligibility vs. display: a layered comparison

The table below summarises the four layers teams should be able to distinguish, what each actually proves, what it does not guarantee, and the best tool or check for that specific layer.

Remove syntax from the list of suspects

Most rich-result debugging sessions begin and end with arguments about nested objects, escaped quotes, and missing required properties. That is the easiest class of problem to eliminate, and eliminating it early lets the team focus on the harder variables: visibility, eligibility, indexing, and quality.

The CodeAva Schema JSON-LD Generator produces structured JSON-LD from form-based inputs for common types such as Article, Product, LocalBusiness, Event, JobPosting, Organization, FAQPage, BreadcrumbList, and WebPage. It removes formatting and nesting mistakes, surfaces local validation issues, and lets you export clean markup you can paste into your page or CMS.

For an extra layer of Google-focused gap analysis, the Structured Data Validator & Rich Result Gap Checker highlights missing required and recommended fields for rich-result-oriented types.

Neither tool — and no tool in the industry — can force Google to display a rich result or force support for a feature Google does not currently render. What a good generator does is remove syntax from the list of suspects so your team can debug the questions that actually determine display.

Syntax is the floor. Display is the prize.

Valid JSON-LD is table stakes. It is necessary, it is achievable, and it is the first thing any structured-data strategy should secure. But it is not the same thing as a rich result in live search.

Google rich results are a product decision layered on top of structured-data validity. That decision depends on feature support, guideline compliance, visible-content matching, indexability, canonicalization, quality signals, manual actions, and query context. Understanding this layering is what separates teams that chase stars from teams that actually earn them.

The practical workflow is straightforward: let tools handle the syntax so humans can focus on the content, eligibility, and quality side of the problem.

Start by generating clean, consistent markup with the CodeAva Schema JSON-LD Generator. Then, if rich results still do not appear, confirm your page is indexable and canonical (see Discovered – Currently Not Indexed and Crawled – Currently Not Indexed), walk through the debugging workflow above, and check the Rich Result Gap Checker for feature-specific gaps. The goal is to be the team that knows exactly which layer is failing, not the team that keeps re-validating the same JSON-LD and hoping.