You added schema markup to your site, and now you want to know if it works. For structured data testing, you need two free tools, and they answer different questions. The Rich Results Test tells you if Google can use your markup for a rich result. The Schema Markup Validator tells you if your code is correct schema.org, for any type.
Most confusion comes from using one tool and expecting the answer of the other. In this guide I explain what each tool checks, when I use which one, how to read the results, and what to do when the markup is valid but nothing shows in Google.
Why There Are Two Tools for Structured Data Testing
Structured data is code that labels the facts on a page, like a product’s price or an article’s author, so search engines can read them easily. The labels come from schema.org, a shared vocabulary that Google, Bing and others support. Most sites write it as JSON-LD (a script block in the page that visitors don’t see).
For years, Google had one tool for all of this: the Structured Data Testing Tool. In 2020 Google moved its focus to the Rich Results Test, which only checks the types Google uses in Search. After feedback from the community, Google announced in December 2020 that the old tool would not simply shut down. It moved to schema.org and became the Schema Markup Validator, with Google-specific checks taken out.
So today the split is simple:
- Rich Results Test: Google’s view. Can this page get a rich result in Google Search?
- Schema Markup Validator: the schema.org view. Is this markup correct, whatever type it is?
Google’s own guide to testing structured data recommends exactly this: start with the Rich Results Test, and use the Schema Markup Validator for general schema checks.
Rich Results Test vs Schema Markup Validator at a Glance
Here is how the two tools compare on the things that matter in daily work.
| Question | Rich Results Test | Schema Markup Validator |
|---|---|---|
| Who runs it? | schema.org | |
| Which types does it check? | Only types Google supports for rich results | All schema.org types |
| Does it check Google’s required fields? | Yes, with errors and warnings | No |
| Formats | JSON-LD, Microdata, RDFa | JSON-LD, Microdata, RDFa |
| Input | URL or pasted code | URL or pasted code |
| Shows the page as Google renders it? | Yes, rendered HTML and crawl details | No |
| Preview of the search result | For some types | No |
| Best for | Checking eligibility for rich results in Google | Checking syntax and types Google doesn’t use for rich results |
Neither tool is “better”. They do different jobs, and I use both on almost every schema project.
How the Rich Results Test Works
The Rich Results Test lives at search.google.com/test/rich-results. You give it a URL or paste a code snippet. It then lists every rich result type it finds and tells you if each item is valid.
URL Mode and Code Mode
In URL mode, Google fetches your live page and renders it, which means it runs the JavaScript the way Googlebot would. This matters if your markup is added by a plugin, a tag manager or a JavaScript framework. If the markup only appears after scripts run, this is the tool that will show it.
In code mode, you paste HTML or a JSON-LD block. You can edit the code right in the tool and run the test again as often as you want. I use this mode a lot when I’m drafting markup, before any developer touches the site.
Smartphone or Desktop
The test uses a smartphone crawler by default, and you can switch to desktop. Google indexes the mobile version of pages, so I always test smartphone first. If your mobile theme drops some markup that the desktop version has, this is where you’ll catch it.
Errors vs Warnings
Each detected item gets a status. The difference between the two problem types is important:
- Errors make the item invalid. Usually a required property is missing or has the wrong format. An item with errors can’t get that rich result.
- Warnings mean the item is valid, but a recommended property is missing or has an issue. The item can still get a rich result, maybe with less detail.
In my experience, people panic over warnings far too often. I fix every error. Then I fix warnings only where I can add real, accurate information. I’d never invent a value just to clear a warning.
Rendered HTML and Crawl Details
The test also shows crawl details: whether the page could be fetched, which user agent was used, and whether robots.txt allowed it. You can open the rendered HTML too. When markup “disappears”, the rendered HTML is the first place I look, because it shows what Google actually saw.
Limits to Know
- It only reports types Google supports for rich results. A
ServiceorWebPageblock won’t appear as a rich result item, even if it is perfect. - It fetches pages anonymously, so it can’t test pages behind a login or a firewall. For a staging site, use code mode instead.
- It identifies itself as Google-InspectionTool. If your robots.txt blocks that crawler, or blocks scripts the page needs, the results can be incomplete.
- Images or scripts that fail to load can make results change between runs. If you see a warning about page resources, run the test again before you start debugging.
One more useful feature: the Share button creates a link to your results that anyone can open, without Search Console access. Google says these links last about 90 days. I use this when I send a problem to a developer, because they see exactly what I saw.
How the Schema Markup Validator Works
The Schema Markup Validator lives at validator.schema.org. Like the Rich Results Test, it accepts a URL or a code snippet. It then shows every structured data item it finds, as a tree of types and properties.
What it checks is narrower in one way and wider in another. It does not know Google’s rules, so it won’t tell you a product needs a price or a review to qualify. But it checks any schema.org type, and it flags syntax problems, unknown types and property names that schema.org doesn’t define.
This makes it the right tool for markup that has no Google rich result, such as:
Service,PersonorWebPagemarkup- Extra properties like
sameAsorknowsAboutthat help Google understand who you are - Markup you add for other search engines or other platforms, not just Google
- Large nested graphs from SEO plugins, where you want to see how items connect
I find the tree view the easiest way to spot nesting mistakes. If an author shows up as a separate item instead of sitting inside the article, you’ll see it right away.
Which Tool to Use and When
Here is the rule of thumb I use with every team I work with.
- You want stars, prices, recipe cards or other rich results in Google: Rich Results Test first. It is the only tool that checks Google’s requirements.
- You’re writing markup for a type Google doesn’t show as a rich result: Schema Markup Validator.
- You’re getting a strange syntax error and can’t find it: try both. The two tools sometimes word errors differently, and one message may make the cause clearer.
- Your markup is added by JavaScript or Google Tag Manager: Rich Results Test in URL mode, because it shows the rendered page.
- You want to check the whole site, not one page: neither. Use the rich result reports in Search Console, which I cover below.
A Simple Testing Workflow That Catches Most Problems
When I add or change schema on a site, I follow the same order every time. It takes a few minutes per template and saves a lot of back and forth later.
- Validate the draft code. Paste your JSON-LD into the Schema Markup Validator to catch syntax mistakes and wrong property names.
- Check Google’s requirements. Paste the same code into the Rich Results Test in code mode. Fix every error and decide which warnings you can fix with real data.
- Publish and test the live URL. Run the live page through the Rich Results Test with the smartphone crawler. Open the rendered HTML if anything is missing.
- Test more than one page. Markup usually comes from a template. Test a new page, an old page and an unusual one, like a product with no reviews or a post with two authors.
- Ask Google to recrawl key pages. In Search Console, run the URL Inspection tool, test the live URL and request indexing for your most important pages.
- Watch the rich result reports. Over the next days and weeks, check the reports in Search Console for new errors across the site.
Step 4 is the one people skip. In my experience, most schema bugs aren’t on the page you tested. They’re on the pages with missing or odd data that nobody looked at.
Reading a Result: A Practical Example
Say you sell a desk lamp and paste this code into the Rich Results Test.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Oak Desk Lamp",
"image": "https://example.com/images/oak-lamp.jpg",
"offers": {
"@type": "Offer",
"price": "$49.00",
"priceCurrency": "USD",
"availability": "In stock"
}
}
</script>
The Schema Markup Validator may accept most of this, because schema.org is flexible about values. The Rich Results Test is stricter, because Google needs values it can read reliably. Two things here are wrong for Google:
priceshould be a plain number like49.00. The currency belongs inpriceCurrency, not in the price.availabilityshould use a schema.org value likehttps://schema.org/InStock, not free text.
This is a good example of why you need both tools. Code can be acceptable schema.org and still not be good enough for Google’s rich results.
Common Errors and How to Fix Them
These are the problems I see most often when I test schema on client sites.
Syntax Errors
A missing comma, an extra comma after the last property, or a missing bracket breaks the whole JSON-LD block. Curly “smart” quotes are another classic. They sneak in when someone copies code from a word processor or a chat window. Always paste code into a plain text editor first.
Missing Required Fields
Each rich result type has its own required properties, listed in Google’s docs for that type. If the test says a field is missing, check where your template gets that value. Often the field exists on the page, but the plugin can’t find it, for example a price stored in a custom field.
Wrong Value Formats
Dates should use the ISO 8601 format, like 2025-06-03T10:00:00+05:30. Prices should be numbers. Fields like availability and condition need schema.org values, not your own words.
Duplicate or Conflicting Markup
A theme and an SEO plugin can both add the same type, with different values. The test will show two items. I always remove one source, so there is a single, consistent block per item. This is very common with article structured data on WordPress sites.
No Items Detected
If the Rich Results Test finds nothing, check these in order: is the markup really on this URL, is it only in the desktop version, is the type one Google supports, and is a script or robots.txt rule stopping the markup from loading? The rendered HTML usually answers the question within a minute.
Valid Markup but No Rich Result? Here’s Why
This is the question I get most. The test says everything is valid, but Google still shows a plain blue link. That’s normal, and there are a few reasons.
- Eligibility isn’t a promise. Google’s general structured data guidelines say valid markup makes a page eligible, but Google decides when to show a rich result.
- Quality and policy rules. Markup must match content visible on the page, and must not be misleading. The test can’t check this. A person has to.
- Feature limits. Some rich results are limited. For example, since August 2023 Google shows FAQ rich results mainly for well-known government and health sites. And review snippets have rules about which reviews count, such as no self-serving reviews on your own business.
- Not crawled yet. Google only reads new markup after it recrawls the page. That can take days or weeks.
- Manual action. If Google finds spammy markup, it can remove rich result eligibility. Check the Manual actions report in Search Console if rich results vanish across the site.
My honest view: a passing test is the start, not the finish. I treat it as “Google can read this”, not “Google will show this”.
Testing Structured Data Across the Whole Site
The two testing tools check one page at a time. For a real site, you also need Search Console.
Under the enhancement and shopping sections in Search Console, you’ll find a report for each rich result type Google found on your site, such as Product snippets, Review snippets or Videos. Each report groups pages into invalid and valid items, with the error name and example URLs. Google builds these from its normal crawls, so they show problems on pages you never thought to test.
After you fix an issue, click “Validate fix” in the report. Google then rechecks the affected pages and tells you when validation passes or fails. I check these reports once a month on most sites, and right after any theme, plugin or template change.
For large sites, crawler tools can also extract and validate structured data in bulk. They’re useful, but I still confirm any real problem with the Rich Results Test, because that’s Google’s own view of the page.
Conclusion
Good structured data testing comes down to using the right tool for the question. Use the Rich Results Test to check if Google can use your markup for rich results, and the Schema Markup Validator to check that any schema.org code is correct. Then use Search Console to keep an eye on the whole site.
Your next step: pick your most important page template, run it through both tools today, and fix every error you find. If you want to see the other free Google tools that help with this kind of work, read my guide to free Google tools for SEO.



