Article No. 42

How to Use the Google Search Console URL Inspection Tool

Abstract

The URL Inspection tool in Search Console shows what Google actually knows about one specific URL: whether it's indexed, what Google saw the last time it crawled the page, and...

On this page

The URL Inspection tool in Search Console shows what Google actually knows about one specific URL: whether it’s indexed, what Google saw the last time it crawled the page, and whether the live version passes basic indexability checks right now. It’s a per-URL diagnostic, not a site-wide report. For patterns across many URLs at once, the Page Indexing report is the right tool; URL Inspection is where a site owner goes when a specific page needs answers.

This guide covers the tool’s UI and workflow only: what each field means, the distinction that causes most of the confusion around it, and how Request Indexing actually behaves. It doesn’t cover Googlebot’s crawling mechanics generally, or the full exclusion-reason taxonomy in the Page Indexing report; those live elsewhere.

Accessing the Tool

A URL can be inspected two ways: typing the fully-qualified URL into the inspection bar at the top of any Search Console screen, or clicking an “Inspect” link next to a URL inside another report (Page Indexing, Sitemaps, and others surface this link contextually). Inspection is scoped to whichever property is currently selected, and works for any URL within that property, indexed or not.

Indexed Version vs. Test Live URL: The Core Distinction

This is the single most important thing to understand about the tool, and the source of most user confusion. When a URL is inspected, Search Console first shows the Google index view: a snapshot of what Google saw and recorded the last time it crawled that URL, which could be hours or weeks old depending on how often the page gets crawled. Separately, clicking Test Live URL sends a fresh, real-time fetch and evaluates the page as it exists right now.

These two views can disagree, and often do. A page that was fixed an hour ago might still show as blocked or non-indexable in the Google index view, because that view reflects the last crawl, not the current state. A page that’s currently broken might still show as indexed and healthy in the Google index view, because Google hasn’t recrawled it since the problem started. Testing the live URL is the only way to confirm whether a recent fix actually resolved an issue; checking only the indexed version after making a change will often just show the old, pre-fix state.

Reading the Report: Field by Field

Field What it shows
Coverage status Whether the URL is indexed, and if not, which exclusion reason applies (points to the Page Indexing report's taxonomy for the full list)
Sitemaps Which submitted sitemap(s), if any, reference this URL
Referring page A page Google discovered this URL through, when available
User-declared canonical The canonical URL specified in the page's own markup
Google-selected canonical The canonical URL Google actually chose to index, which can differ from the user-declared one if Google judged another URL to be the better representative
Crawled as Whether Googlebot Smartphone or Googlebot Desktop performed the crawl (effectively always Smartphone today)
Page fetch Whether the most recent crawl attempt succeeded, and if not, why

The gap between user-declared and Google-selected canonical is worth watching closely. When they differ, it usually means Google judged the page to be a near-duplicate of another URL and picked the version it considered more authoritative, sometimes correctly, sometimes not. A pattern of Google overriding a site’s declared canonicals across many URLs is a signal worth investigating rather than a one-off quirk.

The Page fetch field is where most crawl-side surprises show up. A status of “Failed: Not found (404)” or “Failed: Server error (5xx)” here explains, in plain terms, why a page might be missing from the index even when everything else about it looks fine. “Failed: Blocked by robots.txt” points back to a robots.txt rule as the actual cause, which is a faster diagnosis than working backward from the Page Indexing report alone for a single URL a site owner already has in mind.

Testing a Brand-New Page

For a URL that hasn’t been crawled yet at all, inspecting it returns a straightforward “URL is not on Google” result with no historical data to show, since there’s no prior crawl to report on. Running Test Live URL in this case still returns useful information: whether the page is currently reachable, whether it would pass basic indexability checks (no unintended noindex tag, no accidental robots.txt block), and a rendered screenshot of what Googlebot currently sees. This is the right moment to catch a launch-time mistake, an accidentally-inherited staging noindex tag being the most common one, before requesting indexing and waiting on a full crawl cycle to discover the same problem days later.

Using Request Indexing Correctly

The Request Indexing button submits a URL into Google’s crawl queue with elevated priority; it is not an instant re-crawl and it does not bypass normal processing. In practice, expect the live test itself to complete in something like seconds to a couple of minutes, but the actual crawl and indexing of the URL afterward can still take anywhere from under a day to well over a week, depending on the site’s overall crawl demand and the URL’s history.

Google has acknowledged that Request Indexing is subject to a daily quota per property, but has not published an exact number in its current official documentation. Any claim online of a specific figure like “10 to 50 requests per property” is an unofficial estimate based on user reports, not a Google-confirmed limit. The accurate framing: Google enforces an undisclosed daily quota on manual indexing requests, and once it’s hit, the Request Indexing option becomes unavailable until it resets, typically after about 24 hours.

Request Indexing is appropriate for a handful of specific, already-fixed URLs, not as a substitute for solving an underlying crawl or content problem across many pages. Submitting the same broken URL repeatedly without fixing the underlying issue does nothing, since Google will simply re-observe the same problem on the next crawl.

Common Statuses and What They Mean

  • URL is on Google: the page is indexed and, as far as the tool can tell, eligible to appear in search results.
  • URL is not on Google: the page isn’t indexed, and the specific exclusion reason (Discovered – currently not indexed, Crawled – currently not indexed, blocked by robots.txt, and others) determines the next step.
  • URL is on Google, but has issues: the page is indexed, but something (a mobile usability problem, for instance) is flagged.

When to Escalate Beyond the Tool

URL Inspection is built for one URL at a time. When the same issue shows up across many URLs, or when the goal is understanding a site-wide pattern rather than a single page’s status, the Page Indexing report is the better starting point; it groups affected URLs by exclusion reason and shows trend data over time, which the single-URL tool doesn’t provide.

Used correctly, the tool’s real value is narrow but genuinely useful: confirming, with a live test, that a specific fix actually worked, rather than relying on Google’s last crawl of the page to tell that story.

Call Now Button