URL Inspection Tool and Search Console API: A Debugging Guide

The URL Inspection tool in Google Search Console shows what Google knows about a single URL: whether it is indexed, when it was last crawled, which canonical Google chose, whether crawling and indexing are allowed, and how the page rendered. A live test fetches the page again on demand and shows the rendered HTML, a screenshot, blocked resources and JavaScript console messages. For developers, it is the most direct way to answer "what does Google see?" without guessing from rank trackers or third-party crawlers. The same data is available programmatically through the URL Inspection API, which makes it possible to monitor key templates after every release.

This guide walks through the report section by section, explains common findings and their fixes, and shows how to automate checks.

Opening the URL Inspection tool

Enter a full URL in the search bar at the top of Search Console. The URL must belong to a property you have access to. Google's help article on the URL Inspection tool describes every field in the report.

The first screen shows the indexed result: information from the last time Google crawled and processed the URL. It may be days or weeks old. That distinction matters, because a fix you deployed yesterday will not appear here until Google recrawls the page.

Make sure you inspect the exact URL that matters, including the scheme, host and trailing slash. Inspecting http:// instead of https://, or a parameter version, often shows a redirect or duplicate rather than the page you meant to check.

Reading the URL Inspection tool report

Page is not indexed

The reason shown is the starting point. "Excluded by noindex tag" and "Blocked by robots.txt" point to configuration. "Crawled, currently not indexed" usually means Google did not see enough value in the page, often because it is thin or very similar to others. "Discovered, currently not indexed" means Google knows the URL but has not crawled it yet, which can reflect crawl priority on large sites.

Canonical mismatch

If the Google-selected canonical differs from the one you declared, Google has decided another URL better represents the content. Check for conflicting signals: internal links pointing to the other version, the sitemap listing it, redirects or near-identical content. Our guide to canonical URLs and duplicate content explains how to make the signals agree.

Crawled as

The report shows whether Google crawled the page with its smartphone or desktop crawler. Most sites are crawled mainly with the smartphone crawler, so content missing from the mobile version may be missing from Google's view entirely.

The live test

Select "Test live URL" to fetch the page now. The live test checks whether the page can be indexed in its current state, but it cannot predict every factor, such as whether Google will consider it a duplicate. Use it to confirm that a fix works before requesting indexing.

• Screenshot: a rendered image of the page exactly as Googlebot saw it.
• Rendered HTML: the DOM after JavaScript ran; search it for your main content, links and meta tags.
• Page resources: scripts, styles and images, with any that could not be loaded and why.
• JavaScript console messages: errors thrown while rendering.
• HTTP response: status code and headers, including any X-Robots-Tag.

When the screenshot is blank or content is missing from the rendered HTML, look at the resource list and console messages first. Blocked APIs, scripts that fail on Googlebot's user agent and timeouts are the usual causes. Our guide to JavaScript SEO covers these in depth.

Requesting indexing

After fixing or publishing an important page, "Request indexing" asks Google to crawl it. It adds the URL to a priority queue, but it does not guarantee indexing or a particular timescale, and the number of requests per property is limited.

• Use it for individual important pages: a new service page, a corrected product or a fixed template sample.
• Do not submit the same URL repeatedly; it does not speed things up.
• For many URLs, update the sitemap with accurate last-modified dates and let Google discover the changes on its own schedule.
• For removals, use noindex or a 404 rather than requesting indexing of the old version.

A debugging workflow for developers

1. Reproduce: inspect the URL and note the indexed status, canonical and last crawl date.
2. Test live: check the current status code, robots rules, rendered HTML and resources.
3. Compare: diff the rendered HTML with the HTML your server sends to a normal browser.
4. Fix: deploy the change and confirm it with another live test.
5. Request indexing for the affected URL or a sample from the template.
6. Verify later: inspect again after the next crawl and check the page indexing report for the wider pattern.

Record the inspection results in the ticket. Screenshots of the indexed and live results make it easy for colleagues and clients to see what changed. Our guide "Is my website on Google?" lists the most common indexing reasons in plain language for non-technical stakeholders.

Automating checks with the URL Inspection API

The URL Inspection API returns the indexed result for a URL in a property you can access. It does not run a live test or request indexing, but it is ideal for monitoring.

POST https://searchconsole.googleapis.com/v1/urlInspection/index:inspect
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json

{
  "inspectionUrl": "https://example.com/services/seo-services",
  "siteUrl": "sc-domain:example.com"
}

The response includes fields such as the verdict, coverage state, robots.txt state, indexing state, last crawl time, page fetch state, the Google-selected and user-declared canonicals, and detected rich results. Authenticate with OAuth or a service account that has been added as a user on the property.

Store each day's results in a small table keyed by URL and date. A simple query then shows when a template's verdict changed, which release it followed and how long Google took to recrawl after a fix.

What to monitor

• A sample of URLs per template, inspected daily or after each release to production.
• Alerts when the verdict changes from pass to fail, or when the Google-selected canonical differs from the declared one.
• Last crawl dates for key pages, to spot sections Google has stopped visiting or visits only rarely.
• Rich result detection on product and article templates after each release.

The API has daily and per-minute quotas per property, documented in Google's usage limits, so inspect representative samples rather than every URL. For broad trends, combine it with the Search Analytics API, which returns the clicks and impressions shown in the performance report.

What the tool cannot tell you

The URL Inspection tool is precise about one URL at one moment, which is also its limit. Knowing what it does not cover prevents wrong conclusions.

• Rankings: it says whether a page is indexed, not where it ranks or for which searches.
• Quality judgements: it reports "crawled, currently not indexed" without explaining exactly which weakness held the page back.
• Site-wide patterns: one inspected URL may be fine while hundreds of similar URLs are not; use the page indexing report for patterns.
• Other search engines: Bing and others have their own webmaster tools with different data.
• Guaranteed outcomes: a passing live test means the page is eligible, not that it will be indexed.

Treat inspection results as evidence for a specific question, and combine them with crawls, logs and the performance report for the full picture.

Sharing findings with clients and teams

Indexing problems often involve several people: developers, content editors, SEO specialists and the business owner. Clear evidence shortens the conversation.

1. Capture the indexed result and the live test result side by side.
2. Highlight the specific field that explains the problem, such as the canonical or robots state.
3. Describe the fix in one sentence and link to the pull request or ticket.
4. Repeat the inspection after the next crawl and add the new result to the same ticket.

This record becomes valuable during migrations and audits, when someone asks months later why a template behaves the way it does.

Common findings and fixes

Our guide to Google Search Console covers the other reports that put these single-URL findings in context.

Frequently asked questions

Need help untangling indexing problems? Our SEO services include Search Console audits, and our developers can fix what the inspections find.