Rich Results Test: how to run it and fix what it flags

What the Rich Results Test actually checks

It answers one narrow question: does this page contain valid structured data for a rich result type Google currently supports?

That is the whole job. It is a validator for eligibility. It is not an index check, not a ranking tool, and not a general schema linter.

Structured data is code that labels what is on a page so a search engine can read it without guessing. If that idea is new, start with our schema markup guide, then come back here to test what you built.

Two limits matter before you read any output:

• It only reports Google's own list. Google documents 25 supported structured data types in its search gallery (Search Central, last updated 16 October 2026). Valid markup for anything outside that list is simply not listed.
• It is not a schema.org validator. For vocabulary-level checking — spelling of properties, types that do not exist — use Schema.org's own Markup Validator. The two tools answer different questions and you want both.

FAQPage is the cleanest example of limit one. Google added a deprecation notice on 8 May 2026 saying FAQ results would no longer appear in Search from 7 May 2026, and removed the documentation on 15 June 2026 (Search Central documentation updates).

So a perfectly valid FAQPage block now returns nothing useful here. The markup is not broken. The feature is gone. It is still valid schema.org and still machine-readable context — it just will not draw a rich result. Our post on FAQ schema covers what to do with the blocks you already have.

Which rich result types still exist and what each one needs is a separate question, and we answer it in a separate post on Google rich result types. How to write the JSON-LD itself is another post again. This one stays on the test.

How to run the test, step by step

1. Open the tool. search.google.com/test/rich-results. It is free and needs no sign-in for a public page.
2. Choose URL or Code. URL fetches the live page. Code tests markup you paste — use that before you publish, and for anything behind a login.
3. Set the user agent. Googlebot smartphone is the default and the one to trust. Google indexes mobile-first, so the smartphone render is the render that counts. Switch to desktop only to compare.
4. Run it and let it render. The test fetches the page, pulls its resources and executes JavaScript before it reports. That takes a few seconds.
5. Open every detected item. The summary panel hides detail. Expand each item to see which property triggered which message.

Then open View tested page. That panel holds the rendered HTML, a screenshot, the page resources the test could not load, and any JavaScript console messages.

Most real diagnosis happens there, not in the summary.

Error, warning, or "no items detected" — the three outcomes

These three mean completely different things, and treating a warning like an error is the most common waste of a developer's afternoon.

"No items detected" on a page you know has markup is almost always one of those four causes, in that order of likelihood.

Fixing each error class the test reports

The exact wording changes by type, but the error classes do not. Match the message to a row, apply the fix, retest.

That last row is the one that bites WordPress sites hardest. An SEO plugin and a theme both writing Organization markup will fight, and the test shows you the result without telling you there are two authors.

If you are building a block from scratch rather than debugging one, our schema markup generator produces a valid block you can paste straight into the Code tab and check before it ever reaches the site.

One placement note for WordPress. Put the finished block in your SEO plugin's custom schema field, or in the theme head. Plenty of security and optimisation plugins strip scripts from post bodies — this site runs one — and a block that was stripped looks identical to a block that was never added.

Warnings: which to fix, which to leave

A warning never blocks eligibility. It tells you the rich result can be built, but will be built with less in it.

So the test is simple: would a searcher notice the missing property?

• Fix it when the property is something that shows — an image, a price, a date, a rating, a brand. A thinner rich result competes worse than a complete one.
• Leave it when the property genuinely does not apply to your page. A warning is not a scorecard.
• Never invent a value to clear one. Google's general structured data guidelines require markup to represent the page's visible content. Marking up something that is not there is a guidelines problem, not a warning fix.

Why the test passes and the rich result still does not show

This is the question we get asked most, and the markup is usually not the answer.

In our own work on client schema, when a block validates cleanly and nothing appears in Search, we check four things in this order before touching the markup again:

1. Is the URL even indexed? The Rich Results Test will validate a noindex page without complaint — it does not check indexing at all. Run the URL through URL Inspection in Search Console first. No index, no rich result, no exceptions.
2. Does that type still produce a rich result? FAQ and HowTo are both gone. Several supported types are machine-readable context rather than a visible feature. A pass on a withdrawn feature is a pass on nothing.
3. Is the item type eligible? Review snippets, for one, apply only to Book, Recipe, Movie, Product, Software App and Local business. Review markup on a services page earns nothing however valid it is.
4. Has Google recrawled since the change? Check the last crawl date in URL Inspection, then look at the matching rich result report in Search Console. A fix made yesterday is not a fix Google has seen.

Only after those four do we question the markup itself. More often than not, the markup was never the problem.

There is also a harder truth. Valid structured data makes a page eligible for a rich result. Google decides whether to show one, per query, per device. No testing tool can promise a SERP appearance, and anyone who tells you otherwise is selling something.

Worth separating too: a rich result is not a featured snippet. Snippets are extracted from your text and need no markup at all. Different mechanism, different work.

JavaScript-injected schema behaves differently

The test renders the page, so JSON-LD written by JavaScript is usually found. That is not the same as Googlebot finding it in production.

Where the two diverge:

• Timing. The test renders on demand, now, with a fresh fetch. Live rendering is queued and happens when Google's resources allow. A block that arrives late can be missed in production and still pass here.
• Blocked resources. If the script that writes your schema is disallowed in robots.txt, the test flags it under page resources — and Googlebot hits the same wall. Our technical SEO guide covers the crawl-access side.
• Dependencies. Schema injected through a tag manager depends on the container loading and the tag firing. One consent banner, one script error, and the block is not there.
• Server-rendered is deterministic. The block is in the first HTML response. Nothing has to run for Google to see it.

Quick way to tell which you have: compare the rendered HTML in View tested page against your page source. In the rendered HTML but not the source means JavaScript put it there.

Server-render it where you can. Where you cannot, test with the smartphone agent, retest after every theme and plugin update, and put "retest schema on changed templates" into your site audit checklist. Also confirm the page is discoverable in the first place — a URL missing from your XML sitemap and unlinked internally may never get crawled, markup or no markup.

Where to take this next

The Rich Results Test is a pre-flight check, not a monitor. It looks at one URL, once, right now.

Monitoring is Search Console's job. The working loop is: generate the block, test it in the Code tab before publishing, publish, request indexing, watch the matching rich result report for valid and invalid counts, then retest after any template change.

One last thing it is not. Google's guidance on its AI experiences (Search Central, last updated 10 July 2026) states there are no additional technical requirements and no special structured data needed to appear in AI Overviews or AI Mode. Structured data governs rich-result eligibility. Treating this tool as an AI-visibility checker is a category error.