The short answer
The URL Inspection Tool in Google Search Console shows how Google handled one specific page: whether it is indexed, when it was last crawled, which canonical URL Google chose, and whether the live page can be indexed right now. Paste the URL into the inspection bar at the top of Search Console, read the status, run a live test after any fix, and request indexing for new or updated pages.
Google Search Console can tell you whether Google knows about a page, when it last crawled it and why the page may not appear in search. The URL Inspection Tool brings those answers together for one URL, then lets you compare Google’s stored version with what Google can access right now.
What the URL Inspection Tool Actually Tells You
The URL Inspection Tool shows how Google handled one specific URL during its last crawl and whether the current page appears available for indexing. It reports index status, crawl access, fetch results, canonical details, rendered content and detected enhancements. It is a diagnostic report for one page, not a complete ranking report.
The Evidence Google Shows You
The report shows whether Google indexed the URL, how it discovered the page, when it last crawled it and which canonical URL it selected. You can also review crawl permissions, fetch status, indexing permissions, structured data, loaded resources and rendered output. Google’s official URL Inspection documentation explains each report field.
- Overall status such as URL is on Google or URL is not on Google
- Discovery through a sitemap or referring page
- Last crawl time and crawler type
- Whether robots.txt allowed the crawl
- Whether a noindex directive blocked indexing
- User-declared and Google-selected canonical URLs
- Structured data and other detected enhancements
A page can be indexed and still rank poorly. The report answers whether Google can include the URL and what Google stored. It does not tell you whether the page deserves position one for a competitive query.
What It Cannot See
The tool cannot guarantee rankings, indexing or search visibility because it does not test every condition that affects Google Search. It does not replace manual actions, security reports, quality review or a full search performance analysis. A positive live test means Google can access the page, not that Google must index it.
The live test also cannot predict Google’s final canonical choice. Duplicate handling happens during indexing, so the indexed report remains the place to check the Google-selected canonical. The tool also does not turn a weak page into a useful one just because the server returns a successful response.
For a broader check across your site, start with a website health checker review. That process looks for patterns across pages rather than treating one URL as an isolated incident.
Professional insight
When I reach for URL Inspection instead of the Pages report
I open URL Inspection when a page shows an error in its schema or markup that stops it from being indexed.
That kind of error means something is systematically wrong on the page. Until it changes, Google will never serve that page, however many times you request indexing.
How to Run a URL Inspection Step by Step
Running an inspection takes only a few clicks when you use the correct property and enter the exact URL. Start with the indexed report, record the status and then run a live test if the page changed or the indexed result looks wrong.
Step 1: Open the Right Property
Open Google Search Console and select the property that contains the URL you want to inspect. A URL-prefix property must match the protocol and host covered by the property. A domain property covers the verified domain. If the property does not include the URL, Search Console will not return its report.
Check the property selector before you paste anything. Common mistakes include choosing a staging property, using the non-secure version of a site or inspecting the www version while viewing a non-www property.
Step 2: Enter the Full URL
Paste the fully qualified URL into the inspection bar, including the protocol, domain, path and any intentional trailing slash. Search Console treats URL variations as distinct addresses. Inspect the page you want Google to index, not a shortened domain or a nearby page that redirects somewhere else.
After you submit the URL, wait for the indexed report to load. The first report is not a live check. It reflects the last version Google processed for that address.
If you only need to know how to check if your webpage is indexed, the URL Inspection Tool gives a more reliable answer than a simple site search because it shows the reason behind the status.
Step 3: Read the Report Top to Bottom
Read the overall verdict first, then review page indexing, crawl details, canonical information and enhancements in that order. The top verdict tells you the broad outcome. The lower panels explain the evidence behind it. Record the last crawl date before making changes so you can compare the next inspection.
- Note the overall URL status
- Open Page indexing or Page availability
- Check discovery, crawl and fetch details
- Compare declared and selected canonicals
- Review structured data and other enhancements
- Run the live test when the current page may differ
The Status Messages and What Each One Means
Search Console status messages describe eligibility rather than ranking strength. URL is on Google means the inspected URL is eligible to appear, while URL is not on Google means the URL cannot appear in search in its current indexed state. Warnings identify issues that may limit enhancements without removing the URL from the index.
URL Is on Google
URL is on Google means Google has indexed the URL and considers it eligible to appear in search results. It does not promise a particular ranking or guarantee that every search will show the page. Check the last crawl, canonical and indexed content to confirm Google stored the version you intended.
URL Is Not on Google
URL is not on Google means the inspected URL cannot appear in Google Search in its current indexed state. Expand the Page indexing panel to find the reason. Common causes include noindex directives, robots.txt blocks, redirects, server failures, duplicate handling and pages Google has not yet crawled.
URL Is on Google but Has Issues
URL is on Google but has issues means the page is indexed while one or more detected enhancements have problems. The page may still appear in search, but malformed structured data or an associated feature can limit how the result displays. Fix the specific warning instead of resubmitting the page blindly.
Discovered and Crawled Currently Not Indexed
Discovered currently not indexed means Google knows the URL exists but has not added it to the index, while crawled currently not indexed means Google fetched it but did not add it. These statuses need different investigation. Review our discovered currently not indexed fix guide for the discovery status.
For a crawled page, inspect content uniqueness, internal links, canonical signals and page usefulness. A successful fetch alone does not make a page worth indexing.
Live Test Versus the Indexed Version
The indexed version answers what Google currently has stored. The live test answers what Google can fetch and render now. Comparing both views is the fastest way to separate an old indexing problem from a current technical problem. Use the indexed view for history and the live test for present conditions.
When to Use the Live Test
Use the live test after publishing a page, fixing an access problem, changing a canonical or removing a noindex directive. It fetches the current URL and reports whether Google’s inspection crawler can access and render the page. It can also show the rendered page, response details, resources and JavaScript output.
A live test is useful after a deployment because the indexed report may still describe the old page. Run the test only after the change is live and accessible without a login, firewall rule or temporary maintenance screen.
The live test shows exactly what Google sees: the HTML it renders. Some sites are built to look impressive, but their JavaScript blocks the HTML from loading, and the HTML is what Google actually reads. When a page shows an error, or Google shows it for searches you did not expect, I check the rendered HTML in Search Console to find out why.
Why the Two Views Disagree
The views disagree when the live page changed after Google’s last crawl or when the live test cannot assess an indexed condition. A removed noindex tag may appear clean in the live test while the indexed report still shows the old directive. Canonical selection and duplicate status also depend on indexed processing.
Do not treat the disagreement as a Search Console error. Compare the crawl date with your deployment date, inspect the current HTML and then request indexing if the live page is ready.
How to Fix the Errors URL Inspection Surfaces
Each error points to a different layer of the site. Robots.txt controls crawling, noindex controls indexing, server responses control access and canonicals guide URL selection. Fix the layer named in the report, confirm the repair with a live test and only then send a request for another crawl.
Blocked by robots.txt
Remove the robots.txt rule blocking the URL when the page should be crawled and indexed. Check the exact path because a broader directory rule may block the page even when the page itself looks correct. Do not use robots.txt to remove an already indexed page from search results.
Noindex Detected
Remove the noindex meta tag or HTTP header when you want Google to include the page in search. Check both the page source and server response because a plugin or deployment rule can add noindex outside the visible editor. Run a live test after the change to confirm indexing is allowed.
Soft 404 and Empty Content
Fix a soft 404 by restoring useful page content or returning the correct not-found response when the page should not exist. A page that returns a successful server response can still look empty, abandoned or irrelevant to Google. Review the main content, template output, internal links and rendered HTML.
Server Errors and Redirect Problems
Repair 4xx errors, 5xx failures, timeouts and redirect loops before asking Google to crawl the URL again. Test the page from a normal browser and review hosting logs if the failure appears intermittent. A redirecting URL should lead clearly to one relevant destination without a chain of unnecessary hops.
Canonical Mismatch
Align the declared canonical, internal links, sitemap entries and page content around the URL you want Google to represent. Google may select another canonical when duplicate signals conflict or another version appears more suitable. Inspect the selected canonical in the indexed report because the live test cannot predict that decision.
Professional insight
The surprise I find most often: a canonical Google picked from anchor text
The most common surprise URL Inspection shows me is a wrong canonical that Google has assigned because of anchor text.
I see it on a lot of sites where business owners change the meta values themselves and start moving pages around without a coordinated process. The Google-selected canonical in the indexed report is where it shows up.
When Validation Fails
The status that confuses my clients most is a failed validation. It usually comes down to a single item on a page. Open the failed example, read the reason, and Google tells you exactly what to fix. Most of the time it is a simple schema error or a small mistake that takes 15 minutes to fix when you know where to look.
Our broader guide on how to fix Google Search Console errors covers related indexing problems in greater detail. Keep your repair process tied to the reported cause rather than changing several unrelated settings at once.
Free resource
The Google Search Console Playbook
You can see the problem in Search Console. The next question is which five reports to check every month so it never builds up again.
Request Indexing: When It Helps
Request indexing tells Google that an inspected URL is ready for another crawl attempt. It does not guarantee indexing, ranking or a specific timeline. Use it after a meaningful fix or important publication when the live test shows that Google can access the current page and the page is intended for search.
What Request Indexing Cannot Do
Request indexing cannot force Google to index a page, select your preferred canonical or rank the URL for a target query. Google places the URL into a crawl and indexing queue after a quick check. The queue has limits and the result still depends on page quality, duplication and other conditions.
Google states that indexing can take longer than expected and that submitting a request does not guarantee inclusion. The official request indexing guidance also recommends sitemaps when you need to submit many updated pages.
I use Request Indexing a lot, but only on specific pages that link to other high-value pages, so the request gets those linked pages crawled too. Used that way, I have seen pages rank in under 24 hours. Google limits how many requests you can send; in my experience it is roughly 10-15 a day per property, so I save them for the pages that matter most.
A Better Sequence Than Repeated Requests
Fix the page, run a live test, confirm the important content renders, request indexing once and monitor the indexed report afterward. Repeatedly clicking the button does not repair a noindex tag, weak content or a canonical conflict. Those problems require a site change, not another submission.
- Confirm the URL should be indexed
- Fix the reported blocker
- Run the live test
- Review the rendered page and response
- Request indexing once
- Check the result later in the indexed report
Add important pages to your XML sitemap and keep it limited to URLs you want Google to crawl and index. If you are new to sitemaps, start with what is a sitemap. Internal links from relevant pages also help Google find important URLs naturally.
A Weekly URL Inspection Routine
A weekly routine should focus on the pages that create demand or support a customer decision. Inspecting every URL every week wastes time and can hide the pages that matter. Review key service pages, location pages, new content, recently changed pages and any URL connected to a sudden traffic change.
For my clients, the weekly Search Console check starts with four numbers: total queries, page rankings, clicks and the total number of pages ranking. Together they give me a snapshot of what changed, good and bad, and they point to the URLs worth inspecting that week.
Which Pages to Inspect and How Often
Inspect your homepage, core service pages, location pages and recently changed pages weekly, then review new pages soon after publication. Add pages to the list when they support active campaigns, seasonal demand or a major business offer. Use the Page indexing report for wider patterns across the rest of the site.
- Weekly: homepage and priority service pages
- Weekly: pages tied to active campaigns
- After publication: new service pages and important articles
- After changes: redesigned pages and URL migrations
- Monthly: a sample of older content and location pages
What to Record Each Week
Record the URL, overall status, last crawl date, indexing reason, selected canonical and any repair made. A short log gives you a history that Search Console does not present in one simple timeline. It also shows whether a problem affects one page or repeats across a template, directory or platform.
| Field | What to note |
|---|---|
| URL | The exact inspected address |
| Status | The top verdict and indexing reason |
| Last crawl | The date Google last processed the page |
| Canonical | The user-declared and Google-selected URLs |
| Next step | Fix, monitor, request indexing or leave unchanged |
Structured Data and Mobile Checks in the Same Report
URL Inspection can reveal structured data detected during indexing and can show how the page renders in a live test. These checks support technical diagnosis, but they do not replace the Rich Results Test, accessibility testing or real-device review. Treat the report as evidence about Google’s fetch and processing, not as a complete site review.
Reading the Structured Data Panel
The structured data panel shows eligible detected items and reports errors or warnings for supported search enhancements. A valid item may qualify for a richer search appearance, but structured data does not guarantee an enhanced result or indexing. Compare the markup with the visible page and remove claims that the page does not support.
Our guide to what is structured data explains how markup helps search engines interpret a page. Keep the implementation accurate, specific and consistent with the content users can see.
In my experience, JSON-LD schema kept in the page head is the cleanest signal Google and AI tools get from a page, especially one that leans on JavaScript. It has helped my pages rank faster and get cleaner, more consistent AI Overviews. I have tested this on three sites (Good Fellas, RUMCK Consignment and East Lake Neighbors), and ChatGPT cited the JSON-LD content almost exactly as written. Google reads schema as part of the page’s HTML, so the rendered HTML in the live test is where I confirm it is there.
Why Mobile Rendering Still Matters
Mobile rendering matters because the live test shows whether Google’s inspection crawler can load the page and its important resources on the mobile version. Review the screenshot, rendered content, CSS, JavaScript and images. Do not describe this as a mobile usability report because that panel is no longer the right test for this purpose.
Look for missing navigation, blank content blocks, hidden service details, broken images and scripts that prevent the main content from appearing. A page that looks fine in your browser may still deliver incomplete output when resources fail.
When URL Inspection Is Not Enough
URL Inspection answers what happened to one page. It is not a full technical audit, content review or growth plan. When several URLs show related problems, you need to trace the pattern through templates, internal links, hosting, canonicals, sitemaps and rendering rather than repairing pages one at a time.
One pattern explains why single-page repairs so often fail. A crawl audit usually finds pages that should be indexed but are not, pages that are indexed but should not be, redirect chains, internal link gaps and orphaned pages. Those conditions live in templates and site architecture, not in one URL. Fixing them one at a time leaves the underlying structure unchanged, which is why the same status tends to reappear a few weeks later on a different page.
Use a full review when:
- Many pages share the same indexing status
- Google selects unexpected canonicals across a template
- Important pages are missing from the sitemap
- Rendered content differs across devices or templates
- Organic traffic changes across several directories
- Server errors appear intermittently
That is where technical SEO services become useful. The work should connect crawl access, indexing, canonical selection, structured data, site speed and internal links to the pages that matter to the business.
Do not use the URL Inspection Tool as a daily slot machine. Inspect the right URLs, read the evidence, fix the named cause and keep a record of what changed.
Google can only evaluate the page it can fetch, render and understand. If your priority pages keep returning the same status, the problem is usually in the template rather than the URL.
Book a free SEO audit and we will inspect your priority pages the way Google does, from crawl access to canonical selection to rendering.
Frequently asked questions about the URL Inspection Tool
These answers cover the questions small business owners usually ask after an inspection. The central distinction is simple: the indexed report explains Google’s stored understanding while the live test checks the current page. Use both views when you publish, repair or investigate a page that is missing from search.
What is the purpose of the URL Inspection Tool?
The purpose of the URL Inspection Tool is to show how Google crawled, processed and indexed one URL on your verified property. It helps you find access blocks, noindex directives, fetch failures, canonical differences, structured data issues and changes between the stored page and the current live page.
How do I know if Google indexed my URL?
Inspect the full URL in Search Console and look for the status URL is on Google. Then open Page indexing and confirm the indexed URL, last crawl date and Google-selected canonical. A site search can offer a clue, but URL Inspection provides the verified report and the reason behind it.
What does URL is not on Google mean?
URL is not on Google means the URL cannot appear in Google Search in its current indexed state. Expand the Page indexing section to identify the cause. Fix the specific issue, run a live test and request indexing only when the current page is accessible and intended for inclusion.
Why does Google show discovered currently not indexed?
Discovered currently not indexed means Google knows the URL exists but has not crawled and indexed it yet. Improve discovery through relevant internal links and an accurate sitemap, then review content quality and duplication. Request indexing after the page is ready, but do not expect the button to guarantee inclusion.
Should I request indexing after every edit?
No, request indexing after a new important page or a meaningful repair rather than after every minor edit. Small changes can wait for normal recrawling through internal links and sitemaps. Repeated requests do not improve a page that still has a crawl block, noindex directive, duplicate issue or weak content.
Can the URL Inspection Tool show why my page is not ranking?
The tool can show technical reasons a page may be unavailable, but it cannot explain every ranking result. If the page is indexed, investigate relevance, competition, content quality, internal linking and search intent separately. A clean inspection removes one barrier, but it does not create authority or demand.
Can I inspect a competitor’s URL?
No, the URL Inspection Tool requires a URL within a Search Console property you can access. You cannot use it to inspect a competitor’s indexed data or request crawling for another site. You can study public search results, then use your own property to test how your pages are built and processed.
How often should a small business use the tool?
Most small businesses should inspect priority pages weekly and inspect new or changed pages after publication or repair. Use the Page indexing report for broad patterns and reserve individual inspections for pages tied to leads, revenue, campaigns or recent technical changes. Keep a simple log so decisions stay consistent.
