Most people go to the Google Rich Results Test, paste a URL, see a green tick and move on. That habit misreads what the tool is for. The Google Rich Results Test schema report answers one narrow question: can Google read this markup as a rich result type? It does not tell you whether Google will use it, and a pass can still break in production.
This is a reading guide for the report itself. The requirements for individual types live in our posts on recipe schema and product schema, and the general case for markup is in schema markup, so none of that is repeated here.
What goes in: a URL or a block of code
Google’s Search Console Help article on the Rich Results Test describes the purpose plainly: “Put structured data on your page to enable special features in Google Search results, then test it with the Rich Results test.” The tool “supports structured data in JSON-LD, RDFa, and Microdata”. If you are still choosing between formats, our comparison of JSON-LD and Microdata covers that decision.
There are two inputs. With URL, you “Submit the full URL of the page to test.” With Code, you “paste the code to be tested”, and you can edit it and rerun “as often as you like”. Code mode is the faster loop while you are drafting markup. URL mode is the one that matters before you ship, because it fetches the page the way Google would.
You also choose a user agent, smartphone or desktop. “The default user agent is smartphone, as this is how the majority of users browse the web today.” The tool “accesses the page as Google-InspectionTool (that is, not using your credentials, but as Google). This means that it can be blocked by a robots.txt file.”
What the Google Rich Results Test schema report shows
According to the help page, “The test shows which rich result types were found on the page, as well as any errors or suggestions for your structured data.” The headline is a status line, and there are nine of them. The definitions behind them come from a second Search Console Help page, “Rich result report overview”: a valid item “doesn’t have any critical issues and can appear on Google as a rich result”, while an invalid item “has at least one critical issue preventing it from appearing as a rich result.” Non-critical issues sit under “Improve item appearance”.
| Status line (N = item count) | What it means | What to do |
|---|---|---|
| N valid item(s) detected | No critical issues; eligible | Ship, then watch the Search Console reports |
| No items detected | No supported rich result type was found | Check the markup rendered at all, and the type is on the supported list |
| N valid item(s) with warnings detected | Eligible, with non-critical issues | Fix what affects appearance where you can |
| N valid items detected: All have warnings | Every item eligible, every item has non-critical issues | Look for one template-level omission |
| N valid items detected: Some have warnings | Mixed; all eligible | Compare a clean item with a warned one |
| N items detected: Some are invalid | At least one item has a critical issue | Fix the invalid items before release |
| N invalid item(s) detected | Critical issues; not eligible | Fix the critical issues first |
| URL cannot be crawled | The tool could not fetch the page | Open the crawl section; check robots.txt and noindex |
| Structured data with syntax errors detected | The parser could not read the markup | Fix the syntax before anything else |
Clicking an issue opens the code explorer, and “The explorer uses the rendered source code.” If your markup is injected by JavaScript, the explorer shows what Google saw after rendering, not what sits in your template.
Valid means eligible, not shown
The rich result report overview states it carefully: “Valid structured data is eligible to appear as rich results in Google Search.” Eligible is the whole promise. The preview pane carries its own disclaimer: “Google does not guarantee that your page will appear exactly as shown here, or that any of the views shown will be applied to your page result; Google tries to show the best result for a search request, based on the user’s search history, location, and many other variables.”
So a valid result is a precondition, not a forecast. Warnings are non-critical: they do not block eligibility, but they are listed because they affect how an item can appear. For what rich results look like on the page once they do show, see our overview of SERP features.
The traps that produce a misleading result
Blocked pages and login walls
If Google “is prevented from crawling by a robots.txt rule or noindex directive), the page cannot be tested with this tool.” The crawl section shows “Crawled as”, “Crawl allowed?” and “Page fetch”, which is the first place to look when you get “URL cannot be crawled”. Our post on blocked by robots.txt covers the fix. Resources need the same openness: “All page resources must be accessible by an anonymous user accessing the code from the internet.” Anything behind a firewall or a password is invisible to the test.
Comments inside JSON-LD
This one passes in the tool and fails later. “The Rich Results test tool ignores comments within JSON-LD blocks. However, that behavior is not supported by the JSON-LD standard and so might result in errors in actual usage.” Strip comments before you publish. Genuine syntax faults appear under “Syntax errors in items of unknown type”, with messages such as “Invalid JSON document” or “Parsing error: Missing ‘,’ or ‘}'”.
Results that change between runs
Resources that fail to load produce a warning, and “you might see slightly different results every time you run the test” when loading is inconsistent. If a rerun flips the result, the markup may be fine and the page load unreliable.
Public bookmarks
“Test history is saved for approximately 90 days. These bookmarks are accessible by anyone.” Shared result links last about as long, and “permissions are not required to view the results.” Do not test a page you would not want a stranger to see.
The test against the Search Console reports
The test checks one page at a time. The Search Console reports, found “under Enhancements” (product snippets and merchant listings sit “under Shopping”), watch the whole site, but they “show a sample of detected items” and are “not a comprehensive list”. Their “numbers in the reports reflect items not pages”. The help page’s own advice for a single item is to “inspect the page that hosts the URL, or use the Rich Results Test.” Our guide to the URL Inspection tool covers the first option.
A sensible routine uses both: Code mode while drafting, URL mode on the live page before you announce it, and the Enhancements reports afterwards to catch templates that drift. If you were hoping for a Google Rich Results Test API to do this at scale, the help page does not describe one.
The limitation is worth stating. The test tells you whether markup is readable and eligible on one fetch of one page. It cannot tell you whether Google will show a rich result, how often, or what that does for clicks.
Frequently asked questions
Does a valid result mean my rich result will show?
No. Search Console Help says valid structured data “is eligible to appear as rich results”, and the preview notes that Google does not guarantee the page will appear as shown.
Should I test on smartphone or desktop?
The default is smartphone, “as this is how the majority of users browse the web today.” You can switch to desktop if you need to compare.
Why does the test say the URL cannot be crawled?
The tool fetches as Google-InspectionTool, so a robots.txt rule or noindex directive stops it. Check the crawl section’s “Crawl allowed?” and “Page fetch” fields.
Is there a Google Rich Results Test API?
The Search Console Help article on the tool does not describe one. The documented routes are the web tool and the Search Console reports.
The takeaway Read the status line, not the colour. Valid means eligible, warnings are non-critical but real, and a pass can hide JSON-LD comments, blocked resources or a flaky page load.
