When a page you published is not showing in search, the URL Inspection Tool is where you find out what Google actually sees, rather than guessing. What does it tell you? Whether the address is indexed, when it was last crawled, what blocked it if anything did, and which version Google chose. Who should use it? Anyone who publishes a page that matters this week, from a new service page to a corrected product listing.
Where do you find it, and when should you reach for it? It sits inside Search Console, and the right moment is as soon as you notice a missing page, not after a month of wondering. Why does a structured check beat random fixes? Because indexing problems look identical from the outside, a silent page, while their causes range from a stray noindex tag to a redirect you forgot you set.
How will this guide work? Bring one address that should be in search and is not, and work along step by step.
Save yourself time with three checks before you inspect anything. First, confirm the page actually exists by opening it in a private browser window while logged out. Second, check it is linked from somewhere on your own site, because an orphan page with no internal links is discovered slowly, if at all. Third, confirm you are looking at the correct address, including whether your site uses www or not.
Also check your expectations. A page published yesterday may simply not have been crawled yet, which is a queue, not a fault, and a thank you page after checkout should not be indexed at all.
Paste the full address into the inspection bar and wait for the result. The headline verdict tells you one of three broad stories: the page is on Google, the page exists but is not indexed, or there was a problem fetching it. Read that headline slowly, because every detail below it explains that one sentence.
Note the last crawl date and whether indexing was allowed, then open the coverage details. There the tool names the specific reason, such as a noindex instruction, a redirect, or a soft error. That named reason is your diagnosis, so write it down exactly.
If the address itself is part of the problem, for example a messy parameter version being chosen over your clean page, tidy the structure first. A helper like a URL rewriting tool can help you plan clean, consistent addresses, but only change live addresses with redirects in place and a clear reason.
Now translate the diagnosis into action. A noindex result means something told search engines to keep the page out: find that instruction in the page settings, template, or header, remove it if it was accidental, and request a fresh crawl. A blocked by robots result means your robots file disallows the address, which is a one line fix but one you should double check before editing.
A crawled but not indexed result is subtler. Google saw the page and chose not to include it, usually because it looks thin or duplicated. The fix is editorial: add genuinely useful detail, or merge it with a similar page.
For wider context on how indexing fits into optimisation overall, the overview of search engine optimization is a useful refresher, and the how to archive on the Seovaro blog can help you work through whichever fix your diagnosis points to.
After a real fix, use the request indexing option once. It places the address in a priority queue; it does not guarantee inclusion, and pressing it repeatedly does not move you up the line. Think of it as handing in a corrected form, not as a lever you can pull harder.
Then verify properly. Wait a few days, inspect again, and check whether the crawl date and status changed. Keep a small log of the reason found and the fix applied. Finally, look for a pattern: five blocked pages sharing a template is a system fault in that template, worth more than rescuing addresses one at a time.
Got a page that should be bringing in work right now? Open the URL Rewriting Tool alongside Search Console, inspect your problem address, write down the exact reason given, and complete the matching fix this week. One diagnosed page, fixed for a named reason, beats a dozen hopeful resubmissions.
No. Requesting places the page in a priority crawl queue, but Google still decides whether the page merits indexing after crawling it. If the underlying reason, such as a noindex tag or thin content, is still there, the request changes nothing.
Your canonical is a hint, not an order. Google weighs it against internal links, sitemap entries, redirects, and which version looks most complete. When signals conflict, it picks the version it trusts most. Align all your signals on one address to get your preference followed.
Indexed and ranking are different things. The page is in the index but may rank too low to see for the term you tried. Search for an exact phrase from the page, check you are not personalising results, and then treat it as a quality and relevance job, not an indexing fault.
