When a single page misbehaves, every other Search Console report shows you aggregates — the URL Inspection tool shows you that page, through Google’s eyes. Index status, the canonical Google actually selected, the last crawl, the rendered HTML, and a live re-test on demand: it is the most direct diagnostic in the toolbox, and most people use a tenth of it. This walkthrough covers every panel, the live-test-vs-index distinction that confuses everyone, and what “Request indexing” honestly does.
What the Tool Shows
Paste any URL from your property and the tool returns Google’s stored record of it: whether it is on Google, the sitemaps and referring pages that led to it, the last crawl date and result, whether crawling is allowed, whether indexing is allowed, the user-declared canonical, and — crucially — the canonical Google selected.
That stored record is the index’s memory of the page, not its current state. If you fixed something an hour ago, the inspection still shows the world as of the last crawl — which is exactly what makes the tool useful for answering “what did Google see when it decided this?” The official URL Inspection documentation lists every field; this guide focuses on how to read them together.
Indexed Version vs Live Test
The tool has two modes. The default view is the indexed version: what Google stored at last crawl. The “Test live URL” button fetches the page right now and reports what Google would see today. Diagnosis lives in the difference between the two.
Same verdict in both: the state is stable — whatever you are investigating predates the last crawl and persists. Indexed version fails but live test passes: you already fixed it; Google has not recrawled yet — this is the one legitimate moment for Request indexing. Indexed passes but live fails: you just broke something — a deploy, a plugin, a robots edit — and the index simply has not noticed yet. That three-way read turns the tool from a status page into a timeline.
Reading Every Panel
Four panels carry the diagnosis: Indexing (crawl allowed? indexing allowed? which canonical won?), the referring sources (how Google found the URL), Enhancements (structured data validity), and — inside the live test — the rendered HTML and screenshot showing the page after JavaScript execution.
The canonical pair is the panel most worth internalizing: “User-declared” vs “Google-selected” disagreeing is the root of most duplicate-canonical situations. The crawl details tell you whether fetching was blocked by robots.txt or the page by a noindex — different problems with different fixes. And the rendered HTML is where JavaScript sites find their truth: if content is missing from the rendered view, Google is ranking a page without it — the failure modes covered in our rendering SEO guide and Google’s JavaScript SEO basics. Structured-data errors surfaced here map to the work in the structured data guide — and you can pre-validate markup with our free Schema Validator.
Request Indexing, Honestly
Request indexing adds the URL to a priority crawl queue. That is all. It does not overturn quality decisions, does not guarantee indexing, and repeat-clicking does not accelerate anything — the queue position is the queue position, and the daily quota is small by design.
The legitimate uses: a genuinely new page you want discovered fast, and a fixed page where the live test now passes. The illegitimate use — resubmitting an unchanged page stuck in Crawled — currently not indexed — wastes the quota and your attention: that status is a content verdict, and the queue leads back to the same judge. Ration the button to URLs where something actually changed.
Diagnostic Workflows
Three inspections cover 90% of real cases. Page not ranking: inspect → is it indexed at all? Wrong page ranking: inspect both → whose canonical won? Traffic dropped after a deploy: live-test your templates → does rendered HTML still contain the content?
Chain the tool with the aggregate reports: the Page indexing report finds the pattern, URL Inspection confirms the mechanism on representatives, and the Performance report measures whether the fix moved anything — the loop the whole Search Console cluster is built around. For sites with thousands of URLs, the same inspection data is available programmatically via the URL Inspection API (2,000 requests per property per day), which turns spot-checks into audits — and if that audit uncovers structural problems, our services exist for exactly that handoff.
- The default view is Google’s memory (last crawl); the live test is the present — diagnosis lives in the difference.
- The user-declared vs Google-selected canonical pair explains most “wrong page is ranking” mysteries.
- Rendered HTML in the live test is ground truth for JavaScript sites — missing content there is missing for ranking.
- Request indexing is a queue ticket, not an appeal: use it for new pages and verified fixes, never as a retry ritual.
- Scale the same diagnostics with the URL Inspection API (2,000 requests/property/day) when spot-checks become audits.
Frequently Asked Questions
Why does the tool say “URL is not on Google” but the page shows in search?
Usually a property or variant mismatch: you inspected the http or non-www variant while the https/www version is indexed, or the indexed URL differs by trailing slash or parameters. Inspect the exact canonical URL — character for character — before concluding anything.
How current is the information in the default view?
Exactly as current as the last crawl, whose date is shown in the crawl panel — days to weeks old depending on the page’s crawl frequency. For the present state, run the live test; for what Google’s decisions were based on, read the stored version.
How many times per day can I request indexing?
The quota is intentionally small — roughly a dozen URL submissions per property per day, with the exact figure undocumented. Batch needs beyond that are what sitemaps and honest lastmod dates are for; the button is a scalpel, not a pipeline.
Can I inspect a competitor’s URL?
No — the tool only works for URLs in properties you have verified. It reads Google’s private index record for your site, which is precisely why its data is more authoritative than anything a third-party crawler can infer about you.
What does “Indexed, though blocked by robots.txt” mean?
Google indexed the URL from external signals without being able to fetch its content — robots.txt blocks crawling, not indexing. The result is an ugly, description-less listing. If you want it gone, allow the crawl and add noindex, or use removal for urgent cases.
The Bottom Line
URL Inspection is the difference between guessing what Google did and reading the record. Learn the indexed-vs-live distinction, trust the canonical pair over your assumptions, treat rendered HTML as the only HTML that counts, and spend Request indexing like the scarce currency it is. One URL at a time, it answers the question every other report only gestures at: what, exactly, did Google see?
Further reading & sources
- URL Inspection tool — Google Search Console Help
- JavaScript SEO basics — Google Search Central
See how your site actually shows up in AI search. An AI visibility audit maps where you’re cited, where you’re invisible, and what to fix first — in plain English.
Get your AI visibility auditTry the free SEO tools →
Prefer self-serve? The interactive checklists turn guides like this one into a working to-do list.
Keep reading in Google Search Console
Get one email when something genuinely changes
AI search moves fast and most of it is noise. We send one short email when a real shift is worth your time. Unsubscribe anytime.
Published by Plain Intelligence — practical AI SEO, GEO, and technical SEO, documented in plain English. About Plain Intelligence →
↑ Back to Google Search Console · Explore all articles · Free tools & resources · Glossary