Using the URL Inspection tool
The URL Inspection tool in Google Search Console reports, for one URL, whether it is indexed, when Google last crawled it, which canonical Google chose, and any coverage or enhancement issues. Its live test fetches the URL in real time and shows the rendered HTML, loaded resources, and any crawl errors — making it the fastest way to diagnose why a specific page is or is not in the index.
What it reports
Enter a URL belonging to your verified property and the tool returns its current state in Google's index: whether it is on Google, when it was last crawled, whether crawling was allowed, whether indexing was allowed, and the canonical URL Google selected (which may differ from the one you declared).
It also surfaces any issues from the page indexing report and enhancement reports (such as structured data or mobile usability) tied to that specific URL, so you can see exactly what is blocking or affecting it.
- Index status: is the URL on Google, and when was it last crawled
- Google-selected canonical vs your declared canonical
- Coverage and enhancement issues specific to this URL
The live test and rendered output
The Test Live URL action fetches the page in real time, independent of the indexed version. It shows whether the live page can be crawled and indexed now, the rendered HTML after Google processes the page, a screenshot, and the list of resources Google loaded or could not load.
This is invaluable for JavaScript-heavy pages: if content present in the browser is missing from the rendered HTML, Google may not see it. Comparing the indexed result with the live test tells you whether a problem is already fixed (live passes, index stale) or still present (both fail).
Requesting indexing and its limits
After a live test passes, you can Request Indexing to add the URL to a crawl queue. This is suitable for individual important URLs, not bulk submission — for many URLs, rely on sitemaps and good internal linking instead. Requesting indexing does not guarantee or accelerate indexing; it only queues the URL for consideration.
Use URL Inspection for one-off, deep diagnosis of a specific page; use the page indexing (coverage) report to understand patterns across many URLs.
How it appears in analytics and logs
URL Inspection reveals how Google specifically treated one URL — indexed or not, the canonical it picked, the crawl result, and rendering output. Discrepancies between the indexed version and the live test pinpoint why a page is not ranking as expected.
Diagnostic use case
Diagnose a single page: confirm whether it is indexed, see Google's chosen canonical and last crawl, and run a live test to expose rendering or fetch problems.
What WebmasterID can help detect
WebmasterID shows which crawlers actually fetched a URL server-side, complementing URL Inspection: where Google reports its own view, WebmasterID confirms real crawler hits and statuses for the same page.
Common mistakes
- Treating Request Indexing as a bulk tool — it is for individual URLs.
- Assuming the indexed result reflects the live page; run the live test to compare.
- Ignoring the Google-selected canonical when it differs from your declared one.
- Overlooking unloaded resources in the live test that hide JavaScript-rendered content.
Privacy and accuracy notes
URL Inspection reports Google's crawl and index state for a URL, not visitor data. WebmasterID similarly records crawler interactions without attaching them to any person.
Frequently asked questions
- Does Request Indexing guarantee my page gets indexed?
- No. It queues the URL for crawling and consideration but does not guarantee or speed up indexing. Indexing still depends on Google's quality and crawl decisions.
Related pages
- Reading the Page Indexing (Coverage) report
The Page Indexing report (formerly Index Coverage) in Google Search Console shows how many of your pages are indexed and groups the not-indexed pages by reason — such as crawled-not-indexed, discovered-not-indexed, duplicate without user-selected canonical, excluded by noindex, blocked by robots.txt, redirect, or soft 404. Each reason points to a distinct fix.
- Fetch and render: how Google sees your page
Google crawls a page, then renders it with a headless Chromium-based engine before indexing, so the indexed content is the rendered DOM, not just the raw HTML. The old standalone Fetch as Google tool has been folded into the URL Inspection live test, which shows the rendered HTML, a screenshot, and loaded resources. Differences between raw and rendered output explain many JavaScript indexing problems.
- Canonical mismatch diagnosis
A canonical mismatch happens when your rel=canonical tag points one way while redirects, sitemaps, internal links, or hreflang point another. Conflicting signals confuse which URL should represent a piece of content, so crawlers may pick a canonical you did not intend. Aligning the signals fixes it.
- Website observability
Confirm which crawlers fetched a specific URL and the status they got, server-side.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.