The short version
- The Rich Results Test checks Google’s specific requirements. The Schema Markup Validator checks the vocabulary itself. You need both.
- Search Console enhancement reports are the only tool that checks your whole site rather than one URL.
- Markup can be syntactically valid and still ineligible for rich results because a required property is missing.
- Test one page per template, not every page. Markup breaks at the template level.
Structured data is generated by templates and plugins, never checked, and then silently broken by an unrelated change six months later. The tooling to prevent that is free and takes minutes, and the main obstacle is that the three tools look similar enough that people use one and assume they are covered.
The three tools
The distinction between the first two matters more than it appears. The Rich Results Test only reports on types Google supports for rich results, so perfectly valid markup for an unsupported type shows as nothing found — which reads like an error and is not. Conversely, markup can be valid Schema.org vocabulary and still miss a property Google requires for eligibility.
A workflow that catches real problems
- Pick one URL per template — one product page, one article, one category page. Not every page; markup does not vary within a template.
- Run each through the Rich Results Test. Fix anything reported as an error; warnings are recommended properties and usually worth adding.
- Run the same URLs through the Schema Markup Validator to catch vocabulary problems Google’s tool does not flag.
- Check Search Console enhancement reports monthly. This is the only view that catches a template change breaking markup across thousands of pages.
- Re-test after any template, theme or plugin change. That is when markup breaks, and nothing will tell you unless you look.
The failures these tools catch
- Missing required properties. Valid JSON-LD that omits a property Google requires for eligibility — common and invisible without testing.
- Markup describing content that is not on the page. A policy violation, not a shortcut, and a real risk.
- Duplicate or conflicting markup from two plugins both emitting an
Organizationblock with different values. - Broken output after a change. A template edit that leaves a field empty or emits malformed JSON.
- Stale data. Prices, availability or dates in markup that no longer match the visible page.
Catching breakage automatically
Manual testing catches problems you go looking for. Most structured data breakage is silent and nobody goes looking, so the higher-value setup is automatic. The enhancement reports in Search Console are the free version of this — they surface errors across your indexed pages and will tell you when a template change has broken markup at scale.
If you control the codebase you can go further and validate in CI. Emitting your structured data from code means it can be snapshot-tested like anything else, so a refactor that drops a required property fails the build rather than reaching production. That is the strongest argument for treating SEO markup as code rather than configuration — see plugin vs hand-coded SEO.
Whichever route you take, test one page per template rather than sampling randomly. Markup is generated by templates, so a random sample of fifty pages tells you about the same three templates fifty times while missing the one template you have never checked. Enumerate your templates, test one representative page of each, and you have covered the entire site in a few minutes.
Validation is the step, not the markup
Adding structured data is easy and most sites have some. Markup that does not validate does nothing at all — it is not partially credited. The value is entirely in the checking, which is the part that gets skipped because the markup "looks fine" in the page source.