To validate structured data, test it in two places: Google's Rich Results Test to confirm your page is eligible for rich results, and the Schema Markup Validator at validator.schema.org to check that your markup is technically correct against the Schema.org vocabulary. The first tells you what Google will do with your markup; the second tells you whether the markup itself is valid. You need both, because a page can pass one and fail the other. This guide walks through how to use each tool and the errors they catch most often.
The two tools and what each is for
These tools answer different questions. The Rich Results Test renders your page the way Googlebot does, extracts the structured data, and reports which rich result types the page qualifies for — FAQ, breadcrumb, product, and so on. If a type you expect is missing, this tool tells you why. It is the right tool when your goal is a specific search feature.
The Schema Markup Validator is stricter about the vocabulary itself. It does not care whether Google supports a type; it checks that your properties exist on the type you declared, that values are the right shape, and that nested objects are well-formed. Use it when you are marking up anything beyond Google's supported feature set — for AI assistants and other parsers that read raw Schema.org, general validity matters more than Google eligibility. If JSON-LD is still new to you, start with our practical guide to JSON-LD and Schema.org.
Errors versus warnings — and why the difference matters
Both tools separate errors from warnings, and confusing the two wastes hours. An error means a required property is missing or malformed, and the item is not eligible for the rich result — you must fix it. A warning means a recommended property is absent; the item still qualifies, but adding the property improves how it is presented.
The practical rule: fix every error before you ship, and treat warnings as a prioritized backlog. A Product missing price is an error — no shopping result. A Product missing aggregateRating is a warning — it still shows, just without stars. Chasing every warning to zero before launch is a common way to delay a perfectly valid deployment.
The mistakes these tools catch most often
A handful of errors account for most failures. The biggest is a mismatch between markup and visible content: you declare a review or a price in JSON-LD that a user cannot see anywhere on the page. Google treats this as spam and can apply a manual action. The markup must describe what is actually on the page.
Close behind are wrong data types — a date written as free text instead of ISO 8601, a price as "€20" instead of a number with a separate currency field, or a URL that is relative when an absolute one is required. Then there are missing required properties, like an Article without a headline, or a broken parent-child relationship where a nested object is malformed. Marking up content that is not really there is another frequent flag; if you are adding FAQ or How-To markup, our guide to FAQ and How-To schema covers exactly what has to be visible on the page.
How to build validation into your workflow
Validating once at launch and never again is how sites drift into broken markup. Templates change, plugins update, and a field that rendered valid JSON-LD last quarter can start emitting an empty value after a redesign. Re-test key templates after any change that touches the head or the content model.
For anything but a tiny site, do not click through the UI for every URL. Both Google's tools have programmatic equivalents, and the Schema.org validator can be run in a pipeline, so you can test a sample of URLs per template on every deploy and fail the build when errors appear. Pair that with Search Console's enhancement reports, which flag structured-data errors across your whole property over time rather than one URL at a time. If you are marking up articles specifically so AI tools attribute them correctly, our guide on Article and BlogPosting schema shows which properties matter most.
Structured data only helps when it is valid, matches your visible content, and stays that way through every redesign. The fastest way to catch markup that has silently broken across many pages is to scan the whole site at once — run the CheckMy.site scanner to find pages where your schema is missing, malformed, or no longer matches what visitors and AI assistants actually see.