# 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. Updated 2026-09-14 · Source: https://porteur.ai/guides/url-inspection-tool ## 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. > Use Validate fix in the Page indexing report after you repair a cause across many pages. Use Request indexing in URL Inspection for a one-off URL. ## 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. > Do not rely on the screenshot alone. Always check the rendered HTML and the console messages. ## 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. > If the reason is Crawled, currently not indexed and your content is thin or near-duplicate, no amount of requests will force indexing. Improve the page first. ## 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 ### What is the URL Inspection tool used for? It answers what Google did with one specific URL: whether it is indexed, how it was discovered, when it was last crawled, what canonical it selected, and whether crawling and indexing are allowed. Use it to debug a single page after the Page indexing report shows the pattern. ### How do I inspect a URL in Search Console? Open Search Console, select your property, paste the full URL into the Inspect any URL bar. Review Indexing status, Discovery, Crawl, and Canonical. If the status looks stale, run Test live URL and check View tested page for rendered HTML, HTTP response, blocked resources and console errors. ### Should I use Request indexing for every change? No. Use it after you fix a specific URL and confirm with a live test. It queues a crawl but does not guarantee indexing. For template or site-wide fixes, repair them, then use Validate fix in the Page indexing report to trigger a broader recheck. ### Why does Google ignore my rel=canonical? Because other signals point to a different URL: near-duplicate content, internal links to variants, parameters, sitemap entries favouring another page, or mixed canonicals across duplicates. Make the preferred page clearly unique, align links and sitemaps, and keep a consistent canonical across duplicates. ### What does “Crawled, currently not indexed” mean for my page? Google fetched the page and decided not to index it for now. It often signals thin or near-duplicate content, weak internal links, or low overall site quality. Improve the page and its context, then recheck. Request indexing alone will not fix it. ### How can I see what Google actually rendered? Use Test live URL, then View tested page. Read the rendered HTML, not just the screenshot. Check for your main content and links, HTTP 200, unblocked resources, and a clean console. ## Read next - [How to use Google Search Console in ten minutes a week](https://porteur.ai/guides/how-to-use-google-search-console): A quick weekly routine: set four filters, compare 28 days, check pages then queries, and fix three findings, without getting lost in noise. - [Canonical tags: what they do and the mistakes that cost rankings](https://porteur.ai/guides/canonical-tag): What a canonical tag does, when to use one, the mistakes that cost rankings, and how to check and fix canonicals on a small site. - [Alternate page with proper canonical tag: what Search Console means](https://porteur.ai/guides/alternate-page-with-proper-canonical-tag): What this Search Console status means, when to ignore it, when it hides the wrong page, and the exact checks and fixes to set the right canonical. - [Crawled, currently not indexed: what it means and what to do](https://porteur.ai/guides/crawled-currently-not-indexed): What “Crawled, currently not indexed” means in Search Console, how to tell why it happened on your site, and what to change that gets pages indexed. - [Discovered, currently not indexed: why Google has not crawled the page](https://porteur.ai/guides/discovered-currently-not-indexed): Google knows the URL but has not crawled it. Here is how to check why, cut junk URLs, add internal links, fix the sitemap, and set a date. - [How to fix 404 errors reported in Search Console](https://porteur.ai/guides/how-to-fix-404-errors-in-google-search-console): Decide which 404s to fix, find the ones with links or traffic, choose redirect, restore or 410, clean internal links and sitemaps, and revalidate. 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: https://porteur.ai/