How to use the URL Inspection tool in Search Console

You use the URL Inspection tool to see what Google did with a single page and why. This guide shows what each panel says, how to run a live test, what Request indexing does, and how to fix three common cases. It is for founders who own Search Console and ship the site themselves.

By , founder of Porteur · Updated 14 September 2026 · Markdown

What the URL Inspection tool does and when to use it

Use it when you have a question about one URL on your verified property. It shows whether the page is on Google, how Google found it, when it last crawled it, and what canonical it chose.

  • On Google or not, with the reason
  • Discovery: referring page and sitemap
  • Last crawl date and which crawler fetched it
  • Crawl and index permissions
  • User-declared canonical versus Google-selected canonical
  • Enhancements found, such as structured data

Open Search Console, pick your property, paste the full URL in the inspection search bar. The tool only works for URLs inside that verified property.

Read each panel: what it says and how to act

  • Indexing status: States if the URL is on Google. If not, it gives a reason. This is your starting point.
  • Discovery: Shows a referring page and any sitemap that listed the URL. Use this to fix missing or wrong links and sitemap entries.
  • Crawl: Gives the last crawl date and the crawler used. If the last crawl is old for a page that changes often, request indexing after you fix issues.
  • Crawl allowed: Shows robots.txt and meta robots checks. If blocked, remove the block or accept that the URL will be out of the index.
  • Indexing allowed: Shows whether noindex is present. Remove noindex for pages you want indexed.
  • Canonical: Compares your rel=canonical with the URL Google selected. If Google chose differently, review duplication and internal linking.
  • Enhancements: Lists structured data detected. Fix errors in your code or templates, then request indexing for the URL.

A clean page shows: On Google, discovered from your XML sitemap, crawled last week by Googlebot Smartphone, crawl allowed, indexing allowed, your canonical equals Google’s canonical, and enhancements valid.

How the Page indexing report relates to inspection

Use the Page indexing report to spot patterns. Then use URL Inspection to debug one URL. The report lists every URL Google knows as Indexed or Not indexed, with a reason for each, as of 2026.

  • Crawled, currently not indexed: Google fetched the page but did not index it. Often thin, near-duplicate, weakly linked, or low overall site quality.
  • Discovered, currently not indexed: Google knows the URL but has not crawled it yet. Common on new or very large sites, or when crawling would overload the server.
  • Not found (404): The page returned 404. Correct for URLs that should not exist. Fix links and sitemaps that still point there. Redirect only if the old URL had value and there is a close match.
  • Soft 404: The server returned 200 but the page looked like an empty or error page. Return a real 404 or add real content.
  • Duplicate without user-selected canonical: Duplicates exist without rel=canonical. Declare a canonical on each duplicate.
  • Duplicate, Google chose different canonical than user: You set a canonical, but Google picked another. Fix duplication and signals, not just the tag.
  • Page with redirect: The URL redirects. The target gets indexed. Update internal links and sitemaps to the final URL to avoid chains.
  • Excluded by noindex tag: A noindex is present. Remove it if you want the page indexed.
  • Blocked by robots.txt: Robots.txt disallows crawling. Google can still index the URL without content if linked, shown as Indexed, though blocked by robots.txt.
  • Server error (5xx) and Redirect error: Fetch failures to fix before revalidating.
  • Alternate page with proper canonical tag: Google agrees this URL is an alternate and indexes the canonical.

From that report, click an example URL, then Inspect URL. That takes you into the URL Inspection detail for that page to confirm the signals and plan a fix.

Test live URL: what to check and how to use View tested page

Test live URL fetches the page now. It ignores the indexed copy and shows the current response and render. Use it when the indexing status looks stale or wrong for the current code.

  1. Run the live test

    Click Test live URL. Wait for the result. You will see whether the live URL is indexable, plus any new issues not in the indexed view.

  2. Open View tested page

    Click View tested page. Review the rendered HTML, the screenshot, the HTTP response, page resources that failed to load, and JavaScript console messages.

  3. Compare indexed versus live

    Switch between the Indexed page view and Live test. If live is fixed and index is not, request indexing.

  • Rendered HTML: Check that your main content and links appear in the HTML. If not, your rendering or hydration hides it from Google.
  • Screenshot: A quick way to see if consent modals, interstitials or client errors cover the page.
  • HTTP response: Confirm status 200 for indexable pages. A 3xx will show the target; a 4xx or 5xx explains non-indexing.
  • Blocked resources: Fonts, scripts, or images that failed. If blocked by robots.txt or CORS, fix access so Googlebot can render the page close to a browser.
  • Console messages: JavaScript errors that break content or links. Fix them in your app, redeploy, then retest live.

A fixed page after a live test shows your H1 and body in the rendered HTML, status 200, no blocked core resources, and a clean console. Then request indexing once.

Request indexing: what it does and what it does not do

Request indexing queues a crawl for that URL. It has a small daily quota per property. It does not guarantee indexing or ranking.

  • Use it after you fix a specific URL and confirm with Test live URL.
  • Use it to get a new page seen faster, once you have internal links and sitemap in place.
  • Do not spam it for the same URL. If quality or duplication is the cause, indexing will still not happen.
  • For site-wide issues, fix templates and use Validate fix in the Page indexing report across the affected reason.

Walkthrough 1: a new page that is not yet indexed

You published /guides/getting-started today. You see no impressions yet. URL Inspection says Not on Google, reason Discovered, currently not indexed. Discovery shows your sitemap. No last crawl yet.

  1. Check indexability signals

    Open the Canonical, Crawl and Indexing allowed panels. Ensure no noindex, no robots.txt block, status 200, and a self-referencing canonical.

  2. Ensure internal links exist

    Link to /guides/getting-started from /guides and from one relevant page. Use descriptive anchor text like “Getting started guide”.

  3. Update the sitemap if needed

    Make sure the XML sitemap lists the URL. Submit the sitemap in the Sitemaps report if this is a new sitemap.

  4. Run Test live URL

    Verify the rendered HTML shows the guide content. Check blocked resources and the console. Fix errors, redeploy, and retest if needed.

  5. Request indexing once

    Click Request indexing. That queues a crawl. Give it time. Keep the internal links in place.

A week later, re-inspect. A normal result shows On Google, crawled this week, discovered via sitemap and internal links, and the canonical matches itself. Your first impressions appear in the Performance report.

Walkthrough 2: a page that fell out of the index

Your /pricing page used to rank for “yourproduct pricing”. Traffic dropped. URL Inspection shows Not on Google, reason Crawled, currently not indexed. Last crawl was three days ago. Canonical is self, Google-selected canonical is different: /pricing?utm=abc. Discovery shows a referring page with a tracking link, and the sitemap still lists /pricing with an old lastmod.

  1. Remove duplicate parameter paths

    Add rel=canonical on all variants to point to /pricing. In your app and links, drop parameters for internal navigation. Keep canonical consistent.

  2. Fix internal links

    Find and replace internal links that point to /pricing?utm=abc. Link to /pricing only. Update navigation, footer and any banners.

  3. Refresh the sitemap

    Update lastmod for /pricing in the XML sitemap and resubmit the sitemap. This helps discovery but does not replace links.

  4. Improve the page if thin

    If the page became boilerplate or lost content, add unique copy and useful detail like plan limits and FAQs. Keep load fast for LCP under 2.5 seconds.

  5. Run Test live URL and request indexing

    Confirm 200, no blocked resources, and canonical set. Then Request indexing once.

A fixed /pricing shows On Google, last crawled recently, and Google-selected canonical equals /pricing. Rankings recover if the page still satisfies the query and your internal links are clean.

Walkthrough 3: Google ignores your chosen canonical

You run country versions without hreflang, for example /features and /features-uk that are similar. On /features-uk you set rel=canonical to /features. URL Inspection for /features shows On Google. For /features-uk, Canonical says User-declared canonical: /features-uk, Google-selected canonical: /features. Another URL shows Duplicate, Google chose different canonical than user in the Page indexing report.

  1. Decide the canonical per intent

    Pick the primary URL for each audience. If /features-uk is a real UK page, it should be self-canonical and carry UK-specific content.

  2. Differentiate content

    Add material differences: pricing in GBP, UK spelling, local examples, support hours. Avoid near-duplicates. Update title and H1 to match the variant.

  3. Add hreflang between alternates

    Mark each version with hreflang and return tags between them. Keep self-canonicals on each distinct page.

  4. Fix internal linking and sitemaps

    Link to each version from the right context. List each in the sitemap. Avoid site-wide links that collapse everything to one variant.

  5. Retest and request indexing

    Run Test live URL on each page. Confirm the canonical is self on distinct pages and that hreflang is present. Request indexing for each once.

A fixed pair shows each URL On Google with self-canonical and hreflang pointing at the other. The Page indexing report reduces Duplicate, Google chose different canonical than user entries over time.

Troubleshooting by cause: what to check first

  • 4xx and 5xx: Inspect HTTP response. Fix servers, routes, or auth. A public page must return 200 to be indexable.
  • Robots and noindex: If Blocked by robots.txt or Excluded by noindex tag, remove the block only where you want indexing. Keep admin and test pages blocked.
  • Redirects: If Page with redirect, update internal links and sitemaps to the final URL. Avoid chains. Keep one-to-one 301 mappings for retired pages.
  • Duplication: If Duplicate without user-selected canonical, add rel=canonical. If Google chose a different canonical, fix signals: content, internal links, sitemaps, parameters.
  • Quality: If Crawled, currently not indexed, improve the page and its internal links. Add unique value and references. Link to it from relevant pages.
  • Discovery: If Discovered, currently not indexed, add internal links, keep the sitemap current, and be patient, especially on new or very large sites.

What a healthy inspection looks like before you move on

Pick one high-value URL like /landing. Inspect it. You want: On Google. Discovered via your sitemap and at least one referring page. Crawled this week by Googlebot Smartphone. Crawl allowed and indexing allowed. User-declared canonical equals Google-selected canonical. Enhancements valid. Live test shows status 200, rendered HTML includes the hero copy, no blocked core resources, and no console errors.

Questions

Sources

Check my site, free

Want a second view on a tough URL, run your site through Porteur’s free check from your homepage URL and get three findings in about thirty seconds.

  • Free check, no card
  • Read-only, your own accounts
  • Readable by your agent

Read next