Google Rich Results Test: How to Run It and Fix Errors

You've added JSON-LD to a product page, marked up a recipe, or built out a job listing, and now you want to know if any of it actually works. The Google Rich Results Test is the tool built for that exact question: hand it a URL or a code snippet, and it tells you which rich result types your structured data qualifies for, and what's wrong with the rest.

The Google Rich Results Test checks a URL or a code snippet against the structured data types Google can turn into rich results, then reports each item as valid, valid with warnings, or invalid. Errors disqualify a page from a rich result; warnings only limit how it appears. Fix errors first, then rerun the test to confirm.

Prerequisites

• A page that already has structured data on it, in JSON-LD, Microdata, or RDFa, or a code snippet you want to check before it goes live.
• If you're testing a live URL, every resource the page loads (images, CSS, scripts) needs to be reachable by an anonymous visitor from the public internet. A page behind a login or a firewall won't test correctly unless you expose it through a tunnel first.
• A browser and the tool itself, at search.google.com/test/rich-results.
• Search Console access to the site if you also want to check the Manual Actions report for a structured data penalty.

Step 1: Open the Google Rich Results Test and choose what to check

The tool gives two ways in. On the landing page, choose URL and submit the full address of the page, or choose Code and paste a structured data snippet directly into the box.

Testing a URL is closer to how Google sees the page in practice, because the tool fetches it as Google-InspectionTool, not with your own browser session. Anything that needs a login or sits behind a firewall won't load, so a page only available locally or behind access control needs a tunnel before it will test.

Testing a code snippet is faster while you're drafting. Paste the markup, click Run test, edit it, and run it again as many times as needed, without the page needing to be live anywhere. The tool accepts structured data written in JSON-LD (Google's recommended format), Microdata, or RDFa.

A trimmed example of what you'd paste into the Code tab, a Recipe with its rating nested inside, looks like this:

{
  "@context": "https://schema.org/",
  "@type": "Recipe",
  "name": "Banana Bread Recipe",
  "image": ["https://example.com/photos/1x1/photo.jpg"],
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 4.7,
    "ratingCount": 123
  }
}

Two settings to set deliberately before you run it:

• User agent. Test as a smartphone or a desktop crawler; smartphone is the default, since Google says that's how most people browse now.
• Comments in JSON-LD. The test ignores comments inside a JSON-LD block, but the JSON-LD standard doesn't support them. Markup that passes with comments left in can still break once something other than this tool parses it, so strip comments before publishing.

Step 2: Read the URL status and the crawl results

The test opens with one status line for the whole URL: something like "N valid items detected," "N valid items with warnings," "N items detected: some are invalid," or "URL cannot be crawled." That line tells you whether to keep reading or go fix access first.

Below it is a crawling section, because the test can only check what Google can reach:

• Crawled successfully / Crawl failed: whether Google could access the page at all.
• Crawled as: smartphone or desktop, matching the user agent you picked.
• Crawl allowed?: whether a robots.txt rule blocks this specific page.
• Page fetch: whether the test could retrieve the page; this always fails if crawling failed.

If a robots.txt rule or a noindex tag keeps Google out of the page during its regular crawl, the tool has nothing to parse and can't test the page at all. That's worth ruling out before debugging markup that was never going to be seen. A site audit that crawls every page for indexability, alongside duplicate titles and broken internal links, catches this earlier than a one-page test does; SEOAgent's site audit runs that check across a whole site in one pass.

Step 3: Separate errors from warnings

Under "detected structured data," the tool lists every item it found, each one valid, valid with warnings, or invalid. This distinction decides what happens in Search:

• Errors disqualify the item. A page with an error in its Recipe markup won't get the recipe rich result at all.
• Warnings only limit it. A missing image property, for instance, can still leave the page eligible for the rich result; it just shows up without an image.

Click a flagged item to expand it, then click the description to jump to that exact spot in the page's rendered source. For malformed JSON-LD, the tool groups failures as "syntax errors in items of unknown type" before it can even work out what rich result type the markup was meant for. Common causes include a missing colon or comma, a value of the wrong type (a string where a number was expected), a bad or empty escape sequence inside a string, two definitions of the same unique property (two @context values, for example), and a broken Unicode escape sequence. Fixing the raw JSON syntax first, then rechecking the schema.org fields, is usually faster than debugging both at once.

Passing the test isn't the same as meeting Google's general structured data guidelines, which the tool doesn't check for automatically: mark up only content that's visible on the page, keep the data relevant to what the page is actually about, fill in every required property for that type, and if you mark up multiple reviews or items, include all of them rather than a convenient subset. Breaking these rules can still cost a page its rich result, or in serious cases trigger a manual action, which strips a page's rich-result eligibility without changing how it ranks in ordinary web search.

Step 4: Clear resource and access errors

Sometimes the test can't reach the page at all. Google names the specific failure instead of leaving you to guess:

You can check robots.txt availability directly in Search Console's Crawl Stats report.

A related warning covers resources the page depends on, such as images, CSS, or scripts, that the test couldn't load, usually because the resource took too long, returned a 404, sits behind a login, or is blocked from Google-InspectionTool by robots.txt. These are worth chasing: a blocked large image can make a page look mobile-friendly to Google when it actually isn't, and a blocked CSS file can cause the wrong font styles to apply, which changes how Google understands the page. If the test returns slightly different results on repeat runs with nothing changed, check for a "page loading issues" warning; it usually means a resource is loading inconsistently.

Step 5: Preview, save, and share the result

For some rich result types, the test shows a preview of how the result could look in Google Search or Google Assistant, with separate desktop and mobile views where more than one layout applies. You can edit the code and rerun the test to see how a change affects the preview. Google says plainly that this isn't a guarantee: the actual result shown to a real user depends on their search history, location, and other factors the test doesn't simulate.

Two more things worth knowing:

• History. Search Console saves your code and test state every time you run it. Bookmark the result page's URL afterward to keep a version you can return to; Google keeps that history for about 90 days, and anyone with the bookmarked link can open it, so don't bookmark a test that contains anything sensitive.
• Sharing. The Share button gives you a link to the result that anyone can open without permissions, also valid for about 90 days, which is useful for handing a result to a developer or client without a back-and-forth over screenshots.

Common mistakes

• Testing a page Google can't crawl. If robots.txt or noindex blocks the page, the test can't see it either; fix access before you touch the markup.
• Leaving comments in JSON-LD. The test tolerates them; the JSON-LD standard and other parsers don't.
• Treating every flag as a blocker. Warnings limit a rich result's appearance; only errors disqualify it. Fix errors first.
• Marking up content users can't see, or content unrelated to the page. Google's guidelines call this out directly, and it risks a manual action even when the test shows no errors.
• Partial markup on multi-item pages. If a page displays five reviews, the structured data should describe all five; describing only the best ones is the kind of mismatch Google's guidelines flag.
• Assuming a clean result guarantees a rich result. Google deprecated the FAQ rich result on 7 May 2026 (the notice was added 8 May 2026) and later pulled its documentation entirely. FAQPage markup can still test clean without that feature ever showing in Search again, so check the structured data gallery for which types are still active before you invest time marking one up.

What's new (as of 22 October 2026)

Google now tells site owners to start with the Rich Results Test for Google's own rich results, and to use the Schema Markup Validator separately for generic schema.org validation that isn't Google-specific. That split exists because the old Structured Data Testing Tool had its Google-specific checks removed and the tool itself moved to the validator.schema.org domain, so it's no longer where you'd check whether markup qualifies for a Google rich result.

Two structured data types tested through these tools picked up documentation changes recently. On 24 September 2026, Google added a creator property to VideoObject structured data (alongside existing support for author) and clarified which interaction types interactionStatistic supports. On 24 July 2026, Google added a new review snippet guideline specifically about fake and undisclosed incentivized reviews. Neither change affects how the Rich Results Test itself works, but both affect whether markup that tests clean should actually be published.

Once a page's markup passes the test cleanly, see how structured data works across the rest of the site to find which pages are worth marking up next.

Key takeaways

• The Rich Results Test checks a URL or a code snippet and reports each structured data item as valid, valid with warnings, or invalid.
• Errors disqualify a page from a rich result; warnings only limit how the result appears, so fix errors first.
• A robots.txt rule or noindex tag that blocks Google from crawling a page also blocks the test from checking it, since there's nothing left to parse.
• Passing the test isn't the same as meeting Google's quality guidelines, which cover relevance, completeness, and visible content, and aren't checked automatically.
• Use the Rich Results Test for Google-specific rich result eligibility, and the Schema Markup Validator for general schema.org validation.

FAQ

What's the difference between the Rich Results Test and the Schema Markup Validator?

The Rich Results Test checks structured data against the specific types Google can turn into rich results and tells you which ones your markup qualifies for. The Schema Markup Validator checks structured data against the full schema.org vocabulary without any Google-specific rules, which makes it the better choice when you're validating markup that isn't meant to produce a Google rich result at all.

Why does the Rich Results Test say my URL can't be crawled?

This usually means Google is blocked from the page by a robots.txt rule or a noindex directive, or the test hit a server-level problem such as a DNS error, an invalid SSL certificate, or a server that refused the connection. Since the tool fetches the page the same way Google's crawler does, any access restriction that stops Googlebot also stops the test.

Do warnings in the Rich Results Test stop my page from getting a rich result?

No. A warning means the markup is valid but something is missing or suboptimal, such as a missing image property, and the page generally stays eligible for the rich result, just without that element. Errors are the ones that disqualify a page outright.

Does passing the Rich Results Test guarantee my page will show a rich result?

No. The test confirms the structured data is technically valid and eligible, but Google decides whether and how to display a rich result for a given search based on the query, the user, and other factors the test can't simulate. Google's own guidance says directly that it doesn't guarantee a page will appear exactly as previewed.

Is the Structured Data Testing Tool still available?

Google removed the Structured Data Testing Tool's Google-specific validation and migrated the tool to the Schema Markup Validator at validator.schema.org. To check eligibility for a Google rich result, use the Rich Results Test instead.