Structured data validation
Structured data validation is checking that your markup parses, conforms to schema.org, and contains the properties consuming systems expect. Two tools do different jobs: Google's Rich Results Test reports eligibility for Google's own features, while the Schema Markup Validator checks schema.org conformance generally. A page can fail the first and still be perfectly good input for an AI retrieval system.
Two tools, two questions
| Tool | Question it answers |
|---|---|
| Rich Results Test | Is this page eligible for a specific Google rich result? |
| Schema Markup Validator | Is this markup valid schema.org? |
| Search Console structured data reports | Is Google finding errors at scale across the live site? |
The distinction matters more since Google narrowed its rich-result surface. additionalProperty is valid schema.org, is the correct place for typed specification values, and is not consumed by Google's Product rich results. The Rich Results Test will not praise you for it. It is still the cleanest way to hand a model a typed, unit-bearing fact.
So do not let Google's eligibility checker define your markup strategy. It answers a narrower question than the one you are asking.
What validation does not catch
Every meaningful failure mode in catalog markup passes validation.
- Wrong values.
"value": 480where the product is 240 V is syntactically perfect. - Markup that disagrees with the page. A price in JSON-LD that does not match the price rendered to the user. Google's own policies treat this as a violation, and it also destroys trust in everything else you assert.
- Markup injected client-side. The validator runs JavaScript. Most AI crawlers do not. Markup that passes in the tool can be entirely absent from what a crawler receives, which is the single most common false clean bill of health.
- Inconsistent property naming. "Input power," "Wattage," and "Power (W)" used across a catalog for one concept is valid and reproduces the free-text problem inside your structured data.
Which is why validation is a floor, not a quality measure.
Validating a 400,000-SKU catalog
Nobody pastes URLs into a tool at that scale. The workable approach is three layers:
At the source. Enforce type, unit, and allowed values in the PIM with data validation rules, so a wrong value cannot be published. This is where accuracy is actually won.
At build or deploy. Extract JSON-LD from a sample of rendered pages per template and assert programmatically: block present, required properties non-empty, price matches the source of truth, units present on numeric values. Templates break silently during releases and this is what catches it.
In production. Search Console structured data reports for Google-side errors, plus periodic fetches of live URLs without JavaScript to confirm the markup is actually in the served HTML.
That last check is the one teams skip and the one that most often turns out to be the problem. See server-side rendering.
Frequently asked questions
What is the difference between the Rich Results Test and the Schema Markup Validator?
The Rich Results Test checks whether a page is eligible for specific Google rich results, so it only evaluates what Google consumes. The Schema Markup Validator checks whether markup is valid schema.org generally. Valid, useful markup can pass the second and be ignored by the first.
Does valid structured data mean my product data is good?
No. Validation checks syntax and shape, not truth. Wrong values, markup that contradicts the visible page, and inconsistent property names across a catalog all pass validation cleanly while doing real damage to how systems interpret your products.
Why does my markup validate but not appear to AI crawlers?
Because validation tools execute JavaScript and most AI crawlers do not. If your JSON-LD is injected client-side it will validate perfectly in the tool and be completely absent from the HTML an AI crawler receives. Fetch the page without JavaScript to check.
How do you validate structured data across a large catalog?
Enforce types, units and allowed values in the PIM so bad data cannot be published, add automated assertions on rendered pages per template in your build or deploy pipeline, and monitor Search Console reports plus periodic JavaScript-free fetches of live URLs.