The URL Inspection tool in Search Console answers two different questions, and mixing them up is the most common mistake. The first answer, shown when you inspect a URL, describes the version of the page Google last indexed. The second, the URL inspection live test, fetches the page right now and reports whether Google could access and parse it. A page can pass one and fail the other, and neither one promises that the page will appear in search.
This guide is for site owners and developers who need to know why a page is missing, whether a fix worked, or what Google sees after JavaScript runs. You will learn how to read both results, how to use the rendered HTML, screenshot and headers, and which problems the live test cannot see. If your question is mainly "how do I ask Google to index this?", read Request Google Indexing the Right Way after this guide.
Before you begin
You need a verified Search Console property that contains the URL you want to inspect. The URL has to be in the currently open property. For a URL on a site you do not own, Google points to non-owner tests such as the Rich Results test instead. The page must be reachable from the internet without a login; a live test cannot get past a password.
The tool is read-only apart from the indexing request, so the risk is low. Both inspections and live tests have a per-property daily limit, so choose important URLs rather than running through a whole site. If you have not set up Search Console, start with Set Up Google Search Console.
Indexed result versus live test
| Indexed result (default) | Live test | |
|---|---|---|
| What it reflects | The version Google last indexed | The page fetched now |
| Source of truth for Search | Yes, this is the data used in results | No, it is a preview of what could happen |
| Shows screenshot | No | Yes, when the test succeeds |
| Shows sitemap and referring page | Yes | No |
| Predicts canonical choice | Shows Google's choice | Cannot predict it |
The indexed result is not live. If you changed the page after Google's last crawl, the tool still shows the old version until Google crawls again.
Step-by-step instructions
Step 1: Inspect the URL
Paste the full URL into the inspection bar at the top of any Search Console screen, or use the Inspect link next to a URL in most reports (you may need to hover to see it). Use the exact address, including the protocol and the correct host.
What success looks like: The tool returns a verdict for the URL, and the property selector shows the property that contains it.
Step 2: Read the overall status, with its limits
The top verdict is one of "URL is on Google", "URL is on Google, but has issues", "URL is not on Google", or "URL is an alternate version". "URL is on Google" means the URL has been indexed and can appear in results. Google is clear that this does not mean it is appearing. The tool does not check every condition for showing a result. For a definitive check of whether a page is in results, search for the URL on Google.
"URL is not on Google" means the page cannot appear in Search results. The details tell you why.
What success looks like: You can say whether Google has indexed the page and what the stated reason is.
Step 3: Open the Page indexing details
Expand the Page indexing section. It groups the evidence into discovery (how Google found the URL), crawl and indexing. The fields worth reading first:
- Sitemaps and Referring page. How Google may have found the URL. An absent referring page does not mean none exists.
- Last crawl and Crawled as. When and with which crawler type (desktop or mobile) Google fetched the page. Everything shown is derived from that last crawl.
- Crawl allowed? Whether robots.txt allowed Google to crawl the page.
- Page fetch. Whether Google could get the page from your server. A fetch can succeed even if the page is not indexed for another reason.
- Indexing allowed? Whether a noindex rule stops indexing. If robots.txt blocks the page, this always reads "Yes", because Google cannot see a noindex rule on a page it cannot crawl.
- User-declared canonical and Google-selected canonical. Your preference and Google's decision. Google may choose a different URL. To learn which canonical Google chose, use the indexed data; the live test cannot predict it. See Fix Duplicate URLs and Incorrect Canonical Tags.
What success looks like: You know which stage failed: discovery, crawl, fetch, or indexing permission.
Step 4: Run the URL inspection live test
Click Test live URL. The tool fetches the page in real time and the result opens in a separate view; toggle between Google Index and Live Test to compare. The page does not have to be indexed already. The top verdict is "URL is available to Google", "URL is available to Google, but has issues", or "URL is not available to Google".
A positive live result means only that Google-InspectionTool can access the page for indexing. Google states plainly that there is no definitive test that tells you a page will be included. The page also has to be unique or the chosen canonical, of high enough quality, and free of manual actions or legal issues.
The live test follows redirects first and then tests the final page, but it does not tell you it followed a redirect or which URL it ended on. The indexed report does show redirects. To investigate redirects separately, see Redirect Chains, Loops, and Incorrect HTTP Status Codes.
What success looks like: You have both an indexed result and a live result for the same URL.
Step 5: Check the rendered page and fetched code
When the live test succeeds, click View tested page. You get a screenshot of the rendered page as Google-InspectionTool sees it, the raw HTML, HTTP headers, JavaScript console output and the loaded resources. The screenshot is available only in a live test with a successful result, not for the indexed URL.
Use it to answer practical questions:
- Is the main content in the rendered output, or only visible after a user action?
- Are CSS, JavaScript or images blocked for Google, leaving the layout broken?
- Does the HTTP response include an unexpected noindex header?
- Are there JavaScript errors that stop content from appearing? See Find and Fix JavaScript Console Errors on Page Load.
Differences between the screenshot and your browser can be caused by resources blocked to Google-InspectionTool. If the content you care about is missing from the rendered HTML, read JavaScript SEO Rendering Basics.
What success looks like: The content that matters is present in the tested HTML and the screenshot.
Step 6: Know what the live test cannot catch
Google lists issues from the page indexing report that a live test cannot test, including Crawled - currently not indexed, Discovered - currently not indexed, Alternate page with proper canonical tag, the duplicate reasons, and Page indexed without content. Canonical selection is decided at indexing time. The live test also does not check quality and security guidelines, manual actions, content removals or temporarily blocked URLs.
So a page can show "URL is available to Google" and still not be indexed. If the live test is clean but the page is missing, check the Manual actions and Security issues reports, and check whether the page was temporarily blocked.
What success looks like: You do not treat a clean live test as proof of indexing.
Step 7: Request indexing only when it makes sense
After a real fix, you can click Request indexing. A page that passes a quick check enters the indexing queue, but you cannot request indexing if the live test shows the page as non-indexable. Google says indexing can take anywhere from about a day to a week or two, a request does not make indexing certain, and there is a daily limit. For many new or updated pages, a sitemap with accurate lastmod dates is the better route.
What success looks like: The request is submitted for an important fixed page, and you do not repeat it daily.
Final verification checklist
- The inspected URL is in the right property and uses the exact address.
- You recorded the indexed result and the live result separately.
- Crawl allowed, Page fetch and Indexing allowed all have the values you expect.
- The rendered HTML contains your main content.
- You checked headers for an unexpected noindex.
- Manual actions and Security issues reports were checked if the page is still missing.
Common mistakes to avoid
- Reading the indexed result as the current page. It is a snapshot from the last crawl. Run the live test to see now.
- Treating "available to Google" as "will be indexed". The live test skips canonical selection, quality and policy checks.
- Expecting the live test to show a redirect. It silently follows redirects. Check the indexed report or fetch headers yourself.
- Blocking the page in robots.txt and adding noindex. Google cannot see the noindex rule on a blocked page.
- Testing a page behind a login. The tool cannot reach it.
- Requesting indexing over and over. There is a daily limit and repeating does not speed anything up.
- Using the tool on every URL. Per-property daily limits apply; sample a representative page per template.
Frequently asked questions
Does "URL is on Google" mean the page shows in search?
No. It means the page is indexed and eligible. To confirm it is showing, search for the URL on Google.
Why does the live test differ from the indexed result?
You may have changed the page since the last crawl, such as adding or removing a noindex tag or a robots.txt block. The live test also supports fewer states than the indexed version.
Can I use the live test on a page that is not indexed yet?
Yes. It is fine if the page has not been indexed, as long as it is reachable without a login.
Where do I see the screenshot?
Run Test live URL, then View tested page, then the Screenshot tab. It is only available after a successful live test.
Can I inspect a competitor's page?
No. The URL has to be in a property you have access to. Non-owner checks, like the Rich Results test, exist for public pages.
Related guides
- Request Google Indexing the Right Way
- Page Indexing Report Explained: Every Status and What to Do
- Robots.txt Blocking Google or Bing? Diagnose It Step by Step
- Fix Duplicate URLs and Incorrect Canonical Tags
- JavaScript SEO: Server Rendering, Client Rendering and Crawlers
Official references
- https://support.google.com/webmasters/answer/9012289
- https://support.google.com/webmasters/answer/7440203
- https://support.google.com/webmasters/answer/9044175
- https://support.google.com/webmasters/answer/9044101
Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.
Crawvix Editorial Team
· Published October 29, 2026 · Last updated October 29, 2026 · 8 min read