How to Use the URL Inspection Tool in Google Search Console

What URL Inspection tells you, and when to open it

URL Inspection shows how Google sees one URL: whether it is indexed, which canonical Google chose, when the page was last crawled and how it renders ^[1]. It works on one page at a time, inside a property you own, and it is the first tool to open when a page is missing from Google. Use it to check a new or changed page, debug a page missing from search, confirm a canonical or see how Googlebot renders JavaScript. It is the right tool for single-page problems and the wrong tool for site-wide counts. For those, the Page indexing report does the job.

Opening it, in the right property

Type the full URL into the inspection bar at the top of any Search Console screen, or click the inspect icon next to an example URL in the Page indexing report. On a large site the icon is usually the faster route, because you start from a reason in the report and see on one screen whether the problem is the page or the signals pointing at it. The URL must belong to the property you have open, so an https www page cannot be inspected inside an http property. A Domain property avoids most of these mismatches.

Reading the verdict at the top

The top card gives a verdict for the indexed version of the page. "URL is on Google means that the URL is eligible to appear in Search results, but is not guaranteed to be there", and eligible is not the same as ranking. If a page is on Google but gets no impressions, the problem is relevance or competition, so it needs content and links, not another request. A second verdict says the URL is on Google but has issues, such as broken structured data or AMP. Rich results may then not appear, so expand Enhancements, fix the markup and request validation from that report.

Not on Google, unknown, or an alternate

When the URL is not on Google, the Page indexing section gives the reason: blocked by robots.txt, noindex, a redirect, a duplicate or a crawl problem, each matching a status in the Page indexing report ^[2]. Read the reason before acting. A noindex needs a template change, a robots.txt block needs a rule change and a duplicate needs canonical work. None is fixed by requesting indexing. An unknown URL is one Google has never seen, which is normal for a brand-new page; linking it from an indexed page speeds discovery. An alternate version means Google indexed another URL instead, which is usually fine for mobile, AMP or parameter variants.

The indexed version versus the live test

By default the tool shows the indexed version, not the live page, and it says so plainly: this is not a live test. All other Google testing tools test only live pages, so this is the most common reading error. The default view answers what Google has. The live test answers what Google would get if it fetched the page right now. Click Test live URL to run one. The page must be reachable from the internet without a login, results usually appear within a minute, and there is a per-property daily limit on live inspections.

What the live test checks, and what it cannot

The live test checks whether Google can crawl, fetch and index the page, and whether structured data is valid. For an available page, Crawl allowed should read Yes, Page fetch Successful and Indexing allowed Yes; anything else explains a problem. It is the right way to confirm that a fix shipped, for example that a noindex tag is gone, before you spend an indexing request. The limits matter as much. The live test does not check sitemaps or referring pages, it cannot predict whether the tested version will be chosen as canonical, and a valid live test does not guarantee indexing.

The details, field by field

Crawl allowed, Page fetch and Indexing allowed

Crawl allowed says whether robots.txt lets Google fetch the URL. Mind the trap. If robots.txt blocks the page, Indexing allowed shows Yes, because Google cannot see the noindex, and the page might still appear in results; unblock it and use noindex if you want it out. Page fetch reports whether Google got the page and any error, such as a soft 404, a 404, a 401, a 403 or a 5xx. Fetching can succeed even when the page is not indexed for another reason, so a good fetch only removes one suspect. Indexing allowed shows whether a noindex tag or header blocks indexing, and with indexifembedded plus noindex the page is indexed only when embedded.

If Indexing allowed says No on a page you want indexed, the cause is almost always a template, plugin or staging setting. Staging sites copied to production are the classic case. Many content systems add a site-wide noindex while a site is marked private or in development. To find it, search the rendered HTML for a robots meta tag and check the response headers for X-Robots-Tag, since plugins, staging switches and CDN rules add them silently. Once it is removed, run a live test, request indexing and recheck after the next crawl.

Last crawl, crawler and discovery

Last crawl shows when Google last crawled the page, in your local time, and everything else in the tool comes from that crawled version. A crawl older than your fix means Google has not seen it. A crawl date months old on an important page is worth investigating through internal links and the sitemap. The details also name the crawler, usually Googlebot smartphone, and content that exists only on desktop may not count. The Sitemaps and Referring page fields show how Google found the URL. If both are empty, Google found it some other way, or barely knows it.

Canonicals: whose choice wins

Two fields decide most duplicate problems. The user-declared canonical is the one your page states through a link tag, HTTP header or sitemap; if it is empty, you have not declared one. The Google-selected canonical is the URL Google actually chose. It can be a few hours behind the index, and it comes only from indexed data, never from the live test. When the two match, your signals agree with Google's. When the selected one is an http address on an https site, or a URL with tracking parameters, Google found stronger signals pointing there, and the usual cause is internal links or a sitemap still using the old address.

A declared canonical is a hint, not an order. If your declared canonical is not similar to the page, Google will never choose it, and a canonical tag fighting three other signals usually loses. The Page indexing report then lists the page as a duplicate where Google chose a different canonical than the user. The fix is alignment. Check that your canonical target returns 200, is indexable and is linked internally, then point internal links, sitemaps and redirects at the URL you want, so every signal says the same thing. Only then is it worth asking Google to look again.

Seeing the page as Googlebot rendered it

After a live test, View tested page opens the screenshot, HTML and more info panels, and the screenshot exists only in a live test. It shows the rendered viewport Googlebot saw, from the mobile version of the page. Blank areas, cookie walls over content or missing images point to rendering or blocking problems. A consent overlay or newsletter popup covering most of the screenshot is a common finding. The screenshot is also the first stop for a soft 404. If the page looks empty or says not found, Google is right, so return a 404 or add real content.

The HTML tab shows the rendered HTML, while browser view-source shows only the original code before scripts run. Search the rendered version for your main text and internal links. If they are missing there but present in the browser, Google is not running, or not allowed to fetch, the scripts that build the page. The More info panel lists resources Google could not load and JavaScript console messages, and blocked scripts or stylesheets can change what Google renders. Lower down, Enhancements lists the structured data types found and whether they are valid. Not every rich result type is supported yet, so use the Rich Results Test for the rest.

Requesting indexing, and when not to

After a live test, Request indexing asks Google to index the page, but you cannot request it when the live test calls the page non-indexable. Think of it as a priority flag for one page, not a submission system. Google still decides on its usual criteria, and a weak page requested ten times remains a weak page. The same help page gives several estimates for timing, from a day or so to a week or two, so plan for days rather than hours. Inspect again later. If the last crawl date changes but the verdict does not, the issue is quality or duplication.

The quota, and the better tool for many pages

There is a daily limit on indexing requests, and "The request will fail silently if you have exceeded your quota". The interface does not show the number. Spend requests on pages that matter. For many pages, Google says a sitemap with updated lastmod values is your best choice, and it suggests asking for a recrawl only after an important change it has not noticed for a week or more ^[2]. Requesting indexing for every blog post on launch day mostly burns quota you may need later for a broken page. Inspections have their own daily limit per property, so a large audit should sample templates.

When the tool cannot reach the page

The live test needs a page reachable without a login. If it sits behind a firewall, Google suggests exposing it to the tool through a tunnel, but never allow Googlebot by user agent alone, because Googlebot can be spoofed. Certificates matter too. Google will not test an HTTPS URL unless the certificate is valid, and an expired or misissued certificate usually affects the whole site, so check the HTTPS report when every live test fails with a site-wide issue. The same goes for robots.txt. If it exists but cannot be reached, Google will not crawl the site, and the live test reports a site-wide issue under Page fetch; check robots.txt availability in Crawl Stats.

For pages you do not own, URL Inspection is closed to you. The Rich Results Test works on any URL with no login and shows the rendered HTML too, though it cannot show index status. It also covers resources on another domain, such as an image on a CDN. For a definitive check that a page is really on Google, search for it: trim the protocol and parameters and paste the URL into the search box. Inspection describes eligibility. A search shows reality at that moment, in that location.

Playbooks for the usual problems

When a page is missing from search, inspect it first. If the URL is unknown, request indexing and add internal links; if it is excluded, read the reason. If it is indexed, check for manual actions and removals, since an approved removal request can hide an indexed page, and allow at least a week after submitting before assuming a problem. After a site migration, inspect a sample of old and new URLs: old ones should show Page with redirect and new ones should be on Google. Google says a medium-sized move can take a few weeks to notice, so keep inspecting weekly until the new URLs dominate.

Template releases deserve the same discipline. Inspect one URL per template right after release, covering the product, category, article and home pages, run live tests and compare the rendered HTML. A broken template affects thousands of pages at once, so five inspections on release day can catch a problem that would otherwise surface as an indexing drop three weeks later. A missing canonical or an accidental noindex gets caught the same day. That is cheap insurance.

A five-minute weekly routine covers the rest. Pick five URLs: the home page, the best-selling product, a top article, the newest page and one page you recently fixed. Inspect each, note the verdict and last crawl date, and run a live test only where something looks wrong. Five minutes a week catches most indexing problems before the Page indexing report shows them. There is no share link for a single inspection, so copy the verdict, both canonicals and the last crawl date into the ticket.

The API and bulk inspection

The URL Inspection API returns the index status of a URL as Google sees it, but only the indexed version; you cannot test a live URL through it ^[3]. It cannot request indexing either, and it needs the webmasters or webmasters.readonly scope. The quotas are 2,000 inspections per site per day and 600 per minute, with a cap of 10,000,000 a day per project ^[4]. At 2,000 a day, a 20,000-URL site needs ten days to inspect every page once, which is why most teams inspect templates and money pages rather than everything.

Third-party tools wrap the API for batches. Serpstat's Indexing Inspection checks up to 100 URLs at a time, free for registered users, and the community mcp-gsc server inspects up to 10 URLs per batch. Google publishes no official Search Console MCP server. For live tests and indexing requests, you still need the interface, and our Search Console API guide walks through the setup and the quotas in more depth.

Common mistakes, and the tools next to it

The mistakes repeat: reading the indexed version as if it were live, requesting indexing for every new page, expecting a valid live test to mean indexed, inspecting a URL in the wrong property and ignoring the canonical fields. Each leads to waiting for a fix that was never needed. Use the Page indexing report for counts and patterns across the site and URL Inspection for one page. The site: operator shows only a sample bound by indexing and retrieval limits, so Google calls URL Inspection more reliable for debugging. For the reasons behind every exclusion status, see our Page indexing errors guide.

The bottom line

URL Inspection is the single-page truth about Google's index: verdict, canonical, crawl date and rendering. Read the indexed version first, run a live test only to check a fix, and request indexing sparingly, because the quota is limited and over-quota requests fail without warning. Note the crawl date first. Always. If a page is indexed but still earns nothing, the question moves to rankings, which our Performance report guide covers. For anything bigger than a few pages, switch to the Page indexing report or the API.