URL Inspection: complete guide

Compare Google's indexed version with a live test and inspect crawl, canonical, and enhancement evidence.

Automatable now Intermediate

URL Inspection answers two different questions about one URL:

Google Index: What does Google's stored indexing evidence say about the URL?
Live test: Can the Google Inspection Tool fetch and parse the current public version?

These views are complementary, not interchangeable. A page can pass the live test and remain unindexed because the test does not evaluate every indexing condition. It can also be indexed while the current live page is broken because Google has not processed the new failure yet.

This guide reflects Google's documentation as verified on July 18, 2026.

Open the correct URL and property

Enter the fully qualified URL in the inspection bar at the top of Search Console, or use an Inspect link beside a URL in another report.

The URL must belong to the currently selected property. Common mistakes include:

Inspecting https:// in an http:// URL-prefix property.
Inspecting www in a non-www URL-prefix property.
Omitting the path covered by a path-scoped property.
Inspecting a parameter, slash, case, locale, or hostname variant instead of the intended canonical URL.

A Domain property covers protocols and subdomains, but always record the exact URL tested. Canonicalization happens at URL level, not at the display name of the property.

Search Console applies per-property daily limits to index inspections and live tests. Use representative sampling rather than inspecting thousands of URLs manually.

Google Index versus Live test

Evidence	Google Index view	Live test
Source	Google's stored indexing systems	A current fetch by Google-InspectionTool
Main purpose	Explain the URL's indexed or non-indexed state	Test current technical indexability
Last crawl evidence	Yes	Test time only
Discovery sitemaps and referring pages	Can be shown	Not checked
Google-selected canonical	Can be shown	Cannot be predicted
User-declared canonical	Stored evidence	Current page can be examined
Rendered screenshot	Not available	Available after a successful live test
Loaded resources, HTML, headers	Available for supported indexed results	Available for successful test
Duplicate/alternate decision	Reflected in indexed status	Not tested
Manual actions, security issues, removals	Not comprehensively tested	Not tested
Quality sufficient for indexing	Not a published score	Not determined
Video indexed	Indexed evidence can show video status	Detects a video but not whether it is indexed

The live test does not update Google's index. Google explicitly says it does not use live-test information. Requesting indexing is a separate action.

Read the Google Index view

Overall verdict

URL is on Google means the URL is indexed and eligible to appear, subject to caveats. It does not guarantee that the URL appears for a particular query, location, device, or even an exact-URL search at every moment.

URL is on Google, but has issues normally means the page is indexed but an enhancement—such as structured data or an associated AMP page—has a problem. Separate indexing eligibility from rich-result eligibility.

URL is not on Google means the inspected URL is not indexed. Read the Page indexing reason rather than treating the verdict as the diagnosis.

An alternate or duplicate can correctly be absent while its canonical is indexed. Inspect the canonical separately.

Discovery

The indexed evidence may list:

Known sitemaps containing the URL.
Referring pages through which Google discovered it.

These fields are evidence, not exhaustive inventories. A missing sitemap or referring page does not prove none exists. Google can discover URLs through links, sitemaps, redirects, feeds, previous crawls, and other sources.

Use the fields to find obvious contradictions:

A noncanonical URL remains in a submitted sitemap.
A new canonical URL has no normal internal discovery path.
Old templates keep linking to a redirect or removed URL.

Crawl

Record:

Last crawl: When Google last fetched the version represented by this indexed evidence.
Crawled as: The crawler type used.
Crawl allowed?: Whether robots.txt permitted the request.
Page fetch: Whether Google successfully retrieved the page.
Indexing allowed?: Whether a noindex directive prevented indexing.

The last crawl date is essential when a current page differs from the report. If the site changed after that timestamp, the indexed result can legitimately show the old state.

Indexing and canonicals

Compare:

User-declared canonical: The preference expressed by the site.
Google-selected canonical: The representative Google selected for the cluster.

Possible interpretations:

User-declared	Google-selected	Interpretation
Same URL	Same URL	Signals and selection agree
None	Suitable other URL	Google consolidated an undeclared duplicate; often acceptable
Preferred A	Different B	Investigate similarity, accessibility, and conflicting signals
Self	Different URL	Self-canonical was treated as a hint and did not override other evidence

The Google-selected canonical is available only from indexed evidence. The live test cannot calculate it. If the canonical belongs to a property you cannot inspect, some detail may be unavailable.

Enhancements and experience

The tool may show detected structured data, linked AMP, video evidence, and other applicable enhancements. Interpret each panel separately:

A valid page is not guaranteed a rich result.
A structured-data warning usually preserves eligibility but identifies recommended information.
An error can make the affected enhancement ineligible without removing the ordinary web result.
A live test detects current markup; indexed evidence describes what Google processed previously.

Use the report dedicated to that enhancement to understand site-level patterns.

Run and interpret the live test

Click Test live URL when you need to know what the tool can access now—for example after fixing a response, robots rule, noindex, rendering issue, or structured-data error.

Review:

URL availability. Can the current URL probably be indexed technically?
Crawl allowed? Does robots.txt permit the request?
Page fetch. Did the test receive a usable response?
Indexing allowed? Is a noindex directive present?
Crawled as. Which Inspection Tool user agent ran the test?
Test time. When this evidence was generated.
Enhancements. Which current structured-data or AMP issues were found?

What a successful live test proves

It shows that Google-InspectionTool could fetch and parse the tested destination at that time and found no tested technical blocker to indexing.

What it does not prove

The live test does not determine:

Whether Google will crawl or index the page.
Whether Google will select it as canonical.
Whether the page is a duplicate or alternate.
Which sitemap or referring page led to discovery.
Whether content quality is sufficient for indexing.
Whether a manual action, security issue, legal removal, temporary Search Console removal, or other policy condition applies.
Whether a detected video is indexed.

If the URL redirects, the live test follows the redirect and tests the destination without showing which final URL it tested. Inspect the destination directly and trace redirects independently.

Inspect rendered output

After a successful live test, choose View tested page and review:

Screenshot.
Rendered HTML.
HTTP response headers.
Loaded and failed resources.
JavaScript console messages.

Ask:

Is the primary content visible in the screenshot and rendered HTML?
Did a consent screen, login, error, geographic block, or bot challenge replace it?
Did essential JavaScript, CSS, image, API, or font resources fail?
Are title, meta robots, canonical, structured data, and links present after rendering?
Does the result match a signed-out user's page?
Does the response contain a successful status and correct content type?

A screenshot is available only for a successful live test. Absence of a screenshot for indexed evidence is normal.

Do not judge responsive layout or Core Web Vitals from the screenshot. Use the appropriate performance tools and field data for those questions.

A reliable debugging workflow

1. Define the intended outcome

Should this exact URL be indexed, or should it redirect, canonicalize, return 404, require login, or remain noindex? Without an intended state, every exclusion looks like an error.

2. Read historical indexed evidence

Record the verdict, reason, last crawl, discovery, fetch result, declared canonical, selected canonical, and relevant enhancements.

3. Compare with deployment history

Determine what changed after the last crawl: template, CMS, CDN, firewall, redirects, directives, JavaScript, content, URL structure, or sitemap.

4. Test the live URL

Confirm current access and rendering. If the live result fails, fix the concrete issue before requesting indexing.

Inspect the canonical, redirect destination, mobile/AMP variant, localized alternate, and a few pages from the same template. A problem affecting a component should be fixed at component level.

6. Use the correct site-level report

Page Indexing for URL cohorts and validation.
Crawl Stats for host availability and request patterns.
Sitemaps for fetch and parsing evidence.
Rich-result reports for markup groups.
Manual Actions, Security Issues, and Removals for conditions URL Inspection does not fully test.

7. Request indexing only when justified

After an important page has been substantively added or fixed, a single request can place it in the crawl queue. It cannot override a blocker or guarantee indexing.

Common scenarios

Indexed view fails, live test succeeds

Likely explanations include a fix deployed after the last crawl or a transient historical failure. Confirm the last crawl predates the fix. Request indexing for an important URL, or let Google recrawl normally.

Indexed view succeeds, live test fails

The live site may have broken after Google's last processed version. Treat this as urgent for important pages: users and the next crawl can encounter the failure.

Live test succeeds, URL remains unindexed

The page is technically accessible, but untested conditions remain. Review duplicate/canonical evidence, content purpose and usefulness, discovery, manual actions, removals, and site-wide indexing patterns. Repeated live tests do not change the decision.

Google selected another canonical

Inspect the selected URL. Compare redirects, canonicals, internal links, sitemaps, hreflang, accessibility, and primary-content similarity. If both pages should be indexed, make their purposes and content substantially different.

Page is indexed but cannot be found for a query

Indexing and ranking are different stages. Use the Performance report and inspect the actual result environment. “URL is on Google” does not guarantee rankings.

URL not known to Google

Confirm crawlable internal links and an accurate sitemap. A live test can show current accessibility, but it does not show that Google has discovered or scheduled the page.

Automate index evidence with the API

The URL Inspection API can return the status of the version in Google's index for URLs within an authorized property. It does not run live tests and cannot submit indexing requests.

It can return fields such as:

Coverage state and verdict.
Robots and indexing state.
Last crawl time and crawler.
Page fetch state.
User and Google canonicals.
Known sitemaps and referring URLs.
Applicable rich-result and AMP analysis.

Current documented index-inspection quotas include 2,000 queries per day and 600 per minute per site, with separate project limits. Quotas can change, so read the official limits before designing a monitor.

Use the API for representative inventories, template sampling, migrations, and scheduled audits—not as proof that every URL has been exhaustively checked.

Common mistakes

Reading the default indexed view as if it were live.
Treating a successful live test as a promise of indexing.
Using the live test to “verify” canonical selection.
Ignoring the last crawl date when comparing old and new behavior.
Inspecting only the submitted URL when it redirects or canonicalizes elsewhere.
Assuming discovery fields are exhaustive.
Confusing enhancement errors with web-index exclusion.
Requesting indexing before removing robots, noindex, access, response, rendering, or canonical problems.
Testing one URL when a template or host is failing.
Automating the UI when the official API can return indexed evidence safely.