Google Search Console URL Inspection Tool: Results and Fixes

Quick Answer

The Google Search Console URL Inspection tool shows what Google knows about a webpage and lets you test its current indexability. Start with the indexed report, then run a live test if you need to check recent changes or errors. Use both results to find the next step. Inspection does not guarantee indexing.

Key Takeaways

Google's inspection results answer different questions. These findings help you read them without mixing up crawling, indexing, and search visibility.

• The indexed report shows Google's stored page data, which may lag behind recent site changes.
• A successful live test shows current technical eligibility, not proof that Google has indexed the page.
• An indexed URL can still be absent from search results for a given query.
• Google may select a different canonical URL from the one your website declares.
• Fix crawl blocks, noindex rules, and fetch errors before asking Google to crawl again.
• Google says crawling can take days to weeks, and repeated requests do not make it faster.
• The URL Inspection API returns indexed data but cannot run live tests or submit ordinary indexing requests.

The right action depends on what changed. A failed live test calls for a technical check. A passing test with no indexed page calls for a broader review.

How to Inspect a URL in Google Search Console

To inspect a URL, open the right Search Console property. Enter the full page address in the inspection field at the top. Google then shows the indexed report. Start there before running a live test.

The tool works with URLs in properties you can access. You cannot use your own property to inspect any unrelated site. The official Google URL Inspection documentation explains these limits and the data shown.

A useful inspection follows a clear order. It starts with the page Google knows. It ends with an action based on the evidence. Skipping the middle steps can lead to needless crawl requests.

Use this seven-step process for an important page:

1. Select the correct property. Check that the URL belongs to the selected Search Console property.
2. Enter the full URL. Include the intended protocol, host, path, and trailing slash where relevant.
3. Read the indexed result. Check the main status and expand the Page indexing details.
4. Review crawl and canonical data. Record the last crawl and Google's chosen canonical when those fields appear.
5. Run Test Live URL if needed. Use it to check current access after a change or reported error.
6. Compare the reports. Look for an old problem, a new failure, or a mismatch in canonical signals.
7. Choose the next action. Fix a blocker, review the page, request a recrawl, or allow more time.

This order helps keep the problem clear. If an indexed report is old, a live test may show that the issue has already been fixed. If both reports show a block, fix that block first.

Start with the Indexed Report

The indexed report is Google's record of the URL. It may show the page's indexing status, crawl history, discovery data, and canonical information. Some fields appear only when Google has enough data to report them.

Look beyond the large status message. The last crawl date can tell you whether Google has seen a recent fix. The canonical fields can show whether Google prefers another address. A page may work well in a browser while Google keeps a different URL in its index.

For instance, a store may move a product from an old URL to a new one. The new page loads well. Yet Google may still report the old URL as its canonical choice. That result calls for a check of redirects and canonical signals, not a blind resubmission.

A missing field is not always a failure. It may simply mean Google has no stored value to display.

Keep crawl permission, fetch and indexing permission separate

Read these fields as different checks. Crawl allowed? concerns crawler access under robots.txt. Page fetch concerns retrieval of the response. Indexing allowed? concerns directives such as noindex. A successful fetch does not cancel a noindex directive, and blocking crawling can prevent Google from seeing a directive within the page.

Missing discovery fields are clues with limits. An empty referring-page or sitemap field is not a complete history of how Google discovered the URL. Compare the last crawl with the date of your repair before treating stored data as a fresh failure.

If the response succeeds but the useful text is absent, inspect the rendered output and resource loading. For example, a hypothetical help page may load its instructions only after a user action. A successful fetch alone would not establish that Google received those instructions. Correct the rendering problem, test again, and keep that technical result separate from any later indexing decision.

Run Test Live URL When Current Conditions Matter

Use Test Live URL when the page has changed since Google's last crawl. It is also useful after a server fix, a noindex change, or a rendering repair.

The live test checks current technical conditions. Where available, it can help you review returned HTML, loaded resources, and rendered content. Google's single-URL troubleshooting instructions explain how to use these inspection details.

A live test is useful for pages built with JavaScript. The browser may display content that Google's rendered view cannot access. Review the output before assuming the page is ready for search.

For detailed steps, see the Google URL Inspection Live Test guide. The larger decision still starts with the difference between live eligibility and indexed status.

Indexed Result vs. Live Test: Which One Should You Trust?

Use each report for a different check. The indexed result reflects Google's stored information. The live test checks current page conditions. Neither is a full replacement for the other.

Think of an indexed report as a record of what Google last learned. Think of the live test as a fresh technical check. The two may disagree without either being wrong.

The API adds a third way to inspect URLs. It can return indexed-version data for authorized properties, but it does not perform the interactive live test. The main differences are shown below.

This comparison matters most after a site change. A fresh live test can confirm that a technical fix is visible now. Only later indexing information can show whether Google's stored result has changed. The Search Console interface also offers a separate Request Indexing action. Simply inspecting or testing a URL does not submit that request.

The URL Inspection API method reference confirms its indexed-data scope. It does not offer a hidden way to force Google to index a page.

Why the Two Results Can Disagree

Picture a publisher who removes a noindex tag from an article. The live test now says the page is available to Google. Yet the indexed report still shows the old exclusion.

That is a possible timing difference. Google's stored result may come from a crawl before the fix. The publisher should confirm that the live page is correct, then allow Google to revisit it. A recrawl request may be useful.

The reverse can happen too. Google may have indexed a page while it worked. Later, the server starts returning an error. The stored report may look healthy while the live test fails.

That second case needs a server fix. The old indexed result does not prove the page still works.

Both situations are examples, not observations from a real Search Console account. The decision comes from the report dates, present page state, and specific errors.

Read the URL Inspection Status Before Changing Anything

The status message tells you where to look next. It rarely gives the whole diagnosis. Check whether the message comes from the indexed report or the live test, then review its details.

Three common messages deserve careful reading. Each describes a different state. Treating them as the same can lead to the wrong fix.

URL Is on Google

This result means Google has indexed the URL and it is eligible to appear in Search. It does not promise a result for every keyword.

A page may be indexed yet rank poorly. It may also be absent from a search you try. Search results depend on the query and other factors outside URL Inspection.

If the page is indexed, review whether Google chose the URL you intended. Also check whether the report reflects the latest content. An indexed page with an old crawl date may still need time to reflect a recent edit.

Do not request indexing each time you fail to find the page through a manual search. First confirm what problem, if any, the inspection report shows.

URL Is Not on Google

This result means the inspected URL is not indexed as reported. It does not tell you that the page is poor or broken by itself.

Open the Page indexing details. Google may report a crawl problem, a noindex rule, a redirect, or another canonical choice. It may also show that the URL has not been crawled or was crawled without being indexed.

Those findings call for different actions. A page blocked by a noindex rule needs a change only if you want it indexed. A duplicate may be handled through Google's canonical choice. A new page may need better discovery and time.

URL Is Available to Google

This message comes from a live test. It means the tested page meets the technical conditions checked at that time. It is not proof of current or future index inclusion.

A page can pass this test and still remain outside Google's index. The test does not settle every issue related to content usefulness, duplication, or Google's final canonical choice.

Use the live result to confirm access. Then return to the indexed data for Google's recorded state. If there is no clear technical failure, move to the broader troubleshooting checks below.

URL Inspection Troubleshooting: Match the Result to the Next Action

Fix the issue shown by the evidence, not the status label alone. A technical block needs a technical fix. A canonical mismatch needs a signal review. A passing live test with no indexed page may need a wider SEO check.

The next action depends on the finding and when Google observed it. Record the first check, then recheck when new evidence can answer the question. These are investigation paths, not certain explanations for every excluded page.

Google's URL Inspection documentation explains the distinction between indexed data and live testing. A passing live test does not guarantee indexing, and a request does not impose an indexing deadline.

Fix Crawl and Indexing Blockers First

Start with access. Does the page return the right content to Google? Are the server and needed resources available? Is a rule stopping the crawler?

Robots.txt and noindex are not the same. A robots.txt rule can stop crawling. A noindex directive tells Google not to index a page when Google can read that instruction.

Blocking a page in robots.txt may keep Google from seeing its noindex tag. For that reason, a robots block is not a sound way to remove an already known URL from search results.

Server problems need a separate check. A page that often fails to load may be hard to crawl. A JavaScript page may also return HTML with little of the content readers see. Compare Google's rendered view with the intended page.

For a broader list of causes, use the site's guide on why Google isn't indexing your pages. The aim here is to turn the inspection result into the next useful check.

Compare Declared and Google-Selected Canonicals

A canonical URL is the version Google treats as the main page among duplicate or similar addresses. Your site can suggest one. Google can choose another.

For example, an article may be available with and without a trailing slash. Your site may point to one address, while internal links favor the other. Mixed signals can make Google's choice less clear.

Google's canonicalization guidance treats redirects and rel=canonical tags as strong signals. Sitemap inclusion is a weaker signal. None of them guarantees that Google will follow your preference.

Compare the declared canonical with the Google-selected value. Then review redirects, internal links, and sitemap entries. The goal is a clear, consistent preferred URL.

Do not remove a useful redirect or change a canonical tag just because the inspected address differs. First decide which version should remain in search.

Live Test Passes but the Page Remains Unindexed

A clean live test rules out some current technical problems. It does not solve Google's wider indexing decision.

Check whether the page offers content that differs enough from other URLs. Review the internal links that lead to it. Look for conflicting canonical signals and an intended page missing from normal site navigation.

A new product page is a useful case. It may pass a live test but have few internal links. It may also repeat most of the text found on another product page. Those are different issues, and neither is fixed by pressing Request Indexing again.

Google's choice can also reflect factors not fully shown in the tool. Keep the technical result separate from assumptions about content quality. If the page is accessible and the signals are clear, more crawl requests may add no value.

Request Indexing or Submit a Sitemap?

Use Request Indexing for a small set of important URLs. Use an XML sitemap to help Google discover a larger group. Neither method makes Google include every submitted URL.

Google's recrawl request instructions draw this distinction. They also state that crawling may take a few days to a few weeks. That is not a deadline for index inclusion.

A small business may publish a new service page and want Google to visit it. An online store may add hundreds of product pages. The first task suits an individual request. The second calls for a sound sitemap and internal links.

When Request Indexing Makes Sense

Request a recrawl when an important URL is new, has changed, or has had a clear problem fixed. First confirm that Google can reach the intended page.

In Search Console, inspect the URL and use Request Indexing where the option is available. The account must have the needed permissions. Google also applies request limits.

A request is a signal to crawl or recrawl. It is not an order to index. Repeating a request for the same page does not make Google crawl faster.

Suppose an article was blocked by mistake. After removing the block, run a live test. If the page now works, a recrawl request can help bring the fix to Google's attention. The indexed result may still take time to change.

When a Sitemap Is the Better Choice

A sitemap is useful for larger URL sets and ongoing site discovery. It gives Google a list of pages your site wants it to find.

Make sure the sitemap reflects your intended URLs. Avoid treating every URL in a large export as a page worth indexing. The list should support a sound site structure, not replace one.

Google still decides what to crawl and index. Sitemap submission does not bypass technical blocks or settle canonical choices.

For more detail on both methods, see how to submit a URL to Google. The inspection tool should help you decide whether the real issue is submission, access, or indexing.

URL Inspection API vs. Google's Indexing API

The URL Inspection API reads indexed-version information for authorized Search Console properties. Google's separate Indexing API sends notifications for certain supported page types. The names sound alike, but the tools serve different jobs.

This matters for teams that manage many URLs. The wrong API can produce reports that do not answer the intended question. It can also lead to unsupported indexing workflows.

What You Can Automate with URL Inspection

The URL Inspection API can return indexed status and related information through a program. It is useful when a site owner needs to review many controlled URLs.

The request uses an inspectionUrl for the page and a siteUrl for the Search Console property. Access must be authorized. The response depends on the indexed information Google has for that URL.

The API does not run Test Live URL. It also does not provide a general Request Indexing action. A program that calls this API cannot assume it has checked current rendering or made Google crawl the page again.

Use it for indexed-state reporting and triage. For a specific live failure, return to the Search Console interface and test that page directly.

Why the Indexing API Is Different

Google's Indexing API documentation limits supported use to qualifying pages with JobPosting or BroadcastEvent within VideoObject.

It is not a general indexing method for ordinary blog posts, store pages, or backlinks. Sending a supported notification also differs from getting a page indexed and ranked.

An agency building a reporting tool should use the URL Inspection API for authorized indexed data. A site with qualifying job pages may have a separate use for the Indexing API. Neither path offers a universal way to force Google to index a URL.

Inspecting Many URLs Without Losing the Diagnosis

Use bulk tools to find patterns, then inspect important URLs in depth. A long list of unindexed pages is a useful starting point. It is not a root-cause report.

Start by grouping pages with the same template or role. Product pages, category pages, articles, and old redirects may need different checks. A shared issue across one group can be more useful than many separate crawl requests.

A sitemap helps with discovery. The URL Inspection API helps gather indexed data for authorized properties. External status tools may help sort large lists. These tools answer different questions, so keep their results separate.

IndexNowFast offers a Google Index Checker that the publisher says can check up to 10,000 URLs and export results as CSV. This describes the service's stated capability. It is not an independent test of accuracy or Google indexing success.

The service may help identify URLs worth a closer look. Search Console remains the first-party source for indexed details and live diagnosis on a property you manage.

A Practical Bulk-Triage Example

Imagine a publisher with a large group of articles. Some are new. Others have been updated. A few may point to another canonical URL. The publisher wants to know where to start.

A useful first pass separates the URLs by type and reported state. The team then selects important examples from each group and checks them in Search Console.

If one page has a live server failure, the team can test other pages using the same template. If several pages show unexpected canonical choices, it can review the site's common link and canonical rules.

The example does not assume a real customer, a measured success rate, or a known number of affected pages. It shows why grouping results is useful. One sound fix may address a shared cause across many URLs.

For each important case, keep a short record of the URL, inspection date, last crawl, canonical choice, live-test result, and action taken. Compare later findings against that record. This avoids repeating work when Google's indexed data has not yet caught up with a repair.

Common URL Inspection Questions

Use the indexed report to judge Google's recorded state, then check the live page when facts seem out of date. The questions below help you decide what to do next. They cover who can inspect a page, when a crawl may occur, and why search results can differ from inspection data. They also explain when a canonical review or another crawl request makes sense.

How long after Request Indexing will Google crawl the page?

Google says crawling can take from a few days to a few weeks. The actual timing varies. A crawl request does not promise indexing by a set date, and repeated requests do not speed the process.

Can I inspect a website I do not own?

You need access to the relevant Search Console property. You cannot use an unrelated property to inspect any URL on the web. Public search tools and Search Console property inspection are different services.

Does a missing site: result mean my page is not indexed?

No firm conclusion follows from that result alone. Google's search operator guidance explains that operators have limits. Use URL Inspection for a more direct check of an owned property's indexed data.

Why does Test Live URL pass while the indexed report shows an error?

The indexed report may reflect an older crawl. The live test checks the page under current conditions. Confirm the repair and compare the last crawl date. Request a recrawl when appropriate.

What if Google selects a different canonical URL?

Review the URL Google chose and decide which version your site should favor. Check redirects, canonical tags, internal links, and sitemap entries. Google can still make its own canonical choice.

Can the URL Inspection API request indexing?

No. It retrieves indexed-version information for authorized properties. It does not run the live test or provide a general indexing request. The separate Indexing API has restricted supported uses.

Should I request indexing after every page update?

Not for every small edit. Use the option when an important page is new, materially changed, or fixed after a crawl issue. Keep your sitemap and internal links in good order for regular discovery.

Can a page be indexed but never appear for my keyword?

Yes. Indexing means the page is in Google's index and may appear in Search. It does not guarantee visibility for a chosen query. Ranking and the query itself affect what people see.

Choose the Next Step from the Evidence

The URL Inspection tool is most useful when it changes what you do next. Start with Google's indexed report. Use the live test to check current conditions. Fix clear blockers before requesting another crawl.

If the page passes technical checks but stays unindexed, look beyond submission. Review canonical signals, duplicate content, internal discovery, and page value. For large URL sets, group the findings before you inspect each page in depth.

Keep one distinction clear: discovery, crawling, indexing, and ranking are different steps. A tool can help with one step without guaranteeing the next.

SEO Title: Google Search Console URL Inspection Tool: How to Use It

Meta Description: Learn to use Google's URL Inspection tool, compare indexed and live results, troubleshoot indexing errors, and choose the right next action.