How URL Inspection works
You paste one address into Search Console and it returns what Google holds on file for it. The answer covers whether the URL is in the index, how it was discovered, when it was last crawled, which user agent crawled it, whether the crawl succeeded, and which address Google settled on as the canonical version — which is not always the one you declared.
Two views are available and they are easy to confuse. The indexed view describes the copy Google already has, which may be weeks old. The live test fetches the page now, renders it, and reports what a crawler would see today. Both let you open the rendered code and a screenshot, which is where JavaScript problems become obvious: if content is missing from the rendered output, it does not exist as far as search is concerned, no matter how clearly it appears in your browser.
Why URL Inspection matters
Site-wide reports tell you a category of problem exists. This tells you what happened to the one page you actually care about, which is usually the question a client is asking. When a new service page has not appeared in results, this is the fastest way to find out whether it was never crawled, was crawled and rejected, was blocked, or was quietly folded into another URL as a duplicate.
It is also the honest way to check a fix. After changing a canonical URL, a robots rule or a redirect, a live test shows immediately whether the change reaches Google, rather than waiting to see whether rankings move.
Common mistakes with URL Inspection
The biggest is treating the live test as proof of indexing. A green live test means the page can be fetched and rendered right now. It says nothing about whether Google has chosen to keep it, and pages pass the test yet stay out of the index because they are thin, duplicated or unlinked.
Requesting indexing is the second. The button adds the URL to a queue; it does not promise inclusion, does not speed up ranking, and pressing it repeatedly achieves nothing. If a page is refused, the fix is the reason for the refusal, not another request.
The third is ignoring the canonical comparison. When the declared canonical and the selected canonical differ, Google has overruled you, and every other diagnosis you make on that page will be wrong until you understand why.
How to act on it
Use it as a diagnosis step, never as a strategy. Inspect the page, read the crawl date, compare declared and selected canonicals, then run the live test and read the rendered code rather than the source. Only after that should you decide what to change.
When the same finding appears on several pages, stop inspecting one at a time and treat it as a pattern: a template, a robots rule or an internal linking gap. That is technical SEO work, and it is cheaper to fix once at the template level than to chase individual URLs through this tool for a week.