Skip to content
arduralab
·8 min

URL Inspection — Google Search Console Tool

What is URL Inspection?

URL Inspection is the tool inside Google Search Console whose purpose is to report, for a single address, everything Google currently knows about it: whether it is indexed, when Google last crawled it, which canonical was selected, and what the page looks like after rendering.

It is the fastest way to turn a guess ("it probably isn't indexed because of the canonical") into a reading from Google's own system. It also has a second mode, the live test, which checks the page as it is right now rather than as Google stored it.

Can you inspect any URL?

No. URL Inspection works only for addresses inside a Search Console property you have access to, and the URL must belong to the property that is currently open. You cannot inspect a competitor's page or any site you do not manage. Google documents the tool as part of Search Console, with a programmatic version in the Search Console API described below.

Google's URL Inspection documentation describes two ways to open it: type the full URL into the inspection bar at the top of any Search Console screen, or click the Inspect link next to an address in most reports. For a URL in a property you do not own, the same documentation points to tests that do not require ownership, such as the Rich Results Test. Those check one feature, such as structured data, and say nothing about the URL's index status.

How to use the URL Inspection tool in Search Console

  1. Paste the full URL into the search bar at the top of Search Console and hit enter.
  2. Read the indexed data — this is a snapshot from the last time Google processed the page, not a live reading.
  3. Click Test live URL to have Googlebot fetch the page right now. The live test bypasses the index and shows the current state of the server.
  4. Inside the live test, open View tested page: rendered HTML, the screenshot, and More info, where blocked resources and JavaScript console messages are listed.
  5. If the page is genuinely ready and Google does not know about it, use Request indexing.

The split between the indexed view and the live test is the whole point of the tool. The first answers "what does Google have on file," the second answers "what would Google see if it came back now."

What does the live URL test check?

The live URL test checks whether Google can access the page for indexing at this moment. Google fetches the URL in real time and reports whether the page is indexable, which structured data it detected, which resources loaded, and what the rendered page looks like. The screenshot of the rendered page is available only in the live test, not in the indexed view.

That makes it the right check after a fix: you see whether the problem is gone before you ask Google to come back. According to Google's documentation, the live test does not cover several things:

  • Canonical selection. It cannot predict whether the tested version will be treated as canonical. The Google-selected canonical comes only from the indexed data.
  • Duplicates, sitemaps, and referring pages. It does not say whether the page is a duplicate or an alternate version, and it does not look for the URL in sitemaps or on pages that link to it.
  • Manual actions, removals, and quality guidelines. None of these are part of the test.
  • Redirects. The test follows redirects and checks the target, without telling you that it did or showing the final URL.

A clean live test therefore means "Google can fetch this page for indexing," not "this page will be indexed." The page also has to be reachable without a login, or the test cannot fetch it.

What the report shows

  • Index status — one of three states: the URL is on Google, is not on Google, or is on Google with issues
  • Discovery — whether the URL was found through the sitemap, a referring page, or both
  • Last crawl date and the crawler used (smartphone or desktop), which ties directly into crawl budget
  • User-declared canonical and Google-selected canonical — when the two differ, you are looking at a ready-made canonical diagnosis
  • Crawl and index permissions — whether robots.txt allows the crawler and whether a noindex tag is present
  • Rendered version — the HTML after scripts execute, which is decisive for JavaScript SEO
  • Enhancements — detected structured data, mobile usability, and any errors found

How to read the answers

The messages you will see most often, and what they actually mean:

  • "Discovered — currently not indexed" — Google knows the URL but has not crawled it yet. Usually a crawl-priority question, not a page defect.
  • "Crawled — currently not indexed" — the crawler came, and what it found was not compelling enough. The fix is the page itself, not another submission.
  • "Duplicate, Google chose different canonical than user" — your canonical signals contradict each other. Check the link rel="canonical" tag, internal links, and the sitemap.
  • "Alternate page with proper canonical tag" — a healthy state; the page deliberately points at another URL as the primary one.
  • "Blocked by robots.txt" or "Excluded by noindex tag" — a decision made on your side, not Google's.

If the live test looks clean while the indexed data is stale, the real problem is indexing and crawl frequency rather than the page content.

How to use the URL Inspection API

The URL Inspection API returns the indexed data for one URL per call, so a script can check a list of pages instead of someone pasting them into Search Console one by one. You send a POST request to the index:inspect method with two required fields, the URL to inspect (inspectionUrl) and the Search Console property it belongs to (siteUrl), and authorize it with a Search Console OAuth scope, as described in the method reference.

The response follows the report in the interface: the indexing verdict and coverage state, the robots.txt state, the last crawl time and the crawler used, the user-declared and Google-selected canonical, known sitemaps and referring URLs, and rich results analysis when the page has any. Three limits decide when the API is the right tool:

  • Indexed data only. The API returns the status of the version in Google's index; it cannot run a live test.
  • No indexing requests. The reference documents a single method, inspect. Requesting indexing remains a manual action in the Search Console interface.
  • Quotas. Per Google's usage limits, read on October 10, 2026, the per-site quota is 2,000 queries per day and 600 per minute. A large site has to sample or rotate its URLs across days.

Use the tool in Search Console to diagnose a single page and run the live test. Use the API to watch a fixed list of important URLs, for example to catch a Google-selected canonical that drifts away from the declared one after a template change.

What the tool does not do

  • It does not guarantee indexing. Request indexing puts the URL in a queue and nothing more — Google may still skip the page, and the daily submission quota is limited. Resubmitting the same URL repeatedly does not speed anything up.
  • It does not replace a sitemap. A sitemap is the bulk channel for the whole site; URL Inspection handles one address at a time.
  • It is not the Indexing API. That programmatic interface is intended for job postings and livestreams; URL Inspection has its own API, but it is read-only and cannot submit anything.
  • It does not show rankings or traffic — that is what the performance report is for.

Example

An illustrative example: a new blog post never shows up in results. The indexed view says "Discovered — currently not indexed," so nothing is blocking it. The live test, however, reveals that the canonical points at the category page — the template was injecting the wrong tag. Once fixed and resubmitted, the crawler returns and the Google-selected canonical finally matches the declared one.

Need help diagnosing indexing problems? Book a free consultation — we will walk through your Search Console data together.

Related terms

Need help?

Strategy tailored to your goals — check out our offer.