URL Inspection: indexed version vs live test, field by field

URL Inspection, at the top of every Search Console screen, answers questions about a single URL: is it in Google's index, how did Google find it, when was it last crawled, which canonical did Google choose, what did the page look like to Googlebot, and is it eligible for rich results. For diagnosing a specific page it is the most precise tool available. It is also easy to misread, mainly because it shows two different things: what Google has stored, and what Google sees right now.

Two views: indexed result and live test

	Indexed result (default)	Live test
What it shows	Google's stored information from the last crawl and indexing	A fresh fetch and render of the page right now
Answers	"Is this page in the index, and why or why not?"	"Could Google crawl, render and index this page today?"
Canonical chosen by Google	Yes	No (not decided in a live test)
Rendered HTML and screenshot	Crawled page HTML (via "View crawled page")	Yes, including screenshot, resources and console messages
Use it for	Diagnosing indexing decisions	Checking a fix before waiting for a recrawl

A common confusion: the live test says "URL is available to Google", yet the page is not indexed. The live test only checks technical eligibility. Indexing also depends on Google's judgement of duplication and value, which only the indexed result reflects.

The indexed result, field by field

Top verdict

"URL is on Google", "URL is on Google, but has issues", or "URL is not on Google", with the reason. The reason uses the same labels as the Page indexing report.

Discovery

• Sitemaps: which submitted sitemaps list the URL. Missing here for an important page is worth fixing.
• Referring page: an example of a page linking to the URL. If this shows something unexpected, such as a tag archive or an old page, that tells you how Google found it.

Crawl

• Last crawl: date and time of the last crawl. Old dates on frequently changed pages suggest crawl priority is low.
• Crawled as: Googlebot smartphone or desktop. Almost all sites are crawled as smartphone.
• Crawl allowed?: whether robots.txt permits crawling.
• Page fetch: whether the fetch succeeded, or failed with a server error, a 404, a redirect error.
• Indexing allowed?: whether a noindex directive was found.

Indexing

• User-declared canonical: what your page says in its canonical tag.
• Google-selected canonical: what Google actually chose. If these differ, Google is treating your URL as a duplicate of another. Align the signals as described in the canonical tags guide.

Enhancements and experience

Detected structured data types (breadcrumbs, product snippets, merchant listings, videos and others), with errors and warnings, plus HTTPS status. If a rich result type you expect is missing here, the markup either was not found in the crawled version or has errors.

The live test in practice

Click "Test live URL". After a short wait, you get a verdict and the option to "View tested page", which has three tabs:

• HTML: the rendered HTML Googlebot ended up with after running JavaScript. Search it for your main content, links and canonical. If content you see in a browser is missing here, Google is not seeing it. See JavaScript sites and crawlers.
• Screenshot: how the page rendered, at the top of the viewport. A blank or broken screenshot points to blocked resources or script errors.
• More info: page resources that could not be loaded (often blocked by robots.txt or failing), JavaScript console messages, and HTTP response headers. Check headers for an X-Robots-Tag noindex that does not appear in the HTML.

The live test is ideal for confirming a fix: remove an accidental noindex, unblock a resource, fix a render error, then test live to see the change before any recrawl.

Request indexing: when it helps

After a live test, "Request indexing" asks Google to crawl the URL with priority. Useful for:

• A new important page you want crawled soon.
• A page you have substantially updated.
• A page where you fixed a blocking issue such as noindex.

Not useful for: pages Google crawled and chose not to index (it will likely make the same decision), large numbers of URLs (there is a daily limit, and sitemaps are the right tool), or repeated requests for the same URL. The sitemaps guide covers bulk discovery.

Diagnostic recipes

Symptom	Check in URL Inspection
Page not showing in search	Verdict and reason; Indexing allowed; Google-selected canonical
Wrong URL showing in results	Google-selected canonical on both URLs
Content changes not reflected	Last crawl date; then live test HTML to confirm the new content is visible
Rich results disappeared	Enhancements section on indexed result vs live test
JavaScript site with thin index coverage	Live test HTML: is the main content present after rendering?
Suspected hack or cloaking	Crawled page HTML vs what you see in a browser

A worked example

A hypothetical recipe site notices that a popular new recipe does not appear in search a week after publishing. URL Inspection shows "URL is not on Google: Crawled – currently not indexed", last crawled two days ago, with the Google-selected canonical pointing to an older recipe for a similar dish. The live test passes, so nothing technical is blocking it. Viewing the crawled HTML explains the rest: the recipe card is rendered by a script, and the HTML Google stored contains only the introduction, which is almost identical to the older recipe's introduction. To Google, the two pages looked like duplicates.

The site renders the recipe card into the HTML on the server, rewrites the introduction, and links the two recipes to each other with a sentence explaining the difference. A live test now shows the full ingredients and method in the HTML. After requesting indexing, the next indexed result shows the page's own URL as the selected canonical, and the recipe begins to appear for its own name within days.

Comparing two URLs

When the wrong page ranks or two pages seem to compete, inspect both. Compare their Google-selected canonicals, last crawl dates, referring pages and sitemap membership. If Google chose page A as canonical for page B, the question becomes why: are the contents near-identical, does internal linking favour A, does B redirect or noindex in some variant? The answers are usually visible within a few minutes of side-by-side inspection, and they point directly to the fix described in the duplicate content guide.

Using it at scale

The interface handles one URL at a time. The URL Inspection API returns the indexed result for many URLs (within a daily quota per property), which is useful for monitoring the index status of key pages, such as your top 500 products, on a schedule. It does not run live tests or request indexing. Combined with the Page indexing report for patterns and your own crawl for structure, it gives a complete view of how Google treats your important pages. DeskSEO's Search Console connection focuses on performance data (queries, pages, positions) rather than inspection, so the two complement each other.

Who can use it

Any user with access to the property can inspect URLs and run live tests. Requesting indexing requires owner or full user permissions. For agencies, that means restricted users can diagnose but not request crawls; plan permissions accordingly when onboarding clients. Inspection works only for URLs inside a verified property, so a Domain property is the most convenient for sites with several subdomains.

Common misreadings

• Treating "URL is available to Google" in the live test as proof that the page will be indexed.
• Assuming the indexed result reflects today's page. It reflects the last crawl.
• Ignoring the Google-selected canonical, which often explains everything.
• Inspecting a URL with a different protocol, host or trailing slash from the one you meant; each variant is a separate URL.