Schema Validation vs Rich Results Eligibility: Why Perfectly Valid JSON-LD Can Still Fail Google's Rich Results Test

Schema markup that's syntactically perfect JSON-LD can still fail to produce rich results — because "valid" and "eligible" are two completely different things, and the testing tools that check each are also different

A previous article covered which schema types produce rich results (vs. which are indexing-only, informational, with no visual SERP impact). This article addresses the testing/validation layer: how to verify schema is correctly formatted (valid), separately from verifying it meets the additional, type-specific requirements for rich-result eligibility — and why passing one check doesn't guarantee passing the other.

Two different kinds of "checking," using different tools

1. Schema validity checking — does the JSON-LD (or microdata/RDFa) conform to the Schema.org vocabulary's syntax rules: correct property names, correctly-typed values (a Person's name should be a string, not an object; a Recipe's recipeIngredient should be an array, etc.), properly-formed JSON (no syntax errors — missing commas, unclosed brackets).

Tools for validity: Schema.org's own validator, and general-purpose structured-data linters — these check "is this valid Schema.org markup," independent of whether any particular search engine does anything with this specific type/combination of properties.

2. Rich-result eligibility checking — does this markup meet the additional, Google-specific (or other search-engine-specific) requirements for that markup type to be considered for a specific rich-result feature.

Tool for this: Google's Rich Results Test — this tool checks not just "is this valid schema," but "does this markup, for the types Google has rich-result features for, include the required and recommended properties Google's rich-result eligibility criteria specify" — and explicitly distinguishes errors (missing required properties — eligibility-blocking) from warnings (missing recommended properties — not eligibility-blocking, but potentially affecting how the rich result appears/how rich it is).

Why valid schema can still fail Rich Results Test

Example: Recipe schema — Schema.org's general Recipe type has many optional properties (recipeIngredient, recipeInstructions, nutrition, cookTime, prepTime, recipeYield, aggregateRating, and many more) — Recipe schema with just name and author would be perfectly valid (a Recipe type with some of its optional properties populated and others omitted is not a syntax error) — but Google's Rich Results eligibility for Recipe rich results requires specific properties (in addition to name) — commonly including things like image, and depending on the specific recipe rich-result features being targeted, potentially recipeIngredient, recipeInstructions, and others.

The Rich Results Test would show: no errors (the markup is valid Recipe schema) — but likely "missing field 'image' (required for [specific rich result feature])" style messages, indicating that while the markup is valid, it's not yet eligible for the specific rich-result appearance being checked against.

The distinction in practice: "my schema validates with no errors on a general schema validator" and "my schema is eligible for [specific] rich results according to Google's Rich Results Test" are different statements, and only the second directly addresses "will this produce a rich result in Google search."

Common validation/eligibility gaps

Missing image on types that require it for rich results: several rich-result types (Recipe, Product, and others) have image as a required field for rich-result eligibility, even though image is often technically optional in the general Schema.org definition of that type — markup created without specifically checking the rich-result-eligibility requirements (vs. just "what does Schema.org define for this type") commonly omits properties that are technically optional (per Schema.org) but eligibility-required (per Google's specific rich-result criteria for that type).

aggregateRating/review requiring underlying genuine reviews: as touched on in the previous schema-types article — AggregateRating schema that doesn't correspond to genuine, user-visible reviews/ratings on the page violates Google's structured-data guidelines (which explicitly prohibit markup that doesn't reflect what's actually present/verifiable on the page) — this isn't something a Rich Results Test necessarily flags as an "error" in the same way a missing required field would be (the Test primarily checks structural/field-presence criteria, not "does this data genuinely correspond to visible page content") — but violating this guideline can result in manual actions (a different, more severe consequence than simply "not eligible for rich results") — illustrating that *passing Rich Results Test (structural eligibility) doesn't guarantee compliance with all relevant structured-data guidelines (some of which relate to content accuracy/correspondence, not just markup structure).

Multiple/conflicting schema on the same page: a page with several different schema blocks (e.g., Organization and WebSite and BreadcrumbList and an Article) — each individually valid — but potential issues if, for instance, multiple Article-type schemas exist for what's actually a single article (perhaps from different plugins/systems each adding their own schema, unaware of each other) — Rich Results Test, run against the full page, would show each detected schema block — reviewing this output for unintended duplication/conflicts (not just checking whether each individual block, in isolation, is valid) is part of thorough testing, particularly for sites using multiple plugins/systems that each might independently add schema.

Testing workflow: validate, then check eligibility, then check live results

Step 1 — Syntax/structure validation: confirm the JSON-LD is well-formed (no JSON syntax errors) and uses correctly-named Schema.org properties for the intended type(s).

Step 2 — Rich Results Test (or equivalent for other search engines): for each schema type intended to produce a specific rich result, check Google's (or the relevant search engine's) eligibility criteria — addressing any "errors" (eligibility-blocking) and considering "warnings" (optional but recommended, potentially affecting richness/appearance of the result if eligible).

Step 3 — After deployment, monitor actual appearance in search results / Search Console's "Enhancements" reports: passing Rich Results Test indicates eligibility — it does not guarantee the rich result will actually appear for any given query/page — eligibility is a prerequisite, not a guarantee — actual appearance also depends on Google's broader assessment of whether showing this rich result for this page, for whatever queries might be relevant, serves users well — eligible-but-not-displaying is a possible, not uncommon, outcome, distinct from "ineligible" (which Rich Results Test would have flagged).

How to use the Schema Generator on sadiqbd.com

1. Generate schema for your intended type — the tool's core function, producing valid JSON-LD
2. Before deploying: run the generated markup through Google's Rich Results Test specifically (not just a general schema validator) — checking for any "required field missing" errors specific to the rich-result type you're targeting, beyond what general validity checking alone would reveal
3. For rating/review-related schema: verify the underlying page genuinely displays the reviews/ratings the schema represents — this correspondence isn't something Rich Results Test structurally checks, but is part of broader structured-data guideline compliance
4. After deployment: monitor Search Console's relevant "Enhancement" reports (for the specific schema type) over time — eligibility (confirmed pre-deployment via Rich Results Test) is the starting point; actual rich-result appearance/performance is observed post-deployment, separately

Frequently Asked Questions

If Rich Results Test shows only "warnings" (no errors), does that mean the rich result will definitely appear? No — "no errors" means the markup meets the eligibility requirements for Google to consider this page for the relevant rich result — it does not guarantee Google will, in fact, display that rich result for any/every relevant query. Warnings (missing recommended, non-required fields) might affect how rich/complete the result appears, if/when displayed — but the presence of only warnings (zero errors) reflects "eligible," not "guaranteed to display" — the actual display decision involves additional factors beyond what Rich Results Test evaluates.

Do I need to re-run Rich Results Test every time I update content on a page with existing schema? If the schema markup itself hasn't changed (only the page's visible content has, in ways unrelated to the schema's properties) — re-testing isn't strictly necessary from a pure markup-validity perspective. However, if content changes affect what the schema represents (e.g., a Product's price changes, and the schema's price property should be updated to match — or a Recipe's ingredients change, and recipeIngredient should reflect this) — ensuring the schema continues to accurately reflect the current page content is part of ongoing maintenance, separate from "does the markup itself still validate" (which, if the schema block wasn't touched, would presumably still validate the same as before — but might now be inaccurate, which is a different concern from validity, relating back to the content-correspondence guideline-compliance point made above).

Is the Schema Generator free? Yes — completely free, no sign-up required.

Try the Schema Generator free at sadiqbd.com — generate valid JSON-LD structured data for any schema type, ready for Rich Results testing.