How to Use the Google Search Console URL Inspection Tool

The URL Inspection tool answers questions about one URL at a time: whether Google has indexed it, which URL Google chose as canonical, when and how Google last crawled it, what Google saw when it did, and whether the current live version could be indexed. Google’s help page describes it as providing “information about Google’s indexed version of a specific page”, and as a way “to test whether a URL might be indexable” (URL Inspection tool help). Those are two different views, the indexed result and the live test, and reading one as if it were the other leads to conclusions the next crawl can overturn.

Two views of the same URL

Google’s help page says of the indexed view: “This is not a live test. The results shown are from most recently indexed version of a page”. And about the live test: a passing live test means the URL might be indexable, not that Google’s systems have already changed anything.

Step-by-step inspection

1. Paste the full URL into the inspection bar at the top of Search Console. It must belong to the selected property.
2. Read the headline status. “URL is on Google” or “URL is not on Google”. Google warns that “URL is on Google” “doesn’t guarantee that your page is appearing in Search results”, because the tool does not account for every requirement for appearing.
3. Open Page indexing. This section shows:

• Discovery: sitemaps and referring pages through which Google found the URL. A URL that Google knows only from a sitemap, with no referring pages, may be an orphan page.
• Crawl: last crawl date, the crawler type, whether crawling was allowed, whether the page fetch succeeded, and whether indexing was allowed.
• Indexing: the user-declared canonical and the Google-selected canonical.

4. Open View crawled page to see the HTML, HTTP response and resources Google recorded.

1. Check enhancements (structured data, video) if relevant.
2. Run Test live URL if you changed something since the last crawl.
3. Request indexing if the live test passes and the page has changed.

Reading the key fields

Crawl allowed? If it says no, robots.txt blocks the URL. Google’s help page adds an important consequence: when a page is blocked by robots.txt, “Indexing allowed?” will always show “Yes” because “Google can’t see and respect any noindex directives”. The page “might appear in Search results even if indexing is blocked by your site”.

Page fetch. A failure here (server error, not found, redirect) is a direct explanation for a “not on Google” result.

Indexing allowed? “No” means Google found a noindex rule in the page or header.

User-declared canonical vs Google-selected canonical. Google states it “might select the user-declared canonical, but sometimes Google might choose another URL that it considers a better canonical example”. It also says “You can determine the canonical version only in the indexed data”. If the two differ, compare the pages and the signals pointing to each (redirects, internal links, sitemaps, hreflang).

A worked inspection with several outcomes

Say you inspect https://www.example.com/guides/heat-pumps/, a guide updated last week.

Outcome A: on Google, canonical matches. The indexed result shows “URL is on Google”, the user-declared and Google-selected canonicals match, and the last crawl was before your update. Nothing is wrong. Run a live test to confirm the new version is fetchable, then request indexing if you want the update picked up sooner.

Outcome B: not on Google, “Crawled, currently not indexed”. The crawl succeeded, indexing was allowed, but the page is not indexed. The tool cannot tell you why. Compare the page with similar pages on your site and on the web; with no technical block shown, duplication and value are the questions to examine.

Outcome C: Google chose a different canonical. The Google-selected canonical is https://www.example.com/heat-pumps/, an older page with similar content. Google sees them as duplicates. Decide which one should exist: redirect the old page to the new guide, or differentiate the two.

Outcome D: Crawl allowed? No. robots.txt blocks /guides/. Indexing allowed shows “Yes” only because Google cannot read the page. Fix the robots.txt rule, then run the live test.

Outcome E: live test fails but indexed result is fine. A deployment broke the page (500 error) after the last crawl. The indexed version is still in search, but the next crawl will see the error. Fix the server before Google recrawls.

Requesting indexing

Google’s help page states that after you click Request indexing, if the page passes a quick check for immediate indexing errors, “it will be submitted to the indexing queue”. The same page adds: “You cannot request indexing if the page is considered to be non-indexable in the live test.” Google’s recrawl guidance adds:

• there is a quota for submitting individual URLs;
• requesting a recrawl multiple times for the same URL will not get it crawled any faster;
• crawling can take from a few days to a few weeks;
• requesting a crawl “does not guarantee that inclusion in search results will happen instantly or even at all” (asking Google to recrawl).

Use the request for pages that changed meaningfully. For many URLs, submit an updated sitemap instead.

What the tool cannot tell you

• Why a page ranks where it ranks. It is not a ranking tool.
• Why Google judged a page not worth indexing. “Crawled, currently not indexed” is a state, not an explanation.
• What the future canonical will be. The live test cannot predict it.
• Site-wide patterns. One URL is a sample; the Page indexing report shows the pattern.

Using it alongside the Page indexing report

The Page indexing report groups many URLs by reason; URL Inspection explains one URL in detail. Start from the report to find which reason affects important pages, open an example URL from the report in URL Inspection, find the cause, fix it in the template if it is shared, run a live test on a few affected URLs, and then use the report’s Validate fix button. Google’s help page recommends exactly that combination: test the fix with the live test on a few pages, then validate.

A short checklist for every inspection

• [ ] Am I looking at the indexed result or the live test?
• [ ] Does the crawl date predate my change?
• [ ] Is crawling allowed? If not, the “indexing allowed” value is not meaningful.
• [ ] Do the declared and selected canonicals match?
• [ ] Does View crawled page show the content I expect, including content loaded by JavaScript?
• [ ] Is a request for indexing appropriate, or is a sitemap update better?

Name the view before acting on any field: the indexed result describes what Google uses now, and the live test describes what the next crawl could see. Read that way, the tool gives a precise account of how Google sees one URL.