Structured Data Troubleshooting & Validation

Structured data can pass every validator and still never produce a rich result. That is not a bug in the validator; it is three different questions being answered by three different checks. The first is whether the markup is syntactically valid and uses Schema.org vocabulary correctly. The second is whether it satisfies Google’s requirements for a specific search feature that Google currently supports. The third is whether Google actually shows that feature for your page. Troubleshooting goes faster when you know which of the three you are looking at.

The three-stage validation model

Google’s general structured data guidelines state the gap between stages 2 and 3: “Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly according to the Rich Results Test” (structured data general guidelines). The same page explains that using structured data “enables a feature to be present, it does not guarantee that it will be present”, because Google tailors results by variables such as search history, location and device type.

Stage 1: valid markup

Schema.org is a shared vocabulary, maintained independently of any single search engine. A type can be perfectly valid Schema.org without Google using it for anything.

Use the Schema Markup Validator to check:

• the JSON parses (no trailing commas, unescaped quotes or broken brackets);
• every @type exists in Schema.org;
• properties belong to the types they are attached to;
• nested entities are typed where needed.

Google says all three formats (JSON-LD, Microdata and RDFa) “are equally fine for Google, as long as the markup is valid and properly implemented”, and in general recommends JSON-LD “if your site’s setup allows it” (introduction to structured data).

A stage 1 failure is a code problem: fix the syntax or the vocabulary before looking at anything else.

Stage 2: eligibility for a Google feature

Google supports rich results for a specific, documented list of types, and each has its own required and recommended properties; the type guides for Organization, Product, LocalBusiness, Article and BreadcrumbList markup list them. Google’s introduction to structured data states: “You must include all the required properties for an object to be eligible for appearance in Google Search with enhanced display” (introduction to structured data). It also advises supplying “fewer but complete and accurate recommended properties” rather than many badly formed ones.

The tools at this stage:

• Rich Results Test during development. It reports which Google features the page’s markup qualifies for and lists errors and warnings per feature.
• URL Inspection to confirm that Google found the structured data on the indexed version of the page.
• Rich result status reports in Search Console after deployment, which Google recommends for monitoring because markup “might break after deployment due to templating or serving issues”.

Eligibility also depends on guidelines that no tool fully checks. Google’s guidelines say the markup must represent the main content of the page, must not mark up content that is not visible to readers, and must not be misleading. A structured data manual action, according to the same guidelines, removes eligibility for rich results; Google states it “doesn’t affect how the page ranks in Google web search”.

Unsupported is not invalid

Features change. Google stopped showing the sitelinks search box on November 21, 2024, and its announcement said unsupported structured data “won’t cause issues in Search, and won’t trigger errors in Search Console reports” (Google’s 2024 sitelinks search box announcement). FAQ rich results stopped appearing in Google Search starting May 7, 2026, per Google’s documentation changelog (Google Search documentation updates). In both cases the Schema.org markup can still be valid at stage 1 while no longer mapping to any Google feature at stage 2. Leaving it in place is harmless; expecting a rich result from it is a mistake.

Stage 3: observed appearance

The only proof that a feature appears is seeing it. Two places to look:

• Search Console Performance report, Search appearance dimension. It lists rich result types that earned impressions, with clicks and impressions per type. If a type has never appeared there, the site has no recorded impressions for it in the report period.
• Live results, checked from different devices and locations, since Google tailors features by those variables. A single manual search is a sample of one.

When stage 2 passes and stage 3 shows nothing, Google’s guidelines list possible reasons: the markup may not represent the main content or may be misleading, it may be incorrect in a way the Rich Results Test could not catch, the marked-up content may be hidden from users, or the page may not meet the structured data guidelines, the feature’s own guidelines, Search Essentials or Google’s content policies.

A troubleshooting sequence

1. Confirm the feature still exists. Check Google’s documentation for the rich result type. If the documentation is gone or the changelog says the feature was removed, stop: there is nothing to fix.
2. Validate the syntax. Run the Schema Markup Validator. Fix parse errors first.
3. Run the Rich Results Test on the live URL. Look for the specific feature, not only for “valid”. Read every error for that feature.
4. Compare required properties with the documentation. Missing required properties make an item ineligible; missing recommended properties do not.
5. Check visibility. Is every marked-up value visible on the page? Prices, ratings, dates and names in markup should match what readers see.
6. Inspect the indexed page. URL Inspection shows whether Google saw the markup in the version it indexed. JavaScript-injected markup that fails to render can pass a local test and be missing in the index.
7. Read the rich result report. Errors that appear across many URLs point to a template problem.
8. Wait for recrawl after fixing, then check stage 3.
9. Check for a manual action if a previously appearing feature disappeared across the site.

Worked example: valid markup, no stars

Picture a site selling running shoes. Product pages carry Product markup with aggregateRating, and the owner expects star ratings in results.

• Stage 1: the Schema Markup Validator shows no errors.
• Stage 2: the Rich Results Test detects Product snippets and merchant listings as eligible, with a warning about a missing recommended property.
• Stage 3: the Performance report shows impressions for merchant listings but none for review snippets.

Inspection reveals the cause. The rating values come from an aggregation of reviews collected on another site. Google’s review snippet guidelines say “Don’t aggregate reviews or ratings from other websites” (review snippet documentation), a guideline the test tools cannot verify. The markup is valid and the feature is technically eligible in the test, but the content does not meet the guideline. The fix is to show and mark up only reviews collected on the site itself, or remove aggregateRating.

Errors and warnings

The Rich Results Test separates errors from warnings. Errors on required properties make the item ineligible for that feature. Warnings on recommended properties do not block eligibility, though Google says more recommended properties produce a higher quality result for users. Fix errors first; fix warnings when the property applies and you have accurate data for it. Do not fill a recommended property with placeholder or inaccurate values to clear a warning.

What to report to stakeholders

Write status in three separate lines, one per stage:

• “Product markup is valid Schema.org on 1,240 of 1,240 product pages checked.” (stage 1)
• “Rich Results Test shows merchant listing eligibility on the sampled URLs; Search Console reports 12 URLs with errors.” (stage 2)
• “Merchant listings recorded impressions in the last 28 days; review snippets did not.” (stage 3)

Combining them into “schema is working” hides which stage failed, and the fix for each stage belongs to a different owner: developers for stage 1, the SEO or content owner for stage 2 guidelines, and nobody can force stage 3.