URL Inspection Tool: How to Use It in Search Console

The URL Inspection tool in Search Console shows how Google last saw one specific page and lets you test its current live version. Use it to check indexing status, the canonical Google selected, the rendered HTML and crawl details, and to request indexing for a few important pages. It diagnoses single URLs; it is not a quality score.

Canonical signals are among the first things this tool reveals, and they are everywhere: the 2024 Web Almanac found canonical tags on 65% of mobile pages and 69% of desktop pages, and 83.9% of mobile sites returned a 200 status for robots.txt.

What the URL Inspection tool does

Google’s URL Inspection help page describes two jobs. First, it lets you examine Google’s indexed version of a page. Second, it lets you test whether a URL might be indexable. You use it by pasting a fully qualified URL, including the protocol, into the inspection bar at the top of Search Console, or by clicking the inspect link next to a URL in a report.

I use it constantly in audits because it answers a question no crawler can: what does Google itself have on record for this page? A crawling tool tells you what your page looks like to a tool. This tells you what happened when Google came calling.

Indexed version versus live test

This is the distinction people miss, and it causes most of the confusion. The tool has two views of the same URL, and they can disagree.

	Indexed version	Live test
What it shows	Information from the most recent crawl and index entry	The page fetched and examined in real time
Best for	Understanding why a page is or is not in Google today	Checking that a fix works before Google recrawls
Can be out of date?	Yes. The page may have changed since the last crawl.	No, it is current
Shows referring pages and sitemaps?	Yes	No
Shows a screenshot?	No	Yes

The rule I follow: diagnose with the indexed version, verify with the live test. If you fixed a noindex tag yesterday, the indexed version will still show the old state, while the live test should show the new one. A mismatch between them is not an error; it just means Google has not recrawled yet.

Rather have an expert do this for you?

Hand it over and get back to running your business.

Hand it over to me

How to read the result

At the top, the tool gives an overall verdict. In the help documentation these are variations on the page being on Google, being on Google with issues, not being on Google, or being an alternate version. Below that, expandable sections give the detail.

Be careful with the best-looking verdict. Google itself notes that “URL is on Google” does not guarantee the page will appear in search results. Indexing means the page is eligible; it says nothing about whether it will rank, or for what. For that you need the Search Console performance report, which shows impressions and clicks.

The reverse is more useful. When the verdict is “not on Google”, the reason shown is your starting point. Two of the most common reasons are covered in separate guides: crawled, currently not indexed, where Google fetched the page and chose not to keep it, and discovered, currently not indexed, where Google has not fetched it yet.

Canonical: user-declared versus Google-selected

If I could only look at one field in this tool, it would be the canonical comparison. The tool shows the canonical you declared, if any, and the one Google selected. When they match, all is well. When they differ, Google has decided another URL is the better representative.

Google’s canonicalisation documentation explains why this happens: a canonical tag is a hint, not a rule, and Google chooses the page it judges the most complete and useful using several signals, such as redirects, HTTPS and sitemap inclusion. Common reasons your preference is overridden include:

The two pages are near duplicates, so Google picks the one it prefers.
Your canonical tag points to a redirecting, blocked or non-indexable URL.
Internal links, sitemaps and redirects all point to a different version from your tag.
A parameter, trailing slash or HTTP version is competing with the clean URL.

The fix is almost always to make your signals agree: one URL, linked internally everywhere, listed in the sitemap, with a self-referencing canonical. Where the Google-selected canonical is a different page entirely, you probably have duplicate content to consolidate.

The crawled page view: what Google rendered

The “view crawled page” option opens detail that is invaluable for technical diagnosis. It includes the rendered HTML, the HTTP response headers, JavaScript console messages and the resources the page loaded. For the indexed version, this is available when the page was crawled successfully. The live test adds a screenshot.

Here is what I look for:

Is your main content in the rendered HTML? If the text appears in your browser but not in the rendered version, a script is failing or content depends on user actions, and Google may be indexing an empty shell.
Are links real links? Navigation built from elements that are not proper anchor links may not be followed.
What do the headers say? Look for an X-Robots-Tag noindex header, unexpected redirects or a wrong content type, none of which show in the visible page.
Which resources failed to load? Blocked CSS or scripts can change how Google sees the layout and content.
What do the console messages say? Script errors often explain missing content.

Discovery and crawl details

For an indexed version, the tool reports how Google found the URL, such as through sitemaps or referring pages, and when it was last crawled, with the kind of crawler used and whether the page fetch succeeded. Three observations are worth acting on.

No referring page, only a sitemap. The page is probably under-linked. Add contextual internal links, and check the internal links section of the Search Console links report.
An old last-crawl date on an important page. Google is not revisiting it often. Improve its links and its usefulness.
Page fetch failed. Look at the reason: blocked by robots.txt, server error, not found or redirect. Each has a different fix.

Request indexing: when it helps and its limits

After a live test passes, you can ask Google to index a URL. Google says indexing typically takes only a day or so but can take much longer, and that there is a daily limit on how many requests you can submit per property. It does not publish the exact number, so do not plan around one.

My guidelines for using it:

Use it for a new page that matters, or a page you have just fixed in a significant way.
Run the live test first, so you are not requesting a page with a visible problem.
Request once. Repeating the request does not speed anything up.
For many pages, rely on sitemaps and internal links instead. If you are setting up a new property, my guide to submitting a website to Google Search Console covers sitemaps and first steps.
If a page is not indexed because Google judged it low in value, requesting does not change that judgement. Improve the page first.

What the tool does not tell you

The tool is a technical inspection, and Google is clear about what it does not test: compliance with quality and security guidelines, manual actions or security issues, legal removals and temporary URL blocks. A page can pass every check here and still be a weak page that never ranks. Conversely, a “not on Google” verdict does not tell you why a human reviewer might find the page lacking. Treat the tool as a window onto Google’s technical handling of one URL, not as a verdict on its worth.

A five-step routine for any problem URL

Inspect the URL and note the verdict and the last crawl date.
Compare the two canonicals. Resolve any difference before doing anything else.
Open the crawled page and check the rendered HTML, headers and console for missing content or blocking.
Run a live test after any fix, and compare it with the indexed version.
Request indexing only if the page matters, then recheck in a few days.

This single-URL routine is one layer of a broader technical review. See what a professional SEO audit includes for how it fits with site-wide crawling, content and link checks, and my explanation of the Search Console coverage report for the site-wide version of the same statuses.

Questions people ask about the URL Inspection tool

Why does the live test pass when the indexed version shows a problem?

Because they describe different moments. The indexed version reflects the last crawl; the live test reflects the page right now. If you fixed something recently, the live test passing means the fix works, and the indexed version will update after Google recrawls.

Does “URL is on Google” mean my page will rank?

No. It means the page is in the index. Whether and where it appears depends on relevance, quality and competition, which you can study in the performance report.

How many URLs can I request indexing for?

Google applies a daily limit per property but does not publish a figure. Save requests for new or significantly fixed pages that matter, and let sitemaps and internal links handle the rest.

Why is Google’s canonical different from mine?

A canonical tag is a hint, and Google weighs it with other signals. If your redirects, links and sitemap point elsewhere, or the pages are near duplicates, Google may choose differently. Align your signals or consolidate the pages.

If you would like someone to run this routine on your key pages and report what is holding them back, that is part of my SEO audit services. You can ask for a free audit and I will point you to the first fixes.

More in this series (SEO measurement and Search Console): start with What a Professional SEO Audit Includes (and Red Flags), then explore: