Structured data testing tools each answer one question, and no tool answers all of them. The Rich Results Test reports whether Google can extract markup and whether it qualifies for a Google search feature. The Schema Markup Validator at validator.schema.org checks markup against the whole schema.org vocabulary. The JSON-LD Playground works on the layer beneath both. Search Console reports what Google actually parsed on live pages. Running the wrong one is why valid markup gets reported as broken and broken markup passes.
Google Rich Results Test
What it is for: confirming that Googlebot can fetch and render a page, that it finds the markup, and that the markup meets the requirements for a Google rich result type.
At search.google.com/test/rich-results, the tool accepts a live URL or a pasted code snippet and can test with the smartphone or desktop crawler. Because it renders the page the way Googlebot does, it executes JavaScript, which makes it the only one of these tools that sees markup injected client-side by a tag manager or a front-end framework. It also shows the rendered HTML and page loading issues, so a blocked resource or a script error that prevents the markup from ever existing shows up here.
Where it is blind: it only knows about types that map to a Google search feature. A correct Dataset node, or an Organization node full of knowsAbout and parentOrganization statements, may produce nothing in the results, and that silence means the type has no feature attached rather than that the markup is wrong. The reverse also holds: the tool does not validate against the schema.org vocabulary, so a misspelled property, or one used on a type that does not define it, can pass unremarked as long as the required fields for the detected feature are present.
A pass also means only that the markup meets the technical requirements for the named feature. Whether that feature appears is a separate decision Google makes per query, so the tool reports eligibility, never an outcome.
Schema Markup Validator (validator.schema.org)
What it is for: checking markup against the full schema.org vocabulary, independently of any search engine.
The validator parses JSON-LD, Microdata, and RDFa from a URL or a pasted snippet and lists every entity it finds with its properties, flagging types and properties absent from the vocabulary and values that do not match a property’s expected type. It is the tool that catches datePublised, a contactPoint value that is not a ContactPoint node, PostalAddress fields written directly on an Organization, and every other error the Rich Results Test has no opinion about. It is also the right tool for markup with no Google feature attached, which is most of an entity-focused graph.
Where it is blind: it says nothing about Google eligibility or about required and recommended properties for a rich result, and it does not execute JavaScript, so client-rendered markup has to be pasted in as a snippet. The vocabulary check is permissive by design, since schema.org expects extension and does not treat an unexpected value type as fatal, so warnings need reading rather than counting.
JSON-LD Playground
What it is for: the JSON-LD layer itself, one level below schema.org. At json-ld.org/playground/ a document can be expanded, compacted, flattened, framed, and converted to N-Quads.
This is the tool that shows what a @context actually resolves to. Expansion replaces every term with the full IRI it maps to, so a key that silently failed to resolve appears as a dropped key rather than a property. That one view diagnoses a class of problems: a typo in the context URL, a custom context that never defined the term in use, a key that looks like schema.org but is not in the vocabulary the context loads, @id values that are relative where they should be absolute. The N-Quads output converts the document to triples, and comparing the triple count to the properties written shows what was lost. Background on that conversion is in JSON-LD and RDF.
Where it is blind: it knows nothing about schema.org semantics and nothing about search engines. A document can expand cleanly, produce correct triples, and still describe an entity wrongly.
Search Console rich result status reports
What it is for: the only view of what Google actually extracted from live pages at scale, across a whole site, over time.
The other three tools test one page or one snippet on demand. Search Console reports what Googlebot found during real crawls. Each supported feature detected on the site gets its own enhancement report, listing valid items, warnings, and errors grouped by issue with example URLs, plus a validation flow that recrawls affected pages after a fix. The Unparsable structured data report collects markup that failed to parse at all, usually a syntax error, and is worth checking first because those items appear in no other report. URL Inspection adds a live test for a single URL and shows the enhancements detected on the indexed version, which distinguishes a problem that is already fixed from one that is not.
Where it is blind: it needs verified site ownership, covers only Google-supported features, and lags, since data appears after a crawl. It also reports detection rather than display, so a report full of valid items is not evidence that any feature is appearing in results.
The retired Structured Data Testing Tool
The Structured Data Testing Tool was Google’s general-purpose validator for years, checking markup against the schema.org vocabulary rather than only against Google’s features. Google announced in 2020 that it would be retired in favour of the Rich Results Test, and the codebase moved to schema.org, which launched the Schema Markup Validator at validator.schema.org from it in 2021.
Anyone still looking for the old tool wants one of two things. For vocabulary validation, including types Google has no feature for, the successor is the Schema Markup Validator, which behaves much as it did. For anything about Google features, the Rich Results Test is the only tool that reports on them.
Schema generators
Generators that produce a JSON-LD block from a form are a reasonable way to learn the shape of an unfamiliar type and a poor production process. A generator emits only what its template covers, it does not know the site’s @id convention, and it produces a standalone block per page rather than a graph with shared nodes, which is how sites end up with a separate Organization entity on every URL. Generate once, move the markup into the template that renders the page, and validate the result.
Validating at scale
Testing one page at a time does not scale past a small site. Two approaches do.
Crawler-based extraction. A crawler that parses application/ld+json from every page turns markup into a dataset: which types appear on which templates, how many distinct @id values exist for the organization, which articles still emit author as a string, which pages emit two conflicting nodes. Screaming Frog’s structured data validation does this against both the schema.org vocabulary and Google’s feature requirements, and other auditors offer comparable extraction. Even a crawl that dumps every block to a file, plus a script grouping nodes by @type and @id, finds the structural problems a page-by-page review misses.
CI checks against the vocabulary. Because schema.org publishes the vocabulary itself as RDF, a build step can verify markup against it rather than against a hand-written list of property names. Expand each block with a JSON-LD processor, load the triples into a graph, and assert two kinds of rule: that every property used is declared on the type it is used with, and that the site’s own requirements hold, for example that every Article has an author resolving to a Person with a name. SHACL is the standard language for the second kind, and the same graph answers one-off questions through SPARQL, such as listing every distinct Organization identifier across a crawl.
Which tool answers which question
| The question being asked | The tool that answers it |
|---|---|
| Is this JSON valid and does the context resolve? | JSON-LD Playground (expand the document) |
| Does every property I used exist on this type? | Schema Markup Validator |
| Can Googlebot see markup that JavaScript injects? | Rich Results Test |
| Is this page eligible for a Google rich result? | Rich Results Test |
| Why is a property being ignored entirely? | JSON-LD Playground, then Schema Markup Validator |
| What did Google actually parse across my site? | Search Console enhancement reports |
| Which pages have markup that failed to parse? | Search Console, Unparsable structured data report |
| Has my fix been picked up yet? | Search Console URL Inspection, live test and indexed version |
| Which templates emit which types? | Crawler-based extraction |
| Do my own markup rules hold on every page? | SHACL or SPARQL check in CI |
| What triples does this document produce? | JSON-LD Playground, N-Quads output |
| Is markup for a type Google has no feature for correct? | Schema Markup Validator |
For developers
The useful model is three layers, each with its own failure mode. The JSON-LD layer decides whether the document parses and whether terms resolve to IRIs; the Playground tests it. The vocabulary layer decides whether the statements are well formed schema.org; the Schema Markup Validator and a SHACL shape test it. The consumer layer decides whether a search engine does anything with it, and only that engine’s tools can say. Debugging in that order stops the common mistake of hunting a Google feature problem when the fault is a context that never loaded.
The same processors that power these tools run locally. jsonld.js and PyLD implement the JSON-LD 1.1 algorithms, rdflib parses JSON-LD into a graph, and pySHACL validates that graph against shapes, so a pipeline from crawled HTML to a pass or fail is scriptable.
For SEOs
Three of the four belong in a routine, for different reasons. The Schema Markup Validator on a template before it ships, because it catches property errors nothing else will. The Rich Results Test on a representative URL per template after it ships, because it is the only tool that renders the page and the only one that speaks to Google features. Search Console weekly, because it is the only source describing the live site rather than a test on demand.
Two habits prevent most wasted effort. Read a clean Rich Results Test as eligibility for the feature it named rather than as a prediction, and read silence as an absent feature rather than an error. And when a report and a test disagree, trust the report and check the date, since Search Console describes a crawl that already happened while the test describes the page as it is now. Wider context on what markup can and cannot do is in structured data and schema.org.
Related pages
FAQ
What is the Rich Results Test?
The Rich Results Test is Google’s tool at search.google.com/test/rich-results for checking whether Googlebot can fetch and render a page, whether it finds structured data, and whether that markup meets the requirements for a Google rich result type. It renders JavaScript, so it sees client-injected markup. It reports only on Google features and does not validate the schema.org vocabulary.
What is the difference between the Rich Results Test and the schema.org validator?
They answer different questions. The Rich Results Test reports eligibility for Google search features and renders the page first, but ignores anything outside Google’s feature list. The Schema Markup Validator at validator.schema.org checks markup against the whole schema.org vocabulary, catching misspelled properties and wrong value types, but says nothing about Google eligibility and does not run JavaScript.
Is there still a Structured Data Testing Tool?
Not at Google. The Structured Data Testing Tool was retired after Google announced its deprecation in 2020, and its codebase moved to schema.org, which launched the Schema Markup Validator at validator.schema.org from it in 2021. Use that validator for vocabulary checks and the Rich Results Test for anything concerning Google search features.
How do you validate structured data across a whole site?
Two approaches scale. A crawler that extracts every JSON-LD block turns markup into a dataset, showing which types appear on which templates and how many distinct identifiers exist for one entity. A continuous integration check expands the markup, loads it as a graph, and asserts rules with SHACL or SPARQL, so a broken template fails a pull request rather than reaching production.
Sources and further reading
- Google, Rich Results Test: https://search.google.com/test/rich-results
- schema.org, Schema Markup Validator: https://validator.schema.org/
- JSON-LD Playground: https://json-ld.org/playground/
- Google Search Central, Rich result status reports: https://support.google.com/webmasters/answer/7552505
- Google Search Central, Structured data general guidelines: https://developers.google.com/search/docs/appearance/structured-data/sd-policies
- schema.org, releases and vocabulary downloads: https://schema.org/docs/releases.html
- pySHACL: https://github.com/RDFLib/pySHACL