A developer adds Dataset markup to a research page. The Rich Results Test reports no items detected. The developer concludes the markup is broken and spends a morning rewriting valid JSON-LD. Nothing was broken. The Rich Results Test only reports on features Google renders as rich results, and that page was never going to get one.
This is the most common wasted hour in structured data work, and it comes from using one tool to answer a question it was never built for. There are three distinct questions in this subject and only two of them have tools. This piece sets out which tool answers which, what each one catches and misses, and the question you have to answer yourself because no validator can.
Everything factual here is from official documentation read on 2 November 2026, with sources at the end. If you need the concept rather than the tooling, start with our JSON-LD and schema glossary entry.
The three questions
One: is this valid schema.org? Does the JSON parse, are the types real, are the properties real, do the values have the right shape. This is a vocabulary question and the Schema Markup Validator answers it.
Two: is this eligible for a Google rich result? Does it meet Google’s requirements for a specific feature, with all required properties present. This is a Google question, it covers only the features Google supports, and the Rich Results Test answers it.
Three: is it true? Does the markup describe what is actually on the page, honestly. No tool answers this, Google says so in its own documentation, and it is the question that gets sites into trouble.
Most arguments about structured data tooling are two people answering different questions from that list.
The Rich Results Test
Google’s own tool, and the one its documentation points you to. The structured data general guidelines state: “You can test compliance with technical guidelines using the Rich Results Test”, and that the tools “catch most technical errors”.
What it does. Fetches your live URL as Google, renders it, extracts structured data, and reports on the Google rich result features it finds, with errors and warnings per feature. It also shows you the rendered HTML, which is quietly its most useful output.
What it does not do, and this is the part that wastes mornings. It reports only on Google-supported rich result types. Valid markup for a type Google does not render as a rich result, or does not render in your region or for your page type, produces no items detected. That is not a validation failure. It is the tool correctly telling you there is no Google feature here, which is a different statement from your markup being wrong. Dataset, QAPage, Service, Organization detail, and plenty of other legitimate markup can sit in this category.
Two further things worth knowing. Errors block eligibility and warnings do not, so a warning about a recommended property is a judgement call rather than a defect. And Google is explicit that passing is not a promise: its guidelines say Google “doesn’t guarantee that marked-up features will appear, even when markup passes testing”. Anyone reporting a green tick as a result has over-claimed.
Test the live URL rather than pasting code whenever you can. Pasting code tests the code; testing the URL tests what your server, your cache, your tag manager and your plugins actually produce, which is frequently different.
The Schema Markup Validator
At validator.schema.org, titled simply “Schema Markup Validator”, presented under the Schema.org name. This is the general-purpose vocabulary validator, and it is the successor to the tool Google used to run: Google published a post in December 2020 titled “An update on the Structured Data Testing Tool”, and the Rich Results Test came out of beta in July 2020.
Use it for everything the Rich Results Test ignores. It will parse any schema.org markup, report what it found, and flag properties and types it does not recognise, without caring whether Google renders a feature for it. For Dataset, for QAPage, for Service, for complex nested organisation and person graphs, for anything you are marking up to be machine-readable rather than to win a rich result, this is the tool.
Its limitation is the mirror image of the other tool’s. It will happily approve markup that is perfectly valid vocabulary and completely ineligible for any Google feature because a required property is missing. Valid and eligible are different words.
Search Console: the only place that tells you what Google actually did
The two testers tell you what a page could be eligible for. Search Console tells you what happened across your whole site, which is a different and more useful thing once you are past the first implementation.
The rich result status reports list, per feature, how many of your pages are valid, how many are valid with warnings, and how many have errors, with examples and a validation flow you can trigger after a fix. This is where you find that a template change three weeks ago broke the markup on four hundred product pages, which no single-URL test would ever reveal.
URL Inspection gives you the detected items for a specific URL as Google last crawled it, plus the rendered HTML. The difference between what URL Inspection saw on its last crawl and what the Rich Results Test sees now is how you tell whether a fix has been picked up yet.
The Manual Actions report is the one nobody checks. Google’s guidelines note that it shows whether a structured data manual action has been applied. If markup has been judged spammy, this is where you find out, and it is worth a look in any audit of a site you have inherited.
Crawl-wide validation: the tool that catches real problems
Single-URL testers are for development. The problems that cost money are template-wide and only a crawler finds them.
Screaming Frog validates structured data across a crawl, against both the schema.org vocabulary and Google’s feature requirements, and reports errors and warnings per URL so you can group them by template. Sitebulb and the site audit modules in Semrush and Ahrefs do a comparable job with different reporting. Whichever you use, the output you want is not a list of URLs, it is a count by error type and by template, because a fix goes into a template and applies to every page using it.
Run this before and after any theme or plugin update. In our experience the commonest cause of mass structured data breakage is not a developer writing bad markup, it is an update changing a template or a second plugin starting to emit its own markup alongside the first.
The two-sources-of-markup problem, and how to find it
Worth its own section because it is so common and so easily missed. On WordPress in particular, a theme, an SEO plugin, a review plugin and a page builder can each emit structured data. The result is two Organization nodes disagreeing about the business name, or two Article nodes with different dates, or an aggregate rating appearing twice.
No validator flags this as an error, because each block is individually valid. You find it by looking at the extracted items list in either tester and counting the entities, or by searching the rendered source for the number of script blocks of type application/ld+json. If there are three and you only built one, find the other two and switch them off. One source of truth per entity.
Syntax-level tools
For the cases where the markup will not parse at all, the JSON-LD Playground at json-ld.org expands and flattens a document and reports context and syntax problems in more detail than either validator. Useful when you are generating JSON-LD programmatically and something in the escaping or the context is wrong. The escaping traps specifically are covered in how to add JSON-LD schema in Laravel Blade templates safely, and the framework equivalents in the Next.js metadata deep dive.
Browser extensions that display a page’s structured data are the fastest way to eyeball a competitor’s markup or confirm something is present while you work. They are a convenience, not a validator.
The AI question: there is no validator, and the raw HTML is what matters
Nobody publishes a tool that tells you whether an AI assistant read your markup, and any product claiming to is guessing. What you can check is the thing that actually determines it: whether the JSON-LD is in the raw HTML that a crawler receives, rather than injected by JavaScript after load.
Google renders JavaScript and will usually find markup injected client-side. Most AI crawlers do not render, so markup that only exists after hydration does not exist for them. The test is in rendered vs raw HTML, and the framework-specific version in the React and Next.js crawler test. If the markup is not in view-source, treat it as absent for AI purposes.
On whether any of this earns you a citation, our position has not changed and is set out in does schema markup help you get cited in AI Overviews: markup is not a ranking or citation factor, and it remains the cleanest way to tell a machine what a page is.
The third question, which no tool answers
Google’s structured data guidelines are unusually direct about the limits of automated checking. They state that the tools “catch most technical errors” but that quality guidelines cannot be fully checked by automated tools. Then they set out what the quality guidelines actually require.
“Don’t mark up content that is not visible to readers of the page.”
“Don’t mark up irrelevant or misleading content, such as fake reviews or content unrelated to the focus of a page.”
“Your structured data must be a true representation of the page content.”
And on type selection: “Try to use the most specific applicable type and property names defined by schema.org for your markup.”
Every one of those is a human check. A validator will cheerfully approve an aggregate rating on a page with no visible reviews, a FAQ node listing twenty questions where the page shows five, opening hours that contradict the contact page, or a Hospital type on a two-room clinic. All four pass validation. All four are the kind of thing that ends up in the Manual Actions report.
So the last step of any structured data review is a person opening the page and the markup side by side and asking whether the second is an honest description of the first. We put that check at the end of every schema piece on this site, and it is the only one that cannot be automated.
Getting validation out of the browser and into the pipeline
Testing by hand catches the error you went looking for. A rule in the publishing pipeline catches the one you did not.
The approach we use is in automating structured data from your CMS with a validation script: for each template, declare the type that must be present and the properties that must be filled, then check it on publish and fail loudly. Add the entity count check from above so that a second plugin emitting markup is caught the day it starts. Add a scheduled crawl-wide validation monthly, and watch the Search Console reports rather than waiting for someone to notice.
That combination means the only structured data work left is the honest-description judgement, which is where the thinking belongs.
The comparison
| Tool | Answers | Scope | Catches | Misses |
|---|---|---|---|---|
| Rich Results Test | Google eligibility | One URL, live or pasted | Missing required properties for Google features, rendered HTML | Anything outside Google’s feature set, truthfulness |
| Schema Markup Validator | Vocabulary validity | One URL or snippet | Invalid types and properties, parse failures, any schema.org type | Google eligibility, missing required properties |
| Search Console rich result reports | What Google did, site-wide | Whole property, by feature | Template-wide breakage, regressions over time | Immediate feedback, unsupported types |
| URL Inspection | What Google last saw | One URL | Whether a fix has been crawled, rendered output | Anything site-wide |
| Manual Actions report | Whether you have been penalised | Whole property | Structured data manual actions | Everything else |
| Screaming Frog and other crawlers | Both, at scale | Whole site | Errors grouped by template, duplicate entities | Truthfulness, Google’s unpublished judgement |
| JSON-LD Playground | Syntax and context | A snippet | Escaping and context errors in generated output | Vocabulary correctness, eligibility |
| A human reading page and markup together | Is it true | One page | Everything the guidelines actually prohibit | Nothing, which is why it is last |
A review order that does not waste time
- Decide first whether the type you are implementing has a Google rich result at all. If it does not, the Rich Results Test is the wrong tool and no items detected is the expected output.
- Validate vocabulary in the Schema Markup Validator.
- If a Google feature is intended, check eligibility in the Rich Results Test, on the live URL, and treat errors as blocking and warnings as a judgement.
- Count the JSON-LD blocks and the entities. More than one source per entity is a bug whatever the validators say.
- Confirm the markup is present in raw HTML, not injected after load.
- Crawl the whole site and group errors by template rather than by URL.
- Read the page and the markup side by side and answer the honesty question.
- Put steps two to five into the publish pipeline so none of this is manual next time.
What is a waste of effort
Rewriting valid markup because the Rich Results Test said no items detected for a type Google does not feature.
Reporting a green tick as a result, when Google states that passing does not guarantee the feature appears.
Chasing every warning. Errors block eligibility; warnings are recommendations.
Testing pasted code instead of the live URL, and so never seeing what the cache and the plugins actually output.
Validating one URL per template by hand, monthly, instead of crawling.
Trusting any tool that claims to tell you whether an AI assistant used your markup.
If your structured data passes every validator and you are still not sure it is honest, get in touch.
Last verified: 2 November 2026. We review this page quarterly.
Sources. Google Search Central, “Structured data general guidelines”, read 2 November 2026. Schema Markup Validator at validator.schema.org, read 2 November 2026. Google Search Central Blog, “An update on the Structured Data Testing Tool”, December 2020, and “The Rich Results Test is out of beta”, July 2020.