Structured Data Troubleshooting & Validation

Writing schema markup is the easy part. Knowing whether it’s actually correct, and what to do when it isn’t, is where most implementations go wrong. This guide covers the tools Google provides for checking structured data, what their results actually mean, and how to fix the errors you’ll run into most often.

What validation does and doesn’t guarantee

Valid schema is not the same as a guaranteed rich result. A page can pass every validation check and still never show a star rating, an event date, or any other enhanced search feature. Google is explicit about this distinction: structured data “enables a feature to be present, it does not guarantee that it will be present” (General structured data guidelines). Whether a rich result actually appears depends on additional factors Google weighs at query time, including the user’s device, location, and search history, none of which a validator can check for you.

So treat validation as clearing the floor, not hitting the ceiling. It confirms your markup won’t be rejected for a technical reason. It doesn’t confirm Google will choose to use it.

Using the Rich Results Test

The Rich Results Test is Google’s own tool for checking whether a page’s structured data qualifies for the rich result types Google supports. You can test a live URL or paste raw code directly.

What the results mean:

Result	What it means	What to do
Valid item detected, no issues	The markup meets Google's requirements for that rich result type	Nothing required, but review recommended (non-required) properties for a stronger result
Valid item, with warnings	Required properties are present, but recommended properties are missing	Optional fix, warnings don't block eligibility but weaker markup may compete less well
Invalid item, errors present	A required property is missing, malformed, or the wrong data type	Fix before Google will consider the page eligible for that rich result
No items detected	Google found no structured data on the page, or found a type it doesn't support for rich results	Confirm the JSON-LD script is present, loads correctly, and uses a type Google's Search Gallery documents

Because the Rich Results Test only validates schema.org types Google specifically supports for rich results, it will report “no items detected” for markup that is otherwise perfectly valid schema.org syntax but isn’t one of Google’s supported rich result types. That’s a different problem than broken code, and worth knowing the difference before you start debugging syntax that was never broken.

The tool also renders the page the way Google’s crawler would, including executing JavaScript, which matters if your schema is injected client-side rather than present in the initial HTML. If a “view source” of your page shows no JSON-LD but the Rich Results Test still finds it, that confirms Google is able to see dynamically injected markup, consistent with Google’s own documentation on JSON-LD and JavaScript. If the test also finds nothing, the injection itself is failing before Google ever sees it, which is a front-end bug to chase down rather than a schema problem.

Reading Search Console’s structured data reports

The Rich Results Test checks one URL at a time as of the moment you run it. Search Console’s Rich result status reports show you the aggregate picture across your whole site, based on Google’s most recent crawl and index of your pages, which is a different (and usually delayed) view than a live test.

Each report is organized by rich result type (Article, Product, and so on, for whichever types Google has found markup for on your site) and breaks pages into valid, valid with warnings, and invalid (error) groups. Clicking into an error group shows you the specific issue and the list of affected URLs, which is the fastest way to fix a templating bug affecting hundreds of pages at once instead of debugging one URL and assuming the fix applies everywhere.

After you fix a templating bug, use the “Validate fix” button inside the specific error group rather than waiting passively. It doesn’t force an instant recrawl of every affected URL, but it tells Google to prioritize reprocessing that set of pages and gives you a status you can check back on, which is a meaningfully faster loop than doing nothing and hoping the report updates on its own.

One practical note on timing: Google does not publish a fixed schedule for when a structured data fix will be reflected in Search Console. It depends on Google recrawling and reprocessing the page, which can take anywhere from a few days to longer depending on how often Google crawls that part of your site. There’s no reliable “it updates in exactly N days” number to plan around, and any post claiming otherwise is guessing at a precision Google doesn’t offer.

Common errors and real fixes

These are the errors that show up most often across schema implementations, in roughly the order you’re likely to hit them.

Syntax errors. A missing comma, an unclosed bracket, or a stray trailing comma in the JSON-LD block will invalidate the entire script, not just the property near the error. Run the block through a JSON validator before testing it against Google’s tools, since a syntax error will often produce a vague “no items detected” result rather than pointing at the exact character.

Missing required properties. Each schema type documents its own required and recommended properties on its Google Search Central page. Product schema, for example, requires specific properties depending on which rich result you’re targeting (review snippet vs. merchant listing). Check the documentation for the specific type you’re implementing rather than assuming all types share the same requirements, they don’t.

Type mismatches. A property that expects a URL (like image or url) needs an absolute URL string, not a relative path or a plain filename. A property that expects a Date needs ISO 8601 format (2026-07-01), not a human-readable date string. These errors are common because they pass a casual visual read of the code but fail strict parsing.

Relative vs. absolute URLs. Any URL-type property should be a full, absolute URL including the protocol (https://example.com/page, not /page or example.com/page). Relative URLs are a frequent cause of “invalid” results that look correct at a glance.

Date format errors. Beyond ISO 8601 formatting, a common mistake is putting a dateModified earlier than datePublished, or leaving dateModified static after editing a page, which doesn’t cause a validation error but undermines the freshness signal the property exists to provide.

Duplicate or conflicting schema blocks. It’s common on templated sites for a plugin, a theme, and a manually added script to each output their own JSON-LD for the same entity, sometimes with different values for the same property. Google doesn’t clearly document how it resolves conflicting duplicate markup on one page, so the safer approach is to find and remove the redundant source rather than assume Google will pick the correct one. Checking a page’s full rendered source for more than one application/ld+json script describing the same entity is a fast way to catch this.

Schema Markup Validator

The Schema Markup Validator, maintained by schema.org rather than Google, checks your markup against the full schema.org vocabulary rather than just the subset Google supports for rich results. Use it when you’re implementing a schema.org type that Google doesn’t have a rich result for (schema.org is a multi-vendor standard also used by Bing, Yahoo, and Yandex), or when you want to confirm your JSON-LD is syntactically and semantically correct independent of whether Google currently does anything visible with it. For anything you specifically want to show up as a Google rich result, start with the Rich Results Test since it reflects Google’s actual supported feature set; use the Schema Markup Validator as a secondary, broader check.

The two tools can disagree, and that’s expected rather than a bug in one of them: the Schema Markup Validator can report a page as fully valid schema.org markup while the Rich Results Test reports “no items detected,” simply because the type or property combination you used isn’t one Google currently builds a rich result around. Neither tool is wrong in that scenario, they’re answering different questions, “is this valid schema.org” versus “does Google do anything with this specific markup.”

Pre-deployment checklist

Before pushing new or changed structured data live:

• Run the exact page through the Rich Results Test, not just the JSON-LD snippet in isolation, since template context can break markup that looks fine on its own.
• Confirm every URL property is absolute, not relative.
• Confirm every date property is ISO 8601 and that dateModified actually reflects the last real edit.
• Confirm the schema describes content that is actually visible on the page. Markup describing content that doesn’t appear on the page is a policy violation, not just a technical error.
• If the change affects a template used across many pages, spot-check a sample of pages beyond the one you tested. A property populated by a template variable can be correct on one page and empty or malformed on another.

Conclusion

Validation tells you whether your markup meets Google’s technical bar, not whether it will produce a visible result, and not on a fixed timeline. Use the Rich Results Test for anything you want Google to treat as a rich result candidate, use Search Console’s reports to catch template-wide errors instead of debugging page by page, and treat any specific “time to reindex” number you see elsewhere as an estimate at best.