URL Inspection Tool: The Complete Guide

The URL Inspection tool in Google Search Console shows what Google knows about one URL on a site you own: whether it's on Google, how Google found it, when it was last crawled, whether robots.txt and noindex let it through, and which canonical Google chose. A live test fetches the page as it is right now, and the same screen holds the Request indexing button. Google's URL Inspection tool help describes it as a view of the indexed version of a page plus a test of whether a URL might be indexable.

It's the one place in Search Console that answers page by page. For patterns across many pages, use the page indexing report; if your site doesn't appear on Google at all, start with how to get your website to show up on Google. This guide goes through every verdict and field of the Google Search Console URL inspection tool, with the label you see on screen and the field the API returns, then what the live test adds and the quotas, as of October 2026.

What the URL Inspection tool is for

Google URL inspection answers six questions about a single URL:

• Is it indexed? The verdict at the top of the result.
• If not, why not? A robots.txt rule, a failed fetch, a noindex, a canonical pointing elsewhere, or no crawl yet. Each has its own field.
• Which URL did Google pick as canonical? Yours, or another one.
• Is my fix live? The live test fetches the current version before Google recrawls.
• What did Google index? View crawled page shows the HTML of the indexed version.
• Can Google look again? Request indexing puts the URL in Google's queue.

Google announced the tool on June 25, 2018, and in January 2019 pointed users of Fetch as Google to it. Since January 31, 2022 the same indexed data is available through the URL Inspection API. Like the rest of Search Console, it's free; Google Webmaster Tools covers where the other old tools went.

How to use the URL Inspection tool

1. Open the property that contains the URL. The URL must be in the property that's currently open. Adding a property explains Domain and URL-prefix properties.
2. Paste the full URL into the search bar at the top of any Search Console screen, labeled Inspect any URL as of October 2026, or click the inspect icon next to a URL in most reports.
3. Read the verdict (next section).
4. Expand Page indexing. It splits into Discovery, Crawl and Indexing.
5. Compare Last crawl with your last change. If you changed the page after that date, the result describes the old version: click Test live URL.
6. Request indexing only after a change that matters, and only once.

Inspect the exact URL you want in search. When a URL redirects, the indexed result describes the URL you typed, not the redirect target, so an http:// or www variant only tells you about the variant.

Request indexing on the result runs a quick check for immediate indexing problems; if the page passes, it goes into Google's indexing queue, and if the live test finds it non-indexable, you can't request it. Only an owner or full user of the property can request indexing, there's a quota for individual URLs, and requesting the same URL again won't get it crawled any faster (Ask Google to recrawl your URLs). The URL Inspection help says indexing can take up to a week or two and isn't guaranteed. Request indexing covers the limit and when a click is worth it, indexing request rejected the failures, Google recrawl updated pages, and bulk request indexing what's possible at scale. The Indexing API isn't a shortcut: Google documents it only for JobPosting pages and BroadcastEvent embedded in a VideoObject (Indexing API quickstart), so other pages are outside its documented use (Google Indexing API).

URL inspection verdicts

Under Page indexing, a heading gives the state: The page is indexed, The page is not indexed, or a short reason such as Page is not indexed: URL is unknown to Google, which means Google hasn't seen the URL before (URL is unknown to Google). The reasons use the Page indexing report's wording, such as Crawled - currently not indexed. Google's guide to troubleshooting a single page notes that duplicates and alternates are not indexed by design, which is fine unless Google picked the wrong URL. URL is not on Google vs URL is on Google, but has issues gives the next action for each verdict.

Every field in the Page indexing section

Page indexing has three groups: Discovery (how Google found the URL), Crawl (whether and how it fetched it) and Indexing (noindex and the canonical). Each label on screen has a field in the API's indexStatusResult (UrlInspectionResult reference):

Two API fields have no label of their own: verdict (the verdict at the top) and coverageState (the reason phrase), covered after the field groups.

Discovery: Sitemaps and Referring page

Referring page is a page Google possibly used to discover the URL: a lead, not a backlink list. The API's referringUrls can include indirect links, and URL variants: our homepage's list included its own http:// address. That shows you which variants of a URL Google knows about.

Don't read much into an empty Sitemaps field. Google lists as a known issue that in a few cases it doesn't report the sitemap for a page submitted in one, and the API reference says the list may not be exhaustive. Our homepage is in our sitemap and came back Submitted and indexed on October 30, 2026, yet the response had no sitemap field.

Crawl: Last crawl, Crawled as, Crawl allowed? and Page fetch

Last crawl is the last time Google crawled the page, in your local time on screen and as an RFC 3339 timestamp in UTC (lastCrawlTime) in the API. Compare it with your last deploy: everything else in the indexed result describes the page as it was then. A URL Google knows but hasn't crawled yet is typically Discovered - currently not indexed.

Crawled as is the user agent type, desktop or mobile (DESKTOP or MOBILE). Under mobile-first indexing, Google indexes and ranks the mobile version of a site's content, fetched with its smartphone agent, so expect mobile; every crawled URL we inspected showed MOBILE. The field is absent when the crawl wasn't successful.

Crawl allowed? says whether robots.txt let Google fetch the page. In the API, robotsTxtState is ALLOWED or DISALLOWED, and ROBOTS_TXT_STATE_UNSPECIFIED usually means the page wasn't fetched or robots.txt couldn't be reached. The trap: when robots.txt blocks the crawl, Indexing allowed? always shows Yes, because Google can't see a noindex on a page it may not fetch. Google may still index a disallowed URL without its content (Indexed, though blocked by robots.txt), so to keep a page out, allow the crawl and use noindex (how to remove a URL from Google).

Page fetch says whether Google got the page from your server. On screen it reads Successful, Failed with a reason, or N/A. The API spells the reason out in pageFetchState:

Don't swap the two access codes: ACCESS_DENIED is the 401, ACCESS_FORBIDDEN the 403. Google's troubleshooting guide adds that 5xx errors usually leave the old version in results, while 4xx errors usually remove the page.

Indexing: Indexing allowed? and the two canonicals

Indexing allowed? reports whether a noindex rule blocks indexing. The API's indexingState also says where the rule was: BLOCKED_BY_META_TAG for a robots meta tag, BLOCKED_BY_HTTP_HEADER for an X-Robots-Tag header. That tells you whether to look in the page template or the server config (excluded by noindex tag, X-Robots-Tag). BLOCKED_BY_ROBOTS_TXT is reserved and no longer used. Don't read INDEXING_STATE_UNSPECIFIED as a block: our /v1 JSON endpoint, crawled and not indexed, returned it next to a successful fetch.

User-declared canonical is the canonical your page declares (userCanonical, absent if none); None is fine for a page that isn't an alternate. Google-selected canonical is the one Google chose (googleCanonical). Google notes it can be a few hours behind the index, and shows canonical details for an alternate only if the canonical is in a property you own.

When the two differ, Google didn't follow your preference: its canonicalization guide calls a declared canonical a hint, not a rule. Redirects and rel="canonical" are strong signals and sitemap inclusion a weak one, so make all three point at the same URL (Duplicate, Google chose different canonical than user, canonical tag). The API omits googleCanonical for a page that isn't indexed, though our redirecting www URL still returned one, its redirect target. A value present is Google's choice for the group, not proof that the URL you inspected is indexed.

The verdict and coverageState fields

verdict is coarse. Google maps PASS to Search Console's “Valid”, NEUTRAL to “Excluded” and FAIL to “Error” or “Invalid”; PARTIAL is reserved. A redirect, a page Google chose not to index and a URL it has never seen are all NEUTRAL, so read coverageState for the reason. It's a phrase, not an enum. Four results from our property on October 30, 2026:

If you store these values, keep the phrase exactly as returned and match it loosely: the wording is Google's to change.

The Enhancements & Experience section

This is where URL is on Google, but has issues comes from: the rich result types Google detected and their issues, the status of a linked AMP page, and video indexing when Google detects a video (only one video can be indexed per watch page). Structured data types the tool doesn't support can still be valid and appear in Search. In the API these are richResultsResult and ampResult; mobileUsabilityResult is deprecated and came back VERDICT_UNSPECIFIED for every URL we inspected.

View crawled page: the HTML Google indexed

For a URL that is on Google, with or without issues, View crawled page opens the version Google indexed: the HTML, and under More info the HTTP headers, page resources and JavaScript console output. There is no screenshot; that is only in the live test. Use it to check that your main content made it into what Google processed, as Google's mobile-first indexing guide suggests for rendered content; JavaScript SEO covers what to do when it didn't.

It's also the nearest thing left to a cached copy: Google's documentation updates log noted on October 2, 2024 that the cached link feature is no longer available in Search results. See Google cache, and how to check if a page is indexed for the other methods.

What the live test adds

Test live URL fetches the page now, whether or not it's indexed, as long as it's reachable without a login. Its verdicts are URL is available to Google, URL is available to Google, but has issues and URL is not available to Google. View tested page then shows the HTML, a Screenshot tab (only after a successful test) and More info. Run it after a fix: it doesn't wait for Google's next crawl.

The fetch comes from Google-InspectionTool, not Googlebot. Its robots.txt tokens are Google-InspectionTool and Googlebot, so a robots.txt rule for Googlebot applies to the live test too. Its user agent strings don't contain the word Googlebot, though, so a firewall or bot rule that only lets through user agents containing “Googlebot” can fail the live test while Googlebot's own crawls get through:

Mozilla/5.0 (compatible; Google-InspectionTool/1.0)
Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Google-InspectionTool/1.0)

What the live test leaves out matters as much as what it shows:

• It doesn't check sitemaps, referring pages, duplicates or canonical selection. Google also lists the Page indexing reasons it can't test: Crawled - currently not indexed, Discovered - currently not indexed, the duplicate and canonical reasons, Blocked by page removal tool and Page indexed without content.
• It doesn't judge quality, manual actions, removals or temporary blocks.
• It follows redirects without saying so, so a clean result for a redirecting URL describes the target.
• A valid result doesn't mean the page will be indexed. It only confirms that Google-InspectionTool can fetch the page, and nothing in the index changes until Google crawls it again.
• It can fail for site-wide reasons: DNS server unresponsive, Server connection error, Robots.txt unreachable or Hostload exceeded, which Google explains as your site being at maximum capacity for Google crawling or inspection requests.

Live test vs indexed version walks through what to do when the two disagree.

URL inspection quotas

Google limits inspections, live tests and indexing requests, but as of October 2026 it publishes numbers only for the API (Search Console API usage limits):

The per-property limit counts calls that query the same site, and the per-project limit calls made with the same key, so tools that inspect one property share its 2,000 calls a day. Bulk URL inspection covers working within that, and managing many sites in Search Console covers agencies, where each property has its own allowance.

The URL Inspection API

The API returns the indexed result only. Google's method reference says you can't test the indexability of a live URL with it, and it has no method for Request indexing: for ordinary pages Google offers no public API for that (request indexing API). A call is a POST with the URL, the property and an optional languageCode for translated messages (default en-US). A URL-prefix property needs its trailing slash (https://www.example.com/); a Domain property is written sc-domain:example.com. The OAuth token needs the webmasters or webmasters.readonly scope.

curl -s -X POST "https://searchconsole.googleapis.com/v1/urlInspection/index:inspect" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"inspectionUrl": "https://indexcyborg.com/", "siteUrl": "sc-domain:indexcyborg.com"}'

What it returned for our homepage on October 30, 2026, trimmed:

{
  "inspectionResult": {
    "indexStatusResult": {
      "verdict": "PASS",
      "coverageState": "Submitted and indexed",
      "robotsTxtState": "ALLOWED",
      "indexingState": "INDEXING_ALLOWED",
      "lastCrawlTime": "2026-10-25T04:15:04Z",
      "pageFetchState": "SUCCESSFUL",
      "googleCanonical": "https://indexcyborg.com/",
      "userCanonical": "https://indexcyborg.com/",
      "referringUrls": [
        "http://indexcyborg.com/",
        "http://indexcyborg.com/blog/indexing-status-from-your-coding-agent"
      ],
      "crawledAs": "MOBILE"
    },
    "mobileUsabilityResult": { "verdict": "VERDICT_UNSPECIFIED" }
  }
}

The response also carries inspectionResultLink, which opens the same result in Search Console. URL Inspection API covers every response field with code examples and batching, Google Search Console API covers auth and the other endpoints, and Search Console for developers covers the parts of the product worth automating.

What URL Inspection can't tell you

• Whether the page ranks. Indexed means eligible. Google's troubleshooting guide suggests searching for the URL on Google to confirm it appears.
• Quality and policy problems. The tool doesn't test manual actions, security issues, legal removals or temporary removals. Check the Manual Actions and Security Issues reports, and whether the page has been temporarily removed.
• Pages on sites you don't own. For those, Google points to non-owner tests such as the Rich Results Test.
• The whole site. It works one URL at a time. The Page indexing report shows patterns, and the crawl stats report shows crawl activity.
• Traffic. Index status isn't visits; see Google Search Console vs Google Analytics.
• Other search engines. Bing Webmaster Tools has its own URL Inspection for Bingbot.

New to Search Console? Start with how to use Google Search Console. To confirm a fix across many pages, use Validate fix in Search Console; for other tools, see Google Search Console alternatives.

How IndexCyborg uses URL Inspection

Once you connect Search Console and link the property, IndexCyborg runs the URL Inspection API on every URL it finds in your sitemaps. Never-inspected pages go first, 50 every 5 minutes, within Google's 2,000 per property per day and keeping 100 for calls you make through the API or MCP. Inspected pages are checked again after 7 days, up to 150 a day. The response is stored as Google returned it, coverageState word for word, and a status change lands in the activity log. POST /v1/sites/{id}/inspect queues inspections for URLs you name, GET /v1/urls/{id} returns the verbatim result, and the MCP tool get_indexing_status gives it to a coding agent. A page that hasn't been inspected is Not checked, never counted as indexed.

The API has no live test, so IndexCyborg doesn't run one; its own technical checks (HTTP status, redirect chains, meta robots, X-Robots-Tag, robots.txt rules, canonical) are its fetch, not Google's view. For Request indexing, the Chrome extension types the URL into Inspect any URL in your own Search Console session, clicks the button and reports Google's answer, at most 10 per property per rolling 24 hours. A request queues a crawl; it doesn't make Google index the page. More on the features page.

Frequently asked questions