URL Inspection Tool: How to Read Every Field in Search Console

On this page: quick jump links

• What the tool is, and where it gets its data
• Two panels, two different questions
• Reading every field in Page indexing
• The verdicts, and what each one certifies
• What the live test cannot tell you
• Documented, versus widely believed
• The URL Inspection API
• A read order for a page that is missing
• Frequently asked questions

The URL Inspection tool in Google Search Console reports what Google knows about one specific URL on a property you own. It opens on the indexed version of the page — the copy Google last crawled and stored, which is what search results are generated from — and it can also run a live test that fetches the page fresh. Those two panels answer different questions, and the fields inside them are precise rather than decorative: Crawl allowed? asks about robots.txt, Indexing allowed? asks about noindex, and Google-selected canonical reports a decision Google made that may differ from the one you declared. Read in order, the URL Inspection tool usually names the reason a page is missing. This guide walks every field, quotes Google's own documentation for the mechanisms, and marks the places where the widely repeated version differs from the documented one.

What the tool is, and where it gets its data

Google's documentation describes the URL Inspection tool Google Search Console ships with plainly: it "provides information about Google's indexed version of a specific page, and also allows you to test whether a URL might be indexable" (URL Inspection tool, Search Console Help). Two things follow from that sentence, and most misreadings of the panel come from missing one of them.

First, the URL has to be inside the property you have open. Google states the constraint directly — the URL "must be in the currently opened property" — so you cannot point it at a competitor. For a page you do not own, the Rich Results Test is the equivalent non-owner check.

Second, the opening view is history, not a live reading. Google's key-points box is explicit that this "is not a live test" and that results come from the most recently indexed version, which may be days or weeks old. If you fixed something this morning, the default panel will not show it. That single misunderstanding accounts for a large share of "the tool is wrong" reports.

There are two ways into Google Search Console URL Inspection. Type a fully-qualified URL into the inspection bar at the top of any Search Console screen, or click the Inspect link that appears beside a URL in most other reports — including the Page Indexing report statuses, which is usually the faster route when you are working through a list. Google notes a daily limit on inspection requests per property.

Two panels, two different questions

The index panel answers: what did Google decide about this page the last time it looked? The live test answers: can Google-InspectionTool fetch and parse this page right now? Neither answers will this page appear in Search? — and Google says so in three separate places in the same document.

That gap is the single most useful thing to understand about the URL Inspection tool, because a green verdict is routinely read as a guarantee it was never designed to be. Google lists what the results explicitly do not test: conformance to quality and security guidelines, whether the site is free of manual actions or security issues, whether content has been removed for legal reasons, and whether a URL has been temporarily blocked in Search Console. All four can keep an indexed page out of results while every field on the panel stays green.

Reading every field in Page indexing

Expand Page indexing on the index panel of the URL Inspection tool and the fields arrive in three groups, in the order Google itself groups them: how the URL was found, what happened when it was fetched, and what was decided about it.

Discovery: Sitemaps and Referring page

Sitemaps lists any sitemap you submitted through the Sitemaps report, or that is declared in robots.txt, which points at this URL. Sitemaps Google discovered by other means are not listed, so a blank here is weaker evidence than it looks. No referring sitemap means Google could not identify one — worth fixing on a large or new site, where a well-formed sitemap does real discovery work.

Referring page names a page Google possibly used to find this URL. Google's own wording carries a caution worth repeating: the referring page might be a grandparent rather than a direct link, and an absent value "doesn't mean that no referring page exists". Treat a blank as unknown, not as proof the page is orphaned. If you do suspect an orphan, check the internal links pointing at it rather than trusting this field alone.

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

Last crawl is the timestamp everything else on the panel derives from, shown in your local time. If it predates your fix, nothing below it reflects your fix.

Crawled as names the user agent used — desktop or smartphone. On a site that serves different markup to different agents this field is the one that explains a confusing result.

Crawl allowed? reports one thing only: whether robots.txt permitted the fetch. A "No" here is a crawlability problem, and you can confirm which rule is responsible with a robots.txt and crawlability check against the same URL.

Page fetch reports whether the server actually returned the page. Google's documentation is careful that these are separable: fetching "can be successful even if the page is not indexed for another reason". Values are Successful, Failed with a named status reason, or N/A for a failure Google cannot classify.

Indexing: Indexing allowed?, User-declared canonical, Google-selected canonical

Indexing allowed? reports whether the page explicitly disallowed indexing, normally via a noindex tag or an X-Robots-Tag header. This field carries the most counter-intuitive documented behaviour on the whole panel, and it has its own section below.

User-declared canonical is the canonical you stated — through a <link rel="canonical"> tag, an HTTP header, or a sitemap. Google is clear that there is "no guarantee that Google will choose your preferred canonical", only that it is taken into consideration. If the page is not one of a set of alternates, None is a fine value here.

Google-selected canonical is the decision. Google may pick your declared URL or "another URL that it considers a better canonical example". Two practical consequences follow from the documentation: this value exists only in the indexed data, because "the live test cannot predict whether or not the tested version will be considered canonical"; and the value can run a few hours behind the index. An unexpected URL here is the classic signal that two of your pages are competing, which is a canonical problem rather than a content one — see canonical tag best practices for the fix.

Where the page carries structured data or an AMP version, an Enhancements section appears below these. It reports only the rich result types the URL Inspection tool supports; Google notes that unsupported types "might be present and valid on the page" without appearing here, so absence is not evidence of a problem.

The verdicts, and what each one certifies

The card at the top of the index panel carries one of four values.

• URL is on Google — indexed and eligible to appear, with no problems found in any detected enhancements. Google's own emphasis: this "doesn't guarantee that your page is appearing in Search results".
• URL is on Google, but has issues — same eligibility, with a problem that may block enhancements: malformed structured data for a rich result, or a fault in an associated AMP page.
• URL is not on Google — the page will not appear. The reason is in the Page indexing section, and per Google's guidance the Crawl group is where it can "generally be found".
• URL is an alternate version — the inspected URL is an AMP alternate of a canonical non-AMP page. Usually nothing to do, beyond confirming the Google-selected canonical is the URL you expected.

The live test uses a parallel but distinct vocabulary: URL is available to Google, URL is available to Google, but has issues, and URL is not available to Google. The word is available, not on — the change is deliberate and marks the narrower claim being made.

What the live test cannot tell you

Click Test live URL and Google fetches the page in real time. It is the right move after a fix, because it bypasses the stale indexed copy the URL Inspection tool opens on. What it is not is a prediction. Google's answer to "does a valid result mean that my page will be indexed?" is a one-word "No."

The documentation names the indexing issues that cannot be tested live, and the list matters because several are the exact statuses people run a live test to investigate:

• Crawled – currently not indexed and Discovered – currently not indexed. Both are judgements made at indexing time; see what each indexing status means.
• All four duplicate and canonical states, because "information about Google's canonical choice is determined at indexing time".
• Blocked by page removal tool — check the Temporary Removals page instead.
• Page indexed without content.

Three further limits are easy to trip over. The live test does not check sitemaps or referring pages at all. It follows redirects silently — Google states the test "does not indicate that it has followed a redirect, nor will it display the final URL that was tested" — so a live test on a redirecting URL is quietly testing something else. And the screenshot people go looking for is live-test-only: Google's documentation states screenshots "are not available for the indexed URL", or for an unsuccessful fetch. There is also a per-property daily limit on live inspections.

Documented, versus widely believed

Four places where the version repeated in forums and checklists diverges from Google's own text. Each claim below is verified against the Search Console documentation linked above.

Believed: a noindex tag will keep a robots.txt-blocked page out of Search. Documented: the opposite can happen, and the panel will tell you so misleadingly. Google states that if a page is blocked by robots.txt, "Indexing allowed?" will always read Yes — because Google cannot see, and therefore cannot respect, any noindex directive on a page it is not allowed to fetch. Google's stated consequence: the page "might appear in Search results even if indexing is blocked by your site". If you need a page out of the index, allow the crawl and serve noindex; blocking both is the configuration that fails.

Believed: the default panel shows the page as it is now. Documented: it shows the last indexed copy, and Google flags this in bold in its own key-points box. Run the live test whenever the question is "did my fix land?"

Believed: a green verdict means the page is in Search. Documented: Google names four categories of condition the tool never evaluates, and directs you to search for the page URL on Google for "a definitive test".

Believed: re-submitting through Request indexing pushes a page up the queue. Documented: Google states only that submitting "does not guarantee that the page will appear in the Google Index", that indexing can take "up to a week or two", and that a daily submission limit applies; for many pages it recommends a sitemap with <lastmod> instead. That repeated requests confer no priority is the consensus reading among practitioners rather than a documented rule — but nothing in the documentation supports queue-jumping, and the daily limit makes the tactic self-defeating either way.

The URL Inspection API

The same index data is available programmatically. The Search Console API exposes index.inspect, a POST to https://searchconsole.googleapis.com/v1/urlInspection/index:inspect taking inspectionUrl, siteUrl and an optional languageCode, and returning a UrlInspectionResult object (Method: index.inspect, Search Console API). Authorisation needs the webmasters or webmasters.readonly scope, and siteUrl must match the property exactly — a trailing slash for URL-prefix properties, or the sc-domain: form for domain properties.

One documented limitation shapes what you can build with it: the API returns "the status of the version in the Google index" only, and Google states plainly that "you cannot test the indexability of a live URL". The live test has no API. Anything that needs a live verdict still needs a person in the interface, which is why index-status monitoring scales and live-fix verification does not.

A read order for a page that is missing

When a page is not in Search, the panel answers the question faster if you read it in this order rather than top to bottom.

1. Last crawl. If it predates your change, stop and run the live test — everything below is describing an old copy.
2. Crawl allowed? A No is a robots.txt block and nothing below it is trustworthy, for the reason set out above.
3. Page fetch. A failure here is a server or redirect problem, not a content one.
4. Indexing allowed? A No is a noindex directive — usually a template applying it more widely than intended.
5. Google-selected canonical. If it is a different URL, the page is being treated as a duplicate and no amount of content work will change that until the canonical does.
6. Only then treat it as a quality judgement. If crawl, fetch, indexing and canonical are all clean and the status is Crawled – currently not indexed, the answer is not in this panel — it is in why the page was judged not worth indexing.

Running that sequence by hand on one URL is quick. Running it across a few thousand, then acting on what it finds, is the job our precision page deployment service does page by page, and the wider indexation and crawl budget guides cover the site-level causes this per-URL panel can only hint at.

Frequently asked questions

What is a URL inspection tool?

In Google Search Console it is a per-URL diagnostic that reports what Google knows about one page on a property you own: how the URL was discovered, when and how it was crawled, whether crawling and indexing were allowed, which canonical Google selected, and any rich results detected. It also runs an on-demand live test. Google's documentation describes it as providing information about Google's indexed version of a page and letting you test whether a URL might be indexable. It is a reporting and diagnostic surface, not a ranking tool.

How do I inspect a URL?

Open the property in Search Console, then either type the fully-qualified URL into the inspection bar at the top of any screen, or click the Inspect link beside a URL in another report — you sometimes need to hover to reveal it. The URL must sit inside the property you have open. The panel opens on the indexed version; click Test live URL if you need a fresh fetch. For a page you do not own, use the Rich Results Test instead, which does not require verification.

How to check if a page is indexed?

Inspect the URL and read the verdict card. "URL is on Google" means it is indexed and eligible; "URL is not on Google" means it cannot appear. Google is explicit that eligibility is not the same as presence, and recommends searching for the page URL on Google as the definitive check, because the tool does not evaluate manual actions, security issues, legal removals, or temporary blocks. Use the tool for the reason, and a live search for the fact.

What does "URL is available to Google" mean?

It is the live test's positive verdict, and it makes a narrower claim than the index panel's "URL is on Google". It means the URL is not blocked and has no detectable errors that would prevent full indexing at the moment of the test. It does not mean the page is indexed, and it does not predict indexing: canonical selection, duplicate detection and the two "currently not indexed" statuses are all determined at indexing time and are not checked live.

What is the Google-selected canonical?

The Google selected canonical is the URL Google chose as the authoritative version when it found similar pages on your site. It may or may not match the canonical you declared — Google takes your declaration into consideration without guaranteeing it. If the page has no alternates, the selected canonical is the inspected URL itself. The value appears only in the indexed data, can lag the index by a few hours, and an unexpected URL here is the standard signal that two of your pages are being treated as duplicates.

How to use URL Inspection tool on a missing page?

Read the fields in diagnostic order rather than top to bottom: Last crawl first, to confirm the data postdates your change; then Crawl allowed?, then Page fetch, then Indexing allowed?, then Google-selected canonical. The first field that reports a problem is the one to fix, because the fields below it are describing consequences. Only when all five are clean should you treat the absence as a quality judgement rather than a configuration fault, and run a live test URL Google can reach to confirm the fix before requesting indexing once.