URL Inspection Tool

TL;DR — The URL Inspection tool in Google Search Console tells you whether one of your pages is in Google, and why or why not. Just know this: by default it shows you the last time Google indexed the page, not how the page looks right now. If you just changed something, click Test Live URL to check the current version.

What it is

The URL Inspection tool lives in Google Search Console. You paste in one URL from a site you own, and Google tells you how it sees that page — most importantly, whether it’s in Google’s index and able to show up in search.

You can only inspect URLs on a property you’ve verified in Search Console. You can’t check a competitor’s page.

The one thing beginners get wrong

When you inspect a URL, the report you see first is a snapshot from the last time Google indexed it — not the live page. Google says it directly: this is not a live test, the results are from the most recently indexed version, not the live version on the web. Evidence for this claim The default URL Inspection result describes Google's indexed version, not a live fetch of the current page. Scope: Google Search Console URL Inspection; Test Live URL is the separate current-page test. Confidence: high · Verified: 2026-07-14 Google Search Console Help: URL Inspection tool

So if you just fixed something and want to know if the fix worked, don’t trust that first screen. Click Test Live URL and Google will fetch the page right now.

What it tells you

• Is the page on Google? “URL is on Google” means it’s eligible to appear in search — not that it’s ranking, just that it can show up. “URL is not on Google” means it can’t appear.
• Was Google allowed to crawl and index it? If you accidentally blocked the page, this is where you’ll see it.
• Which version did Google pick? If you have duplicate or similar pages, Google chooses one “canonical” version to show. The tool tells you which one.
• View crawled page shows you the actual HTML Google got, a screenshot of how the page rendered, and any errors.

Request Indexing

There’s a button that says Request Indexing. It tells Google “please come look at this page.” That’s all it does. It does not force Google to index the page, it does not help you rank, and clicking it over and over doesn’t speed anything up — there’s a daily limit, and you’ll just use it up. Evidence for this claim Request Indexing does not guarantee that a page will appear in Google's index. Scope: Google Search Console's Request Indexing feature; requests are subject to a daily limit. Confidence: high · Verified: 2026-07-14 Google Search Console Help: URL Inspection tool Use it once for a new or freshly updated page, then move on. You’ll need to be an owner or full user on the property to use it — and if you’ve got a batch of new or changed URLs rather than just one, Google’s advice is to submit a sitemap instead of clicking the button repeatedly.

Want the field-by-field reading guide, the canonical-mismatch diagnostic, the JavaScript debugging workflow, and the API? Switch to the Advanced tab.

TL;DR — URL Inspection reports how Google sees one URL on a verified property. The default report is the last-indexed snapshot, not the live page — run Test Live URL for the current state. Read the coverage panel for crawl/index permissions, discovery (sitemap + referring page), and the user-declared vs Google-selected canonical (a mismatch is your most actionable diagnostic). View crawled page gives you rendered HTML, a screenshot, the HTTP response, page resources, and JS console messages — the JavaScript-SEO debugging surface. Request Indexing is a queue hint with a daily quota: no guarantee, no ranking effect. The URL Inspection API returns the indexed state (no live test) at 2,000 QPD / 600 QPM per property.

What the tool actually does

Google’s own framing: the URL Inspection tool “provides information about Google’s indexed version of a specific page, and also allows you to test whether a URL might be indexable.” Those are two distinct modes, and conflating them is the single most common mistake I see.

It’s also owner-only. “The URL must be in the currently opened property” — you can only inspect URLs on a Search Console property you’ve verified. There’s no inspecting competitors.

Indexed snapshot vs Test Live URL

The default report is a snapshot of the last crawl. Google is explicit: “This is not a live test. The results shown are from most recently indexed version of a page, not the live version on the web.” Evidence for this claim The default URL Inspection result describes Google's indexed version, not a live fetch of the current page. Scope: Google Search Console URL Inspection; Test Live URL is the separate current-page test. Confidence: high · Verified: 2026-07-14 Google Search Console Help: URL Inspection tool

That distinction drives when you use each mode:

• Diagnosing what’s actually in the index right now? Read the default indexed view. That’s the state Google is currently acting on.
• Just shipped a fix and want to know if it worked? Run Test Live URL. It fetches and renders the current page so you can confirm the fix before you wait on a recrawl.

A huge amount of needless panic — and needless “nothing changed” confusion — comes from reading the wrong one. If you fixed a noindex an hour ago and the indexed snapshot still shows it blocked, that’s expected; the snapshot predates your fix.

Two scope limits on Test Live URL worth knowing: it does follow redirects when it fetches the page, but it doesn’t show you the redirect chain the way a dedicated redirect checker does, and it can’t predict which URL Google will select as canonical — the Google-selected canonical field only comes from the indexed view, because that’s a decision Google makes as part of indexing, not something a single live fetch can determine.

Reading the coverage panel, field by field

Index status verdict. “URL is on Google means that the URL is eligible to appear in Search results, but is not guaranteed to be there.” Eligible is not the same as present, and it’s certainly not the same as ranking. “URL is not on Google means that the URL can’t appear in Search results.”

Crawl allowed? “Indicates whether your site allowed Google to crawl the page or blocked it with a robots.txt rule.” A No here points straight at robots.txt.

Indexing allowed? “Whether or not your page explicitly disallowed indexing.” A No here points at a noindex directive (meta tag or X-Robots-Tag header).

Discovery. The panel also shows the sitemap(s) that reference the URL and the referring page Google followed to discover it. If a URL you expect to be found shows no sitemap and no referring page, treat that as a signal to check your internal linking and sitemap inclusion — not a confirmed verdict. The panel isn’t guaranteed to list every path Google used to find a URL, so an empty field is a reason to investigate, not proof there’s no discovery path at all.

Canonicals — the most actionable field here. Two lines:

• “User-declared canonical: If your page explicitly declares a canonical URL, it will be shown here.”
• “Google-selected canonical: The page that Google selected as the canonical (authoritative) URL.”

When those two disagree, Google has overridden the canonical you declared — it decided some other URL is the authoritative one. That’s your cue to investigate: duplicate or near-duplicate content, inconsistent internal linking, mixed canonical signals, or a stronger duplicate elsewhere. This single comparison is the most useful diagnostic in the whole panel. (For the underlying mechanics, this ties into the canonicalization material elsewhere in this cluster.)

Enhancements. The report surfaces eligible rich-result types and structured data it detected (Breadcrumbs, FAQ, Products, and so on). Note that the old Mobile Usability section is gone — Google retired that report, so it no longer appears here.

View crawled page — the JavaScript-SEO debugging surface

This is where URL Inspection earns its keep for technical work. Open View crawled page (on the indexed result) or View tested page (on a live test) and you get the rendered HTML, a screenshot of the rendered page, the HTTP response headers, the list of page resources Google loaded, and the JavaScript console messages.

For a JS-heavy page, this is the whole debugging loop in one screen:

1. Screenshot — does the rendered page actually contain your content, or is it blank/half-built? If content you can see in your browser is missing here, Google isn’t rendering it.
2. Rendered HTML — search it for the content and links that should be there after JavaScript runs. If they’re absent, your content depends on something Google’s renderer didn’t execute.
3. Page resources — any resource that couldn’t be loaded (a blocked JS file, a 404’d API, a robots-blocked script) is a prime suspect for missing rendered content.
4. JS console messages — errors here often explain exactly why the render came up short.

This is the workflow I lean on for JavaScript SEO problems, and it’s the part most write-ups gloss over. One caveat: what you’re looking at is Google’s rendering of that single fetch — the indexed snapshot’s last pass, or the live test’s pass right now — not a certified guarantee that every system Google uses for indexing rendered the page identically.

Request Indexing — what it is and isn’t

The Request Indexing button runs a quick live test and then pushes the URL into Google’s crawl queue. Two hard limits to internalize:

• “Submitting a request does not guarantee that the page will appear in the Google Index.” It’s a discovery hint, not a command.
• “There is a daily limit to how many index requests you can submit.” Spamming the same URL just burns that quota and accomplishes nothing.
• “You must be an owner or full user of the Search Console property to be able to request indexing in the URL Inspection tool.” Restricted users don’t get a working option here.

And to be blunt about what it is not: it is not a ranking lever. Indexing and ranking are separate stages; nudging a URL into the crawl queue has no effect on where it ranks. It also doesn’t override canonicalization — Google has said requesting indexing doesn’t change which URL it selects as canonical. Use it once for genuinely new, updated, or just-fixed pages. That’s the entire legitimate use case.

It’s also not a bulk tool. Google’s own recommendation: “If you have large numbers of URLs, submit a sitemap.” Working through a spreadsheet of URLs one Request Indexing click at a time just burns your daily quota faster than it helps — a sitemap is the mechanism built for volume.

The URL Inspection API

For monitoring at scale there’s a programmatic equivalent, the URL Inspection API (urlInspection.index.inspect). The per-property quota is 2,000 queries per day and 600 per minute. Evidence for this claim The URL Inspection API quota is 2,000 queries per day and 600 queries per minute per Search Console property. Scope: Current Search Console URL Inspection API per-property usage limits. Confidence: high · Verified: 2026-07-14 Google Search Console API: Usage limits

Two things to keep straight:

• The API returns the indexed state only — verdict, coverage state, robots and indexing state, last crawl time, page fetch state, the Google-selected and user-declared canonicals, how it was crawled, referring URLs, and sitemap. It does not run a live test the way the UI’s Test Live URL does.
• The 2,000/day-per-property cap means bulk index monitoring across a large site needs batching, or splitting the site across multiple verified properties. Several third-party tools wrap the API to make this practical.

It pairs naturally with the Page Indexing report for spotting which URLs to inspect, and with the broader Search Console API and the Performance report when you’re building your own monitoring.

Common myths

• “Request Indexing forces Google to index my page.” No — submitting “does not guarantee that the page will appear in the Google Index.”
• “Request Indexing makes a page rank, or rank faster.” No. It affects discovery/recrawl, not ranking.
• “Re-submitting the same URL speeds it up.” No — it just spends your daily quota.
• “On Google means it’s ranking.” No — it means eligible to appear.
• “The report shows my page as it is right now.” No — the default is the last-indexed snapshot. Test Live URL is the live mode.
• “I can inspect any URL.” No — owner-only; the URL must be in the currently opened property.
• “The API runs a live test like the UI.” No — the API returns indexed state only.

AI summary

A condensed take on the Advanced version:

• What it is: URL Inspection reports how Google sees one URL on a verified property you own (no competitor URLs). Google: it “provides information about Google’s indexed version of a specific page, and also allows you to test whether a URL might be indexable.”
• Snapshot vs live: the default view is the last-indexed snapshot, “not the live version on the web.” Run Test Live URL to check the current state after a fix — it follows redirects but doesn’t show the chain, and it can’t predict the Google-selected canonical (that’s an indexed-view-only field).
• Verdict: “URL is on Google” = eligible to appear, not ranking, not guaranteed.
• Coverage panel: crawl allowed (robots.txt), indexing allowed (noindex), discovery (sitemap + referring page), and user-declared vs Google-selected canonical — a mismatch means Google overrode your canonical and is the most actionable diagnostic.
• View crawled page: rendered HTML + screenshot + HTTP response + page resources + JS console messages — the JavaScript-SEO debugging surface.
• Request Indexing: a queue hint with a daily limit, requires owner or full-user access to the property; “does not guarantee that the page will appear in the Google Index,” no ranking effect, doesn’t change canonicalization. For bulk URLs, Google’s advice is to submit a sitemap instead.
• API: returns indexed state only (no live test) at 2,000 QPD / 600 QPM per property; batch or split properties for bulk monitoring.

Official documentation

Primary-source documentation from Google.

Google Search Console

• URL Inspection Tool — the canonical Help doc: index status verdicts, coverage, canonicals, View crawled page, and Request Indexing.
• Ask Google to recrawl URLs — the Request Indexing permission requirement, the sitemap-for-bulk-URLs recommendation, and the no-guarantee framing.

URL Inspection API

• Welcoming the new Search Console URL Inspection API — Search Central blog announcing the API.
• Usage Limits — Search Console API — the 2,000/day and 600/minute per-property quotas.
• urlInspection.index.inspect reference — the method and the fields it returns.

Quotes from the source

On-the-record statements from Google’s documentation. Each link is a deep link that jumps to the quoted passage on the source page.

Google — what the tool is

• “The URL Inspection tool provides information about Google’s indexed version of a specific page, and also allows you to test whether a URL might be indexable.” — Google Search Console Help. Jump to quote
• “This is not a live test. The results shown are from most recently indexed version of a page, not the live version on the web.” Jump to quote

Google — index status verdicts

• “URL is on Google means that the URL is eligible to appear in Search results, but is not guaranteed to be there.” Jump to quote
• “URL is not on Google means that the URL can’t appear in Search results.” Jump to quote

Google — coverage: crawl, indexing, canonicals

• “Crawl allowed? Indicates whether your site allowed Google to crawl the page or blocked it with a robots.txt rule.” Jump to quote
• “Indexing allowed? Whether or not your page explicitly disallowed indexing.” Jump to quote
• “User-declared canonical: If your page explicitly declares a canonical URL, it will be shown here.” Jump to quote
• “Google-selected canonical: The page that Google selected as the canonical (authoritative) URL.” Jump to quote

Google — Request Indexing and ownership

• “Submitting a request does not guarantee that the page will appear in the Google Index.” Jump to quote
• “There is a daily limit to how many index requests you can submit.” Jump to quote
• “The URL must be in the currently opened property.” Jump to quote

Google — Request Indexing permission and scale

• “You must be an owner or full user of the Search Console property to be able to request indexing in the URL Inspection tool.” — Google, “Ask Google to recrawl URLs.” Jump to quote
• “If you have large numbers of URLs, submit a sitemap.” Jump to quote

Reading a URL Inspection result — checklist

A quick pass to diagnose one URL:

• Confirm you’re in the right verified property (owner-only; no competitor URLs).
• Check the verdict — “on Google” means eligible, not ranking.
• If you just changed the page, run Test Live URL — don’t trust the indexed snapshot for current state.
• Crawl allowed? No → check robots.txt.
• Indexing allowed? No → check for noindex (meta tag or X-Robots-Tag).
• Compare user-declared vs Google-selected canonical — a mismatch means Google overrode your canonical; investigate duplicates and linking.
• Check discovery — is a sitemap and/or referring page listed? If not, check internal linking and sitemap inclusion; an empty field is a signal to investigate, not proof there’s no path in.
• Open View crawled page → screenshot, rendered HTML, page resources, JS console messages for render issues.
• Only use Request Indexing for new/updated/fixed pages — once, not repeatedly.

The mental models

1. Snapshot vs live — pick by your question. The default report answers “what is Google acting on right now?” (the last-indexed snapshot). Test Live URL answers “would the current page be indexable?” Decide which question you’re asking before you read a result, and you’ll stop misreading stale data as a live failure.

2. Verdict ≠ ranking. “URL is on Google” = eligible to appear. Not present, not ranked. Keep indexing and ranking as separate stages in your head.

3. The canonical comparison. User-declared vs Google-selected canonical is the panel’s most actionable line. They match → Google agrees with you. They differ → Google overrode you; go find the duplicate or signal that’s stronger than your declared canonical.

4. The render-debug loop (View crawled page). Screenshot (is the content there?) → rendered HTML (is the markup there?) → page resources (did anything fail to load?) → JS console (any errors?). Walk it in that order to localize a JavaScript rendering failure.

5. Request Indexing is a hint, not a command. It nudges discovery/recrawl. It doesn’t guarantee indexing, doesn’t rank, doesn’t change canonicalization, and has a daily quota. One nudge per new/changed page.

URL Inspection — cheat sheet

Two modes

Coverage fields → what to check

Verdicts

• URL is on Google — eligible to appear (not ranking, not guaranteed present).
• URL is not on Google — can’t appear in results.

Request Indexing

• Queue hint, daily quota, no guarantee, no ranking effect, doesn’t change canonicalization. Requires owner/full-user access. Use once per new/updated page; for bulk URLs, submit a sitemap instead.

API

• urlInspection.index.inspect — 2,000 QPD / 600 QPM per property.
• Returns indexed state only (no live test).

Inspect a URL via the API

The URL Inspection API returns the same indexed state as the UI (no live test), at 2,000 queries/day and 600/minute per property. Here’s a minimal curl against the urlInspection.index.inspect endpoint — swap in an OAuth access token with the webmasters.readonly scope, the URL you’re inspecting, and the verified property (siteUrl).

macOS / Linux

ACCESS_TOKEN="ya29...your-oauth-token"

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://example.com/some-page/",
    "siteUrl": "sc-domain:example.com"
  }'

The response’s inspectionResult.indexStatusResult carries the verdict, coverageState, robotsTxtState, indexingState, lastCrawlTime, pageFetchState, and both googleCanonical and userCanonical — the same fields you read in the UI’s coverage panel. Compare the two canonical fields programmatically to flag pages where Google overrode your declared canonical.

Note the per-property cap: monitoring a large site means batching requests under 600/minute and 2,000/day, or splitting the site across multiple verified properties.

Tools

• URL Inspection (Google Search Console) — the tool itself; inspect one URL, run a live test, view the crawled/tested page, and request indexing.
• Page Indexing report (GSC) — find which URLs to inspect: it groups your pages by index status and the reason they’re not indexed.
• URL Inspection API — the programmatic equivalent for bulk index monitoring (2,000/day, 600/min per property); several third-party SEO tools wrap it.
• Search Console API / Performance report (GSC) — pair with inspection data when building your own monitoring around impressions, clicks, and indexing.

URL Inspection mistakes that lead to bad conclusions

Treating “URL is on Google” as a ranking check

Why it fails: The verdict means the URL is eligible to appear, not that it is currently visible for a query or ranking in a particular position.

Do instead: Use the Performance report or a real search-result check for search visibility, and keep URL Inspection focused on crawl and index state.

Confusing indexed data with a live test

Why it fails: The default inspection describes the version Google last indexed; it can lag behind the page you just changed.

Do instead: Run Test live URL to check the current fetch, then compare it with the indexed view to understand what changed and what Google has not reprocessed yet.

Repeatedly clicking Request indexing

Why it fails: The button is a crawl-queue hint with a daily limit. It does not force indexing, improve rankings, or make repeated submissions process faster.

Do instead: Submit once after the live page is ready, keep it discoverable through links and sitemaps, and investigate quality or technical exclusion reasons if Google still declines to index it.

Ignoring a canonical mismatch

Why it fails: When Google-selected canonical differs from the user-declared canonical, the inspected URL may not be the version Google treats as authoritative. Reading only the headline verdict misses the most actionable part of the report.

Do instead: Compare canonicals, redirects, internal links, sitemap inclusion, and duplicate content across the cluster before deciding whether Google’s selection is wrong.

Using URL Inspection as a site-wide audit

Why it fails: The interface inspects one URL at a time, and the API is quota-limited. A few hand-picked URLs cannot prove an entire template or inventory is healthy.

Do instead: Use the Page Indexing report and a crawler to find patterns, then use URL Inspection on representative examples from each affected template and status.

Inspecting the wrong property or URL variant

Why it fails: Inspection is limited to the verified property you opened. Protocol, host, and URL-prefix scope can put the target outside that property.

Do instead: Confirm the exact URL and property scope before interpreting an empty, unavailable, or unexpected result.

Resources worth your time

My related writing

• The Beginner’s Guide to Technical SEO — where URL Inspection fits into seeing how Google crawled, rendered, and indexed a page.
• JavaScript SEO Issues & Best Practices — the live test / View crawled page workflow for debugging rendering.
• How to Remove URLs From Google Search — context for index status vs removals.

From others

• Search Engine Land — Google Search Console URL Inspection tool: practical SEO use cases.
• Search Engine Land — SEO tools to get URL Inspection API insights.
• Search Engine Journal — Google Announces Search Console URL Inspection API.
• Ahrefs — Google’s New Search Console URL Inspection API: What It Is & How to Use It.
• Search Engine Roundtable — Google Says Request Indexing Does Not Change Canonicalization — Barry Schwartz reporting on Google’s confirmation that Request Indexing has no effect on canonical selection.

Videos

• Google Search Central (YouTube) — Search Console and JavaScript-SEO explainers from Martin Splitt that cover inspecting URLs and reading rendered output. Channel

Test yourself: The URL Inspection Tool

Five quick questions on the URL Inspection tool. Pick an answer for each, then check.

URL Inspection tool

A Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate "Test live URL" mode fetches the current version.

Related: Google Search Console, Index Coverage Report, Search Console API

URL Inspection tool

The URL Inspection tool is a feature inside Google Search Console that tells you how Google sees a single URL on a property you’ve verified. It reports the index status, the canonical Google chose, coverage details (whether crawling and indexing were allowed, which sitemap referenced the URL, and the referring page Google followed to find it), any detected structured data, and a “View crawled page” panel with the rendered HTML, a screenshot, the HTTP response, page resources, and JavaScript console messages.

The single most important thing to understand is that the default view is a snapshot, not a live reading. As Google puts it, “This is not a live test. The results shown are from most recently indexed version of a page, not the live version on the web.” To see the current state of a page — after you’ve shipped a fix, for example — you run “Test live URL,” which fetches and renders the URL right now.

The tool only works for properties you own and have verified; you can’t inspect a competitor’s URL. A “Request indexing” button pushes a URL into Google’s crawl queue, but it’s a discovery hint with a daily quota, not a guarantee of indexing and never a ranking boost. A programmatic equivalent, the URL Inspection API, returns the same indexed state at scale (2,000 queries per day, 600 per minute, per property).

Related: Google Search Console, Index Coverage Report, Search Console API

Changelog