The Google Search Console URL Inspection tool is built for a narrow job: diagnosing one URL. It shows Google’s indexed information for that page and lets you run a live test against the current version. The distinction matters because a page can look correct in your browser while Google is still working from an older crawl, and a successful live test still does not guarantee indexing.
Use this tool after the broader problem has been identified. The Page Indexing report is better for seeing patterns across a property, while crawling and indexing fundamentals explain the wider process. URL Inspection is where you move when one important page needs evidence rather than another round of guesswork.
Start With the Question, Not the Green Tick
Choose the correct Search Console property and paste the fully qualified URL you want to inspect into the inspection bar. Google requires the URL to belong to the property currently open in Search Console. Then decide what you are trying to learn. URL Inspection can answer three different questions, and mixing them together is a common source of bad conclusions.
- What did Google last record about this URL? Read the indexed information first. This is where you can see the last crawl, page fetch information, indexing status and Google-selected canonical when those fields are available.
- Can Google access the current version now? Run Test live URL. This is useful after a technical change or when you need to confirm the current response, directives or rendered output.
- Has Google processed the change into its index? A live test cannot answer that. You need to wait for Google to recrawl and process the URL, then review the indexed information again.
This is why a positive status should be read carefully. Google’s documentation states that URL is on Google means the URL is eligible to appear in Search, not that it must be shown for a query. Likewise, a live result saying the URL can be indexed confirms only the conditions checked by the live test. It is not an indexing promise.
Indexed Data and the Live Test Answer Different Questions
Google’s URL Inspection documentation separates indexed information from the live test for a reason. The first describes what Google recorded during indexing. The second fetches the current page with Google-InspectionTool and checks what can be evaluated in real time.
| Check | Indexed information | Live test |
|---|---|---|
| Purpose | Shows Google’s stored information for the inspected URL. | Tests the current page as it is fetched now. |
| Last crawl and discovery clues | Can show last crawl, referring sitemap and a possible referring page when available. | Does not report referring pages or sitemap membership. |
| Google-selected canonical | Can show Google’s selected canonical after indexing. | Cannot predict which canonical Google will select. |
| Current technical fix | May still reflect the previous crawl. | Useful for checking whether a recent change is present and fetchable now. |
| Indexing outcome | Shows the processed indexing state Google has recorded. | Does not guarantee that the tested URL will be indexed. |
A Live Test Cannot Recreate Every Indexing Condition
This limit is easy to miss. Google specifically lists canonical-selection outcomes, Crawled – currently not indexed, Discovered – currently not indexed and several duplicate states among the conditions that the live test cannot reproduce. Canonical selection happens during indexing, so a live test should not be used as proof that Google has accepted a new canonical choice.
The useful comparison is simpler: indexed data tells you what Google recorded before, while the live test tells you what Google-InspectionTool can see now. If those two views differ after a fix, the change may be live even though Google’s indexed record has not caught up yet.
There is another small but useful limit when redirects are involved. Google’s live test follows redirects before testing the destination, but it does not tell you that a redirect was followed or show the final URL it tested. If the redirect itself is part of the diagnosis, check the response independently rather than relying on the live test alone.
Read the URL Inspection Report in a Useful Order
A longer checklist is not automatically a better diagnosis. Read the fields in an order that rules out obvious explanations before you move into content or site-wide theories.
- Check the overall indexing status. First ask whether the reported state is actually wrong for this page. An intentional alternate, redirected URL or noindex page does not need to be forced into the index.
- Look at discovery clues. The indexed report may list referring sitemaps and a referring page that Google possibly used to discover the URL. Treat these as clues rather than a complete history. Google notes that a missing referring page does not mean no referring page exists.
- Check the last crawl and page fetch. The last crawl tells you when the indexed information was acquired. Page fetch shows whether Google could retrieve the page during indexing. If the crawl predates your fix, an old result is not surprising.
- Separate crawl access from indexing permission. Crawl allowed? reflects robots.txt access. Indexing allowed? reflects page-level index controls such as noindex when Google can read them. If robots.txt prevents crawling, Google may be unable to see a noindex directive on the blocked page.
- Compare canonical signals last. Review the user-declared canonical and Google’s selected canonical in the indexed information. If they differ, investigate the relationship between the URLs rather than assuming the canonical tag failed.
For canonical problems, canonical tags and their supporting signals need to be considered together. Google may take redirects, canonical annotations and sitemap signals into account, and it recommends linking internally to the URL you consider canonical. A tag on its own does not force the choice.
Use Rendered Output When Rendering Is Actually the Question
If a page looks correct to a user but you suspect Google is receiving something different, run a live test and open View tested page. Google says this view can expose the rendered screenshot, returned HTML, HTTP headers, JavaScript console output and loaded resources. That makes it useful for checking missing main content, blocked resources, unexpected responses or JavaScript behaviour.
Do not make rendering the default explanation for every indexing problem. A complete live render does not settle duplicate selection, page purpose or whether Google will index the URL.
Let the Result Change the Next Check
The same button should not follow every status. URL Inspection is useful because it narrows what you know about one page, not because it produces a universal fix.
| What you find | What URL Inspection establishes | What to do next |
|---|---|---|
| URL is on Google | Google has indexed the URL and considers it eligible to appear in Search. | If the concern is weak visibility rather than indexing, move beyond URL Inspection and investigate the query, page purpose, search intent and competing results. |
| Accidental noindex | The indexed information shows that indexing was disallowed when Google last processed the page. | Remove the directive if the page should be indexable, then use a live test to confirm the current page no longer exposes it. |
| Unexpected Google-selected canonical | Google chose another URL as the representative version during indexing. | Compare the duplicate set, declared canonical, redirects, internal links and sitemap treatment. Do not use the live test as proof of a new Google-selected canonical. |
| Crawled or Discovered – currently not indexed | The indexed report confirms the reported processing state. | Use that state to choose the deeper diagnostic path. The live test cannot reproduce either status, so a successful live test does not cancel the report. |
| Current page fetch fails | The live test cannot successfully retrieve or process the current URL under the conditions it checks. | Fix the response, access rule or resource problem first. There is little value in requesting indexing while the live test still exposes the technical failure. |
This distinction also protects the role of the wider indexing cluster. Property-level status patterns belong in the Page Indexing report. A specific exclusion such as Crawled – currently not indexed deserves its own diagnostic workflow. This page should stay focused on collecting and interpreting evidence for one URL.
Request Indexing Only After the Page Has Earned Another Crawl
Request indexing is useful after a meaningful change to a small number of URLs. It is not a shortcut around the reason a page was excluded. Google says the feature has submission quotas, requires an owner or full user of the Search Console property, and repeated requests for the same URL do not make Google crawl it faster.
Google’s recrawl guidance also makes the scale distinction clear: URL Inspection is for a few URLs, while a sitemap is the better route when many pages are new or substantially updated. Even then, crawling can take days or weeks and inclusion in Search is not guaranteed.
A sensible sequence is:
- Read the indexed information before changing the page.
- Decide whether the current state is expected for that URL.
- If you made a relevant technical change, run a live test to confirm the current page.
- Request indexing only when an important individual URL has materially changed and is eligible for another crawl.
- Recheck the indexed information after Google has had time to recrawl and process the page.
Know When the Problem Is Larger Than One URL
If the same unexpected state appears across a template, directory, language section or publishing batch, stop treating the URLs as isolated cases. At that point, compare representative pages and investigate the shared system: template output, internal linking, URL generation, sitemap logic, server behaviour or deployment changes.
The broader Google Search Console guide is useful when the investigation needs to move beyond one inspected page. URL Inspection is deliberately narrow. That is a strength when one URL needs evidence, and a limitation when the real problem sits in the site architecture.
