How to read the Rich Results Test
The Rich Results Test answers two questions: could Google fetch and render the page, and does its structured data qualify for a supported rich result type. It does not promise the result will appear. Here is how to run it, how to read each verdict, and where it stops being useful.
The Rich Results Test answers exactly two questions: could Google fetch and render this page, and does the structured data on it qualify for any rich result type Google currently supports. It does not tell you a rich result will appear. Google's own documentation says so in one sentence, and most of the confusion around this tool starts by ignoring it.
What you need before this chapter
You need structured data already on the page. If you are still deciding which type to add, which structured data types still earn anything covers the shortlist. This chapter is the step after that: proving what you wrote is being read the way you think it is.
What the Rich Results Test actually checks
It runs four checks in one pass, and only the last one is about your markup.
| Check | What failure looks like |
|---|---|
| Can the page be reached | Fetch error, or a robots.txt rule blocking it |
| Can it be rendered | Page loads but the rendered HTML is missing your content |
| Is the structured data parseable | Items listed as unparseable, usually a JSON syntax problem |
| Does it qualify for a type | Detected items with errors, or no eligible type found |
The reachability check is the one that surprises people. Google's Search Console help states the tool "won't crawl a website if the robots.txt file is present but not reachable" — a robots.txt that times out is treated differently from one that does not exist. It also accesses your page "as Google-InspectionTool (that is, not using your credentials, but as Google)", so anything behind a login, a geo rule or a bot filter fails here for reasons that have nothing to do with your schema (Rich Results Test, read 2026-09-03).
The default fetch is mobile. The same help page says "The default user agent is smartphone, as this is how the majority of users browse the web today." If your site serves different markup to phones — a stripped template, a lazily mounted component, a consent wall — the mobile pass is the one that decides, and you have to switch the agent manually to see the desktop version.
Why a passing test does not mean a rich result appears
Eligibility and appearance are two different things, and the tool only measures the first. Google states the limit directly: "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."
Three things sit between a green result and something visible in search. The page has to be indexed at all. The result type has to still exist as a rich result — some types the parser still recognises no longer produce anything, which is the subject of whether FAQ schema is still worth adding. And Google decides per search, per device, per result, whether to use the enhancement.
A green Rich Results Test means your markup is not the problem. It does not mean your markup is the reason for anything.
How to run it in five steps
Run these in order. The order is the point: four of the five steps exist to rule out something other than your markup, and skipping to the last one is how a delivery problem gets misdiagnosed as a schema problem.
- Test the live URL first, not the code. Paste the full address and let it fetch. This is the only mode that exercises delivery, and delivery is where most failures actually live.
- Read the fetch status before the item list. If the page could not be reached or rendered, everything below it is describing a page Google never saw properly.
- Open the rendered HTML view and search it for your structured data block. Seeing it in your editor is not evidence. Seeing it in the rendered HTML is.
- Switch the user agent to desktop and run it again. If the two runs disagree, your markup depends on the template, and the mobile answer is the one that counts.
- Only then paste the code directly, using the code mode Google describes as "Code instead of URL for the test". A pass here plus a failure on the URL isolates the problem to delivery rather than to the markup.
Step five is the one people run first and it is the least useful on its own. Testing a snippet proves the snippet is valid. It says nothing about whether your site ever puts that snippet on the page.
How to read the verdict
Copy this table into your notes. It is the whole judgement layer of the tool in five rows.
| What you see | What it means | Do this |
|---|---|---|
| No items detected | The markup never reached the rendered page | Check delivery, then check the type is one Google reads |
| Item detected, errors | A required property is missing or malformed | Fix the named property; the item is not eligible until you do |
| Item detected, warnings | An optional property is missing | Optional. Warnings do not block eligibility |
| Item detected, valid | The markup qualifies for that type | Stop editing schema. The next variable is indexing |
| Unparseable | The JSON-LD block itself is broken | Validate the JSON, then re-test; usually a trailing comma |
The distinction between errors and warnings is the part worth memorising. An error means the item cannot be used. A warning means Google would like more and will proceed without it. Teams routinely spend a week clearing warnings that were never blocking anything.
One more field is useful and easy to miss: Google saves test history for "approximately 90 days". When someone asks whether a page passed before last month's template change, the answer may still be in the tool.
Three ways people misread the result
All three come from the same habit: reading the item list before reading the fetch status, and reading a verdict as a forecast.
- Reading eligibility as a promise. A valid item means the markup qualifies. Every step after that — indexing, the type still being live, Google's per-search choice — is outside the tool.
- Testing code when the question is about a page. The code mode cannot see your CDN, your consent script or your template. If your question starts with "why doesn't my live page", the URL mode is the only one that can answer it.
- Treating a fetch failure as a schema failure. A blocked or unreachable page produces an empty item list, which looks identical to markup that was never added. Read the fetch status first and this stops happening.
When this tool cannot help you
It cannot tell you whether a rich result is currently showing for your page — it tests eligibility, not live search. It reports nothing about ranking, position or traffic. It says nothing about how AI answer engines read the same markup, since it only knows the types Google supports. And it will not tell you how long the gap between eligibility and appearance runs; we have not measured that, and no number we could give you would hold across sites.
For the live-search side of the question you want the URL inspection tool instead, covered in how to read the URL inspection tool. If the fetch itself is failing and you want to know who is blocking it before you argue with the schema, run the page through the AI crawler reachability check.
Common questions
Is the Rich Results Test the same as the schema markup validator?
No. This one reports the types Google can generate a rich result for; the generic validator reports whether your markup is well-formed schema.org vocabulary. A block can be perfectly valid vocabulary and produce nothing here, because Google supports a specific list of types.
Why does it show items my page does not have?
Because it reads the rendered page, which includes markup injected by scripts, plugins and embeds. A consent tool, a comment widget or a theme can add its own structured data. If an item surprises you, search the rendered HTML for it before assuming the tool is wrong.
Do warnings hurt my chances?
They do not block eligibility. Filling them in gives Google more to work with, which may change how a result is drawn, and we cannot tell you by how much. Clear errors first, always.
Can I test a page that is not published yet?
Use the code mode and paste the markup, or test a staging URL that is reachable without credentials. The tool fetches as Google, not as you, so a page behind a password is not testable by URL.
How often should I re-run it?
After every template change that touches the head or the markup layer, and once when a page type is first launched. Running it on a stable page weekly tells you nothing new, because the tool only reads the page as it is right now.
Part of the QueryWin handbook · Level 2
