Learning how to use the URL inspection tool is the fastest way to answer a stressful question: why is this page not in Google? What the tool does is show you, for one exact address, what Google's index holds, what a crawl found, and what is stopping the page appearing. Who can use it is anyone with verified access to the site's Search Console property, no developer required.
When to reach for it is the moment a valued page is missing, showing an old version, or behaving oddly on mobile. Where it lives is the inspection bar at the top of Search Console. Why it beats guessing is that it replaces rumours with the index's own record: discovered, crawled, indexed, or excluded, with a reason. How to work through it is this walkthrough.
Open the correct property, because a domain property and a prefix property can show subtly different data. Paste the full, exact address, including protocol and trailing slash, copying it from your browser or sitemap rather than typing the version you think exists. Copying errors are a classic cause of confusing results.
The summary gives a plain verdict: the page is on Google, it is not, or it is there with issues. Do not stop at the verdict. Expand the coverage sections beneath, because the reason codes are the real diagnosis. Detail on how visit data is classified in Google's analytics documentation also helps you check whether the page still receives visits from other sources while search is blocked.
Three fields explain most cases. Discovery shows how Google found the address: sitemap, a referring page, or not yet discovered. Last crawl shows when a crawler visited and which type it was. Indexing allowed and page fetch show whether a rule blocked the visit or the server failed.
Do not skip the canonical pair: the canonical you declared and the one Google selected. When they differ, Google trusts another page more as the main version, often because content is very similar. Tidying duplicate addresses with a URL rewriting tool can standardise versions and make your intended page the obvious choice.
None of those fixes requires guesswork. Each code maps to a small set of causes, checked in order, which is exactly what an expert would charge you to do.
The tool's second mode is its most underused feature. Test Live URL fetches the page fresh, as Google would now, rather than reporting what the index remembers. After a fix, the index view may still show a noindex tag you removed yesterday, while the live test proves it is gone.
In the tested page view, check three things. The screenshot should look like the page visitors see, not a bare skeleton. The HTML should contain your main content, headings, and canonical. The resources list should show no important files blocked or failing. If the live version renders badly, resubmission will not help.
Only when the live test is clean should you use Request Indexing. That button asks for a fresh crawl; it guarantees neither inclusion nor speed. More worked examples of inspection reports sit on the Seovaro blog.
Work one cause at a time, so you know what solved it. After the fix and a clean live test, submit the request, note the date, and check back in a week rather than daily. Quality-related decisions commonly take days to weeks, and repeated requests do not speed them up.
That log turns a one-off rescue into lasting health. Patterns across pages reveal a release quietly adding noindex to a whole section, which page-by-page checking alone would take weeks to spot.
Choose the missing page that matters most, run it through the steps above, and write down its reason code before changing anything. If the code points to messy duplicate addresses, try the URL Rewriting Tool linked above to tidy your versions, then finish with a clean live test and one patient indexing request.
Inspection is generous, but live tests and indexing requests have daily quotas per property. Prioritise important pages, avoid repeated tests of one address in a day, and remember that inspecting more often does not speed Google's decision.
The request only joins a crawl queue. Google still evaluates quality, duplication, and crawl priorities before including the page. A thin or near-duplicate page will be excluded again until the underlying issue is fixed.
Then indexing is not your problem; ranking is. The page may sit deep in results, or location and personalisation may hide it from your searches. Check its real impressions and positions in Search Console performance data.
Either works with verified access, but the domain property gives the complete picture across subdomains and protocols. If results confuse you, confirm you are inspecting under the property matching how the site is actually used.
