Rich Results Test vs URL Inspection

Choose the right tool for testing live markup, indexed markup, rendering, and eligibility.

Partially automatable Intermediate

Use the Rich Results Test to debug the structured data in a live URL or code sample, including pages outside properties you control. Use URL Inspection when you need to know what Google stored for a URL in your Search Console property, compare that indexed evidence with a live fetch, diagnose indexing, or request recrawling.

The tools overlap on live structured-data testing, but they answer different questions. Neither guarantees that a valid item will appear as a rich result.

This comparison reflects Google's documentation on July 18, 2026.

Quick decision table

Question	Use
Can this code qualify for a Google-supported rich result?	Rich Results Test with a code sample
What does the current public page render for Google?	Rich Results Test or URL Inspection live test
Can I test a page outside a property I own?	Rich Results Test
What structured data was in Google's indexed version?	URL Inspection indexed view
Is the URL indexed, and which canonical did Google select?	URL Inspection indexed view
Did a deployed fix reach the live page but not Google's index yet?	Compare URL Inspection live and indexed views
Can Google fetch the page and its important resources now?	Either live test; URL Inspection gives broader indexing context
Can I request indexing after a fix?	URL Inspection
Can I preview a supported rich-result layout?	Rich Results Test, for types with a preview
Can I inspect indexed rich-result evidence by API?	URL Inspection API
Can the API run a live test?	No

Rich Results Test: a live markup debugger

The Rich Results Test evaluates a URL or pasted code against Google's supported rich-result requirements.

It is best for:

Developing new JSON-LD, Microdata, or RDFa.
Testing markup before the page is indexed.
Debugging a page outside a Search Console property you can access.
Locating errors in rendered source.
Checking smartphone and desktop rendering.
Previewing some supported rich-result layouts.
Sharing a reproducible test with a developer.

Test a URL

Enter a fully qualified public URL and choose the smartphone or desktop user agent. Smartphone is the default.

The tool fetches as Google-InspectionTool, without the credentials of a logged-in visitor. The page and important resources must therefore be accessible without authentication and not blocked for that user agent by robots.txt.

The result can show:

Whether the page was fetched.
Which Google-supported rich-result item types were detected.
Valid items, warnings, errors, and unparsable data.
Rendered source with issue locations.
Loaded-resource problems.
A preview for some feature types.

This is current test evidence, not proof of what was present during Google's last indexing crawl.

Test code directly

Choose Code to paste and edit a markup sample. This is the fastest option when:

A page is not public yet.
A staging environment requires authentication.
A developer is isolating a syntax or property error.
The full page has unrelated rendering failures.

A passing code sample does not prove that production emits the same markup. After deployment, test the real URL and inspect rendered output.

The test ignores comments inside JSON-LD code blocks, but JSON-LD itself does not support those comments. Remove them before publishing even if the test appears to accept the sample.

It tests Google features, not all schema.org markup

The Rich Results Test reports types supported for Google rich results. A valid schema.org object can be absent if Google does not test that type for a Search feature.

Use the Schema Markup Validator for generic schema.org vocabulary and syntax. Use the Rich Results Test for Google-specific eligibility rules.

URL Inspection: indexed evidence plus a live test

URL Inspection works on a fully qualified URL inside the currently selected Search Console property. The account needs access to that property.

Its default result describes Google's indexed version, not necessarily the page served now.

It is best for:

Confirming whether a URL is indexed.
Seeing Google's last crawl time and stored fetch evidence.
Comparing the user-declared and Google-selected canonical.
Reviewing detected enhancements and their issues in the indexed page.
Checking rendered HTML and resources from Google's stored crawl when available.
Running a live test after a fix.
Requesting indexing for a changed URL.

Indexed view

The indexed view answers “What did Google process?” It can show:

Overall indexed status.
Page fetch and indexing information.
Last crawl time and crawler type.
Referring URLs and known sitemaps when available.
User-declared and Google-selected canonicals.
Detected structured-data sections and issues.
Stored HTML, HTTP information, JavaScript output, and resources for eligible results.

If the page changed after the reported last crawl, the indexed evidence is expected to be stale. That is precisely why it should be compared with a live test.

Live test

Select Test live URL to fetch and examine the current page. The live result can evaluate access, page fetch, indexing directives, structured data, linked AMP, and other supported checks.

A positive live result means Google could fetch and parse the tested version under the checks performed. It does not mean the page is indexed or will be selected for indexing.

The live test cannot reproduce every indexing decision. In particular, it cannot predict Google's canonical selection and does not check every policy, quality, manual-action, removal, security, or temporary-block condition. It also has a per-property daily usage limit.

Request indexing

After a meaningful fix or update passes the live test, URL Inspection can submit an indexing request. The request joins a crawl queue; it does not guarantee immediate crawling, indexing, or rich-result display.

Do not use repeated requests as a substitute for fixing access, rendering, canonical, or markup problems.

Evidence hierarchy

The tools produce three distinct evidence states.

Evidence	What it represents	What it cannot establish
Rich Results Test code	The pasted markup under the test's current rules	Production rendering, indexing, or display
Live URL test	A fetch and render performed now	What Google has indexed or will select
URL Inspection indexed view	Google's processed evidence from the reported crawl	What the page serves after that crawl

Name the evidence state in every bug report. “Google says the schema is invalid” is ambiguous unless the report records the tool, exact URL or code, user agent, test time, and indexed last-crawl time.

Side-by-side capabilities

Capability	Rich Results Test	URL Inspection indexed view	URL Inspection live test
Requires Search Console property access	No	Yes	Yes
Tests pasted code	Yes	No	No
Tests a current URL	Yes	No	Yes
Shows indexed evidence	No	Yes	No
Shows Google-selected canonical	No	Yes	No
Shows rich-result issues	Yes	Yes, for stored page	Yes
Shows page indexing context	Limited access checks	Yes	Potential indexability only
Can request indexing	No	From the inspection workflow	From the inspection workflow
Can preview some rich results	Yes	No	No
Can test an unverified external URL	Yes	No	No
Available through the Search Console API	No public endpoint	Yes	No

A dependable development-to-index workflow

1. Validate the data model

Read the current Google documentation for the intended feature. Identify required properties, nested types, content rules, and supported values.

Schema.org defines a vocabulary; Google's feature documentation defines Google Search eligibility.

2. Test an isolated sample

Use Rich Results Test Code mode to remove syntax and type errors quickly. Confirm that every value is truthful and matches the content users will see.

3. Test the rendered development page

Test a public staging URL or expose an appropriate temporary tunnel. Compare the rendered source with the intended markup and review blocked or failed resources.

Do not publish a secret URL in a shared test result. Rich Results Test result links can be viewed by anyone who has the link and are retained for roughly 90 days.

4. Test the production URL

After deployment, run the Rich Results Test against the exact production URL. Test all important template states rather than one ideal example.

For a commerce template, that could include in-stock, out-of-stock, sale-priced, variant, and no-review products. For an events template, include current, postponed, and expired events.

5. Inspect the URL in Search Console

Open URL Inspection and record:

Indexed status.
Last crawl time.
Google-selected canonical.
Indexed structured-data result.

Then run the live test and compare its detected items with the indexed view.

6. Request indexing only when appropriate

If the live production page is correct and the indexed version is stale, request indexing for a small number of important URLs or allow normal crawling through internal links and sitemaps.

For template-wide changes, do not manually submit every URL. Fix the template, keep sitemaps accurate, and use the relevant rich-result report's validation workflow after representative live checks pass.

Interpret common disagreements

Rich Results Test passes; indexed URL Inspection fails

Most likely, the live page changed after Google's last crawl.

Check:

The indexed last-crawl time.
Whether both tests used the exact same canonical URL.
URL Inspection's live result.
Whether the structured data depends on user state or intermittent JavaScript.

If the live tests pass consistently, the next step is recrawling and monitoring—not another markup rewrite.

Indexed URL Inspection passes; the live test fails

Google's stored version was valid, but the current page has a new problem. Treat this as a regression before it reaches more indexed pages.

Check recent releases, feature flags, CMS data, resource availability, and rendering timeouts.

The Rich Results Test finds an item; URL Inspection live test does not

Google states that URL Inspection's live test should ordinarily produce the same result as the standalone live testing tool. First verify:

Exact URL, including host, protocol, path, parameters, and redirect target.
Smartphone versus desktop user agent.
Test timestamps.
Intermittent server or resource failures.
Personalized, geolocated, consent-dependent, or randomly injected markup.
Whether both tools loaded the same rendered resources.

Repeat sparingly and inspect rendered HTML. Non-deterministic markup is a production defect even if one run passes.

Both live tools pass; no rich result appears in Search

Passing establishes technical eligibility for tested requirements, not display.

Check:

Whether the page is indexed and canonicalized as intended.
Feature-specific content and quality policies.
Structured-data manual actions.
Whether markup represents visible main content.
Whether Google supports and selects the feature for the query, country, and device.
Performance report Search appearance data.

Do not keep adding optional properties merely to force display.

No items are detected

Inspect rendered source rather than only the original server response.

Possible causes include:

Markup not emitted on the tested template state.
JavaScript failure or late injection.
Blocked scripts or APIs.
Invalid top-level JSON-LD.
A schema.org type unsupported by the Google test.
Testing a redirect or unexpected canonical page.
Markup available only after login, consent, or interaction.

The code test passes, but the URL test fails

The isolated snippet is valid, but the page integration is not.

Look for duplicate scripts, invalid escaping by the template, truncated JSON, conflicting items, incorrect dynamic values, or resource-loading failures.

Rendered HTML and resources matter

Both live tools use Google-InspectionTool and render pages. A correct JSON-LD template in source control can still fail if production:

Escapes quotes or Unicode incorrectly.
Emits empty values.
Loads product or event data too late.
Blocks an API or script required to generate markup.
Serves different output by device or geography.
Times out under crawler traffic.

Use the code explorer and View tested page information to inspect the output Google actually received. A screenshot is available for live URL Inspection, not its indexed view.

Automation boundaries

The URL Inspection API returns indexed-version evidence, including richResultsResult when rich results are found. It can report detected item types and warning or error issues for a sampled URL.

The API cannot:

Run a live inspection.
Submit pasted code to the Rich Results Test.
Request indexing.
Replace a property-level rich-result report.
Prove that a valid item was displayed.

Use automated schema validation and rendered-page tests in continuous integration, then use the URL Inspection API for governed samples of important indexed URLs. Keep interactive live testing for releases, regressions, and ambiguous cases.

What neither tool proves

Neither tool can prove:

That Google will index the page.
That Google will select the declared canonical.
That a rich result will appear.
That the page complies with every quality or content policy.
That structured data caused a ranking or CTR change.
That every URL sharing the template is valid.
That a future documentation change will preserve eligibility.

Treat a passing result as one technical checkpoint, not a launch guarantee.

Troubleshooting checklist

The exact URL and property are recorded.
The intended Google feature is currently supported.
Required properties follow current Google documentation.
Code mode passes before page integration.
The production URL passes with the intended user agent.
Rendered output, not only raw source, is reviewed.
Important resources are accessible to Google-InspectionTool.
Indexed last-crawl time is compared with the deployment time.
Live and indexed results are labeled separately.
Google-selected canonical is checked in indexed URL Inspection.
A recrawl is requested only after the live page is correct.
Search appearance data is used for display evidence.
Passing validation is not described as guaranteed visibility.