The URL Inspection tool is a feature of Google Search Console that reports what Google knows about a single URL: whether it is indexed, how it was discovered and crawled, which canonical Google selected, and which enhancements were detected. In indexing work, it is the primary diagnostic for answering why one specific page does or does not appear in Google Search.
The tool has two views. The indexed view shows data from the last time Google processed the URL, while the live test fetches the page right now with Googlebot and shows whether it could be indexed in its current state. Site owners can also use it to request indexing after fixing a problem or publishing important content.
What the URL Inspection tool reports
The URL Inspection tool reports the index status of a URL in one of a few verdicts, then breaks the result into discovery, crawling and indexing details. It works only for URLs inside a verified Search Console property, so it cannot be used to inspect competitors or third-party sites.
| Data point | What it shows | Why it matters |
|---|---|---|
| Index verdict | Whether the URL is on Google | First answer to an indexing question |
| Discovery sources | Sitemaps and referring pages | Shows how Google found the URL |
| Last crawl | Date, crawler type and fetch result | Reveals stale or failed crawls |
| Crawl and index allowed | Robots.txt and noindex status | Exposes blocking directives |
| User-declared canonical | Canonical specified by the site | Shows the intended preferred URL |
| Google-selected canonical | Canonical Google actually chose | Reveals duplicate consolidation |
| Enhancements | Detected structured data and other features | Confirms eligibility for rich results |
The canonical comparison is often the most revealing line. When the Google-selected canonical differs from the user-declared one, Google treats the inspected URL as a duplicate and indexes the other address instead, which explains many cases where a page seems to be missing.
Indexed view versus live test
The indexed view and the live test answer different questions, and confusing them is a common source of wrong conclusions. The indexed view describes the past, while the live test checks the present state of the page without changing the index.
| Aspect | Indexed view | Live test |
|---|---|---|
| Data source | Last processed version in the index | Fresh fetch by Googlebot |
| Answers the question | Is this URL indexed now | Could this URL be indexed now |
| Rendered output | Not shown | Screenshot, rendered HTML, resources |
| Canonical selection | Shown | Not evaluated |
| Use case | Diagnose existing status | Verify a fix before requesting indexing |
A passing live test means only that nothing technical blocks indexing. It does not guarantee that Google will index the page, because quality assessment, duplicate detection and canonical selection happen later in the pipeline and are not part of the test.
Using the live test for rendering checks
The live test is the closest public view of how Googlebot renders a page. It shows the HTTP response headers, a screenshot of the rendered viewport, the rendered HTML after JavaScript execution, JavaScript console messages and a list of page resources that could not be loaded.
This makes the tool central to JavaScript SEO diagnostics. If important text or links appear in the browser but are missing from the rendered HTML in the live test, Google probably cannot see them either. Blocked scripts, failed API calls and timeouts are typical causes.
- Compare rendered HTML with the source to confirm that content generated by scripts is present.
- Check the resource list for files blocked by robots.txt or failing with server errors.
- Read the HTTP headers for an unexpected
X-Robots-Tagor a wrong status code. - Review console messages for script errors that stop the page from finishing rendering.
Requesting indexing and its limits
After a successful live test, the tool offers a Request indexing button that adds the URL to a priority crawl queue. This is useful for new important pages, updated content and fixed errors, but it is subject to a limited daily quota per property and does not bypass quality evaluation.
| Situation | Better option | Reason |
|---|---|---|
| One important new page | Request indexing in the tool | Fast recrawl for a single URL |
| Hundreds of changed URLs | Updated sitemap with accurate lastmod | Scales without manual quota |
| Monitoring many URLs | URL Inspection API | Programmatic access to the same data |
| Site-wide indexing trends | Page indexing report | Aggregated reasons across the site |
Repeated requests for the same URL do not speed up indexing. If a page stays in a state such as crawled but not indexed, the cause is usually quality or duplication, and the solution lies in the content and internal linking rather than in more requests.
Common misreadings of inspection results
Inspection results are precise but easy to misinterpret, especially when data lags behind changes. The indexed view may show a version that is days or weeks old, while the page itself has already been fixed.
| Observation | Wrong conclusion | Correct interpretation |
|---|---|---|
| Live test passes | The page will be indexed | Only technical eligibility is confirmed |
| URL is not on Google | The page is penalized | Often not yet crawled or a duplicate |
| Different canonical selected | The tool is wrong | Google consolidated duplicate signals |
| Old crawl date | Google ignores the site | Low priority or weak internal links |
Stripped to the essentials
The URL Inspection tool lets a website owner ask Google one simple question about one page: do you know this page, and can you show it in search? Google answers with what it saw on its last visit. It can also visit the page again right away to check it.
It is like asking a librarian whether a particular book is on the shelf. The librarian checks the catalog and looks at the book itself. If the book is not there, you learn why it is missing.
Where it is applied
An online magazine notices that a new long-form article about electric heating receives no search traffic two weeks after publication. The page indexing report shows nothing unusual, so the editor inspects the exact URL.
The indexed view reports that the URL is not on Google and that Google selected a different canonical: a printer-friendly version of the same article that the content system also publishes. The team sets the correct canonical on the print version, adds the article to the internal links of a related category page, runs a live test and requests indexing. Within days, the main URL appears in the index with the expected canonical.