Rich Results Test vs Schema Markup Validator: Which One to Trust

Use the Rich Results Test when you want to know whether markup can earn a Google Search feature. Use the Schema Markup Validator when you want to know whether the markup is valid schema.org at all. They disagree in both directions, and the disagreement is by design.

We ran both against the same URL on 1 November 2026, the crawl budget guide on this site. Google's tool reported 4 valid items in two groups and raised four distinct date warnings against each of the two Article items it found. The schema.org tool reported 7 items across four types, with zero errors and zero warnings. Same page, same minute.

What each tool is actually checking

The split is eligibility against validity. One asks whether Google can build a result feature from your markup, the other asks whether the markup conforms to the schema.org vocabulary.

	Rich Results Test	Schema Markup Validator
Who runs it	Google, at search.google.com/test/rich-results	schema.org, at validator.schema.org
Question it answers	Can this page produce a Google Search feature?	Is this markup valid schema.org?
Types reported	Types tied to a documented Search feature	Any schema.org type, feature or not
On our test URL	4 valid items, 2 types	7 items, 4 types
Issues raised	4 date warnings per Article item	0 errors, 0 warnings
How it fetches	Crawls as Google-InspectionTool, uses the rendered source	Fetches the URL and displays the served source
Blocked in robots.txt	Cannot test the page	Paste the code instead

Rich Results Test: eligibility for a Search feature

Google's tool tells you which of your markup can become a result feature, and it is the only one of the two that fetches the page the way Google does. Google's structured data documentation, last updated 10 December 2025, puts it at the centre of the development loop: "Be sure to check your structured data using the Rich Results Test during development, and the Rich result status reports" after deployment.

What it does well: it renders the page before judging it, so JavaScript-injected markup is in scope. Google's help page for the tool states that the explorer "uses the rendered source code" and that the tool "accesses the page as Google-InspectionTool". It also shows the parsed property values back to you, which is how you catch a templating error rather than a syntax error. And it is strict about the fields Google itself consumes, which is where our date warnings came from.

Where it falls down: it is silent about anything outside Google's feature set. It reported nothing for three of the five types our page serves, which on screen is indistinguishable from markup that is missing or broken. It also needs a crawlable URL, so a staged page behind robots.txt cannot be tested.

Pick it when the goal is a Search feature and the page is live.

Schema Markup Validator: syntax and vocabulary

The schema.org tool checks the markup against the vocabulary itself, with no opinion about Google. It is the successor to Google's Structured Data Testing Tool, which Google announced it was refocusing in December 2020, and schema.org now hosts it at validator.schema.org.

What it does well: it reports every type it finds, including the ones Google has no feature for, which is the only way to confirm that markup you ship for other consumers is well formed. It groups results by type with item counts, it accepts pasted code as well as a URL, and on our page it showed the served source alongside the parse, so you can see exactly what it read.

Where it falls down: a clean bill of health here says nothing about Google. It returned zero errors and zero warnings on the same markup Google raised four warnings against, because the fields Google cares about are Google's requirements rather than schema.org's. Treat a green result as a syntax check, never as readiness to ship.

Pick it when you need to know whether the markup itself is correct, or when the consumer is not Google.

What each tool reported on the same URL

The page serves five JSON-LD blocks: Organization, WebSite, Article, BreadcrumbList and FAQPage. Here is what each tool made of them, tested within a minute of each other on 1 November 2026.

Type on the page	Rich Results Test	Schema Markup Validator
Article	2 valid items, 4 warnings each	2 items, 0 errors, 0 warnings
BreadcrumbList	2 valid items	2 items, 0 errors, 0 warnings
FAQPage	Not reported	2 items, 0 errors, 0 warnings
WebSite	Not reported	1 item, 0 errors, 0 warnings
Organization	Not reported	Not listed as its own group
Total	4 valid items	7 items

Two things in that table are worth more than the totals. The schema.org tool found types Google ignored, and Google found problems the schema.org tool did not.

Organization is the result we cannot explain

FAQPage and WebSite going unreported by the Rich Results Test is expected, because neither is in Google's feature gallery. Organization is, and the page ships a 915-byte Organization block, and the Rich Results Test reported nothing for it either.

We do not know why. It may be consumed as the publisher of the Article rather than counted on its own, since the tool did show our Organization details nested inside each Article item. That is a guess, and it is the kind of guess worth naming as one: a gallery-listed type can go unreported, so "nothing shown" never means "nothing found".

The four warnings only one tool raised

Google's tool flagged four non-critical issues against each Article item, and all four are about dates:

Invalid datetime value for "datePublished" (optional)
Datetime property "datePublished" is missing a timezone (optional)
Invalid datetime value for "dateModified" (optional)
Datetime property "dateModified" is missing a timezone (optional)

Our CMS stores publication dates as a plain date, so the markup emits "datePublished": "2026-08-31" and "dateModified": "2026-10-09" rather than full timestamps with an offset. schema.org accepts that. Google wants the timezone. Both tools are consistent with their own rules, and only one of them told us.

They are marked optional and they did not stop the items being valid, so this is a cleanup task rather than an emergency. It is also site-wide: every post here carries the same two date fields, which makes it exactly the kind of templating issue that one URL test surfaces and a hundred manual page reviews would not.

FAQPage: valid markup, no feature

FAQ is not among the 25 features in Google's structured data features gallery, last updated 16 October 2026, which is why the Rich Results Test reported nothing for it while the schema.org tool validated two FAQPage items cleanly. We walked through whether to keep shipping it in our analysis of FAQPage markup after the rich results removal, and kept it.

A type that disappears from the gallery does not become invalid. It becomes invisible to the tool most teams use to check it.

The practical risk is misdiagnosis. A developer runs the Rich Results Test, sees nothing reported for FAQ, and files a bug against the markup. The markup is fine. It is unsupported, which is a different ticket with a different answer.

Why both tools counted two of everything

Both reported 2 Article items and 2 Breadcrumb items against a page that ships one Article script tag and one BreadcrumbList script tag. The response explains it: our page serves five <script type="application/ld+json"> tags and then five more escaped copies of the same JSON inside the Next.js flight payload, the self.__next_f blob React uses to hydrate the page. Every block is in the response twice.

We have verified the duplication. We have not verified what each tool did with it, and the two tools would have to be reaching it by different routes, since one renders the page and the other displays the served source. The useful rule stands either way:

An item count is what a tool parsed, not the number of script tags you shipped. If two independent validators both double a count, read the response before you trust either number.

Which one to run, and when

Run them in this order, and stop at the first one that answers your question.

1. Rich Results Test, on the live URL. It fetches the page the way Google does and runs your JavaScript. If a Search feature is the goal, nothing else substitutes.
2. Schema Markup Validator, on the same URL or the raw block. Use it when the first tool reported nothing, to separate "invalid" from "unsupported".
3. Search Console, after deployment. Google's guidance is to monitor the rich result status reports for pages that "might break after deployment due to templating or serving issues", and to confirm with the URL Inspection tool that Google found the markup.

What neither tool tells you

Neither predicts a rich result. Both check the input; the output depends on indexing, on page quality and on Google's own discretion about when to show a feature. A page can validate in both tools and never show an enhanced result, which is why the verification loop ends in Search Console rather than in a validator.

If you are adding markup for the first time, start with the types that carry a documented feature for your page type, verify them in the Rich Results Test, and keep the rest for the consumers that read schema.org directly. Our schema markup guide covers which types are worth emitting at all, and the technical SEO checklist places this check in the wider audit.