Structured Data Testing Tools Compared

Google deprecated its original Structured Data Testing Tool in 2020, and the tools that replaced it split into two purposes that get conflated constantly: checking rich-result eligibility specifically, and checking broader schema.org compliance. Neither one alone gives the full picture, and most structured data debugging sessions in practice bounce between two or three tools rather than relying on a single one. Here's what each actually checks, and when to reach for which.

The Google Rich Results Test is Google's current primary tool, and it checks one specific thing: whether a page's structured data markup qualifies for one of Google's defined rich-result types (Article, Product, FAQ, HowTo, and the rest). It will flag missing required properties for a given rich-result type and confirm eligibility status. What it won't do is validate schema.org compliance more broadly — a schema markup block can be fully valid schema.org markup and still show no rich-result eligibility in this tool, simply because Google doesn't have a rich-result format defined for that type, or the site doesn't currently qualify (FAQ and HowTo being the clearest examples, covered in depth elsewhere in this series). Use this tool to answer "will this specific page qualify for a Google rich result," not "is this schema markup correct" in the broader schema.org sense.

Schema.org's own validator checks markup against the full schema.org vocabulary, independent of any single search engine's rich-result rules. This is the right tool for confirming your JSON-LD (or Microdata/RDFa) is syntactically correct and uses valid types and properties per the schema.org specification itself. It won't tell you anything about Google rich-result eligibility specifically — a page can validate perfectly here and still fail Google's narrower rich-result requirements, and vice versa in rare cases. Use this as the baseline correctness check, then layer Google's tool on top for rich-result-specific eligibility.

Search Console's Enhancements section reports structured data errors and warnings across your entire site, not just one page at a time — this is the tool for ongoing monitoring rather than one-off validation during development. It surfaces issues at scale (a template change that broke schema on thousands of pages, for instance) that testing individual URLs would take far too long to catch. The tradeoff: Search Console's crawl and reporting cycle isn't instant, so a fix you've just deployed won't show as resolved immediately — expect a lag of days before the report reflects current state. Use Rich Results Test and the Schema.org validator for the moment you deploy a change, and Search Console for the ongoing, site-wide check afterward.

Worth distinguishing two categories that get lumped together under "testing tools." A schema markup validator (the Schema.org validator, Google's Rich Results Test) checks structured data you've already written. A schema builder or schema generator is a different category entirely — a tool that helps you construct the JSON-LD in the first place, covered in more detail in the Person, Organization, and FAQ schema articles elsewhere in this series. The two are often used together in sequence: build with a schema builder, then immediately validate the output with a proper schema markup validator before deploying, since builder output is a starting point, not a guarantee of correctness.

Beyond Google's and schema.org's own tools, several third-party tools serve a similar validation function with different interfaces and additional features — bulk URL checking, historical tracking of schema changes, or side-by-side comparison against competitor pages' structured data. These are genuinely useful for agency or in-house workflows managing structured data across many pages or many client sites, where checking one URL at a time in Google's tool doesn't scale. They're not authoritative in the way Google's own tool is for rich-result eligibility specifically — treat third-party tool output as directionally useful, then confirm anything rich-result-critical in Google's Rich Results Test before treating it as settled.

For quick manual checks during development, viewing a page's rendered source (not just the initial HTML, given how much modern JSON-LD is injected client-side) and extracting the JSON-LD script block directly is often faster than round-tripping through an external tool for a small syntax check. Browser developer tools let you inspect the actual DOM after JavaScript execution, which matters specifically for JS-rendered sites where the schema might exist in source but never reach the rendered page Googlebot actually processes — a gap that no external testing tool checking your live URL will always catch cleanly, since some testing tools render JavaScript and some don't.

Every tool covered here validates syntax, structure, and (for Google's tool) rich-result eligibility. None of them verify that the content of your structured data is actually true. A Person schema with a fabricated sameAs array, an Organization schema with a name that doesn't match your actual legal or trading name, a Review schema with an inflated rating that doesn't reflect real reviews — all of these can pass every automated validator cleanly while being factually wrong. That's a distinction worth internalizing: automated testing tools catch "is this correctly formed," not "is this accurate," and the second question requires a manual check every time, particularly for the entity-disambiguation properties (sameAs, author, publisher) that carry the most weight for the reasons covered throughout this series.

For a new implementation: validate with the Schema.org validator first for baseline correctness, then Google's Rich Results Test for rich-result eligibility, then manually verify every URL in every sameAs array actually resolves and is accurate. For an existing site: monitor Search Console's structured data reports on a recurring schedule (monthly is reasonable for most sites, more frequent for large sites with frequent template changes), and re-run Rich Results Test on a representative sample of pages after any template, framework, or CMS migration — these are exactly the changes most likely to silently break structured data without any visible rendering issue on the page itself.