How to read the URL Inspection tool, line by line
The URL Inspection tool reports what Google has on file for one page, not what your browser sees. Three of its lines decide whether the page is indexed, and this is how to read them in order — plus why a passing live test proves less than people think.
The URL Inspection tool answers one question: what Google currently has on file for this page. It does that in about a dozen labelled lines, and three of them decide everything — Crawl allowed?, Indexing allowed? and Google-selected canonical. The default view is not live. It reports the most recently indexed version, which is why the tool and the page in your browser can disagree without either being wrong.
Before you start
You need a verified Search Console property for the site, and you need to know that canonical tags are declarations rather than instructions — see how to use canonical tags. This chapter is about reading the report. Getting a page pushed into the queue in the first place is get your page indexed faster.
Two reports, and the difference matters
Inspect a URL and you get the indexed version by default. Google's help is explicit about it: "This is not a live test. The results shown are from most recently indexed version of a page, not the live version on the web." The live test is a second button, and it "fetches and examines the URL in real time. The information shown in the live test can differ from the indexed URL" (URL Inspection tool, read 2026-09-02).
So the two views answer different questions. The default answers "what does Google know". The live test answers "can Google fetch this right now". Fixing a page changes the second one immediately and the first one only after a recrawl, which is the single most common reason people think the tool is broken.
The default report is Google's memory. The live test is Google's eyesight. Comparing them is the actual diagnostic.
The url inspection tool line by line
The top line is a verdict in one of four states, and each one implies a different next move.
| Verdict | What to do next |
|---|---|
| URL is on Google | Nothing here. Move to the performance report. |
| URL is on Google, but has issues | Read the enhancements section; the page is indexed. |
| URL is not on Google | Work down the three deciding lines below. |
| URL is an alternate version | Google picked a different canonical. Go straight to the canonical rows. |
Below the verdict, the report is grouped. Discovery tells you how Google found the page, crawl tells you what happened when it fetched, indexing tells you which URL it settled on.
| Line | What it answers | Bad value means |
|---|---|---|
| Sitemaps | Which sitemap lists this URL | Blank: discovery depends on links alone |
| Referring page | Where Google found the link | Blank: possibly an orphan page |
| Last crawl | Date of the fetch behind this report | Old date: everything below is old too |
| Crawled as | Smartphone or desktop crawler | Mismatch with what you tested |
| Crawl allowed? | Did robots.txt permit the fetch | No: fix robots.txt, stop reading |
| Page fetch | Did the server return the page | Failed: server, redirect or timeout |
| Indexing allowed? | Any noindex on the page | No: find the noindex, nothing else matters |
| User-declared canonical | The URL your page names | Unexpected value: a template is guessing |
| Google-selected canonical | The URL Google chose | Different from yours: your declaration lost |
Do it: four steps
Read in this order. Each step has a finish line, and a failure at any step makes the rest irrelevant.
- Read the verdict and write it down verbatim. Finish line: you can say which of the four states you are in without paraphrasing.
- Check
Crawl allowed?thenPage fetchthenIndexing allowed?, in that sequence. Finish line: the first "no" you hit is the thing you fix, and you stop there. - Compare the two canonical rows. Finish line: they match, or you have written down what Google chose instead.
- Run the live test and compare it against the default view. Finish line: you know whether the problem is current or historic.
Step 2 is an order, not a checklist. A page blocked in robots.txt will also show unhelpful values further down, and chasing those first is how an afternoon disappears.
Deliverable: the canonical mismatch order
When Google-selected canonical differs from User-declared canonical, work through these five in sequence and stop at the first hit.
- Does the page actually ship a canonical tag? Fetch it and look; templates drop it more often than anyone expects.
- Does the tag point at a URL that returns 200, on the same protocol and host you intend?
- Does the page Google selected have near-identical content? If so, it made a duplicate call, and the fix is differentiation rather than markup.
- Is the chosen URL the one your internal links point to? Google weighs your links, and a canonical that contradicts every link on the site is a weak signal.
- Is the chosen URL in your sitemap while the declared one is not?
None of these five requires a tool beyond curl and the report itself. If you get through all five with nothing found, record the pair and move on — a canonical disagreement on a page that is otherwise indexed is not an emergency.
Three ways this goes wrong
The first is reading a stale report as today's state. Last crawl is printed at the top of the crawl section for exactly this reason, and if it says six weeks ago then every line under it describes a page that may no longer exist in that form.
The second is treating a green live test as confirmation of indexing. Google answers this directly: "Does a valid result mean that my page will be indexed? No. The live URL test only confirms if Google-InspectionTool can access your page for indexing." The same page adds that "even if you get a valid or warning verdict in the live test, your page must still fulfill other conditions in order to be indexed".
The third is hammering "Request indexing" on the same URL. Google states that "there's a quota for submitting individual URLs and requesting a recrawl multiple times for the same URL won't get it crawled any faster", and puts the realistic window at "anywhere from a few days to a few weeks" (Ask Google to recrawl your URLs, read 2026-09-02).
Where this stops
The tool is one URL at a time, which makes it a diagnostic instrument and not an audit. Twelve pages is fine. Twelve hundred is a job for the page indexing report and your sitemap, and anyone inspecting URLs one by one at that volume is doing manual work a file could do.
It also cannot tell you why Google chose not to index a page that it fetched successfully. Crawl allowed, page fetched, indexing allowed, and still not on Google — the report has no line for that, and neither do we. What is left at that point is the page itself and how long it has been live, which is covered in how long does it take to get indexed. Before spending a week on it, confirm that an engine can read the content at all with the QueryWin gap check.
Common questions
What does the URL Inspection tool actually show?
By default, Google's most recently indexed version of the page: how it was discovered, when it was last crawled, whether crawling and indexing were allowed, and which URL Google treats as canonical. The live test is a separate action that fetches the page in real time.
Why does it say my page is not on Google when I can see it?
Seeing your page in a browser proves your server is serving it. The report describes Google's own record, and the two are updated on different clocks. Check Last crawl first, then run the live test to compare.
What does "URL is an alternate version" mean?
Google decided that another URL is the canonical one for this content, so this address is treated as a variant. Go to the two canonical rows and work through the five-step order above.
Does requesting indexing make it faster?
Once, possibly. Repeatedly, no — Google states that repeat requests for the same URL do not speed anything up, and that a crawl can take from a few days to a few weeks.
Which crawler runs the live test?
Google-InspectionTool, which is a separate agent from Googlebot. If your firewall rules are written by user agent name, that distinction is worth checking before you conclude anything from a failed fetch.
Part of the QueryWin handbook · Level 2
