How to Use the URL Inspection Tool

Every other Search Console report is aggregate. URL Inspection is the microscope: one URL, everything Google knows about it. When the Page indexing report tells you *that* something is wrong across 400 URLs, this is the tool that tells you *why* on any one of them.

Index status vs. live test — a distinction that matters

The tool has two modes, and confusing them wastes more debugging time than anything else in Search Console.

Reading the verdicts

Expand Coverage and read four fields in this order — they answer nearly every indexing question you will ever have:

1. 1Discovery — how Google found the URL. Sitemap? Referring page? If neither, the page is orphaned.
2. 2Crawl — when it was last crawled, and whether the fetch succeeded. A date months old on an important page means crawl budget trouble.
3. 3Indexing → User-declared canonical — the URL *you* declared.
4. 4Indexing → Google-selected canonical — the URL *Google* chose.

Rendered HTML: seeing the page as Googlebot does

Under the live test, View tested page gives you the HTML *after* Google ran your JavaScript, plus a screenshot and the list of resources it could not load. For any JavaScript-heavy site this is the highest-value screen in Search Console.

What to look for:

• Is your actual content in the rendered HTML? If the body is an empty <div id="root">, Google is indexing nothing. Client-only rendering is the cause.
• Is the canonical tag present in the rendered output? Tags injected by client-side JS are unreliable — Google may never execute the code that adds them.
• Which resources failed? A blocked JS bundle can mean the page never renders. Check that robots.txt is not disallowing /_next/ or /static/.
• Does the screenshot look like the page? A blank or broken screenshot is Google telling you it cannot see your site.

Request indexing — what it is actually for

The button adds the URL to a priority crawl queue. It is genuinely useful in exactly two situations: you published something new and want it crawled today, or you fixed a problem and want the re-crawl accelerated.

It is not useful for anything else, and this is where people burn hours:

• It is not a ranking lever. Requesting indexing repeatedly on the same URL does nothing. There is no queue position to improve.
• It cannot overrule a quality judgement. If a page is 'Crawled – currently not indexed', Google already looked and said no. Asking again gets the same answer, because nothing about the page changed.
• The daily quota is small — on the order of a dozen or so URLs per property per day. Spend it on genuinely new or genuinely fixed pages.
• It does not scale. If you need hundreds of URLs re-crawled, the fix is a clean sitemap and a healthy site, not clicking a button hundreds of times.

A debugging sequence that works

1. 1

   Inspect the URL

   Read the verdict and, if it is not indexed, the reason directly beneath it.

2. 2

   Compare the two canonicals

   If they disagree, that is your bug, and it is almost always in your own markup. Fix it before looking at anything else.

3. 3

   Run the live test

   Does the problem still reproduce against the current deploy? If not, you are simply waiting on a re-crawl.

4. 4

   Open the rendered HTML

   Confirm your content and canonical tag exist in the output Google actually parsed, not just in your source files.

5. 5

   Request indexing — once

   Only after the live test is clean. Then leave it alone; re-requesting does not speed anything up.

When the same root cause turns up across many URLs, stop inspecting one at a time and go back to the Page indexing report to fix it at the source.