How the URL Inspection tool works
Paste any URL from a verified property into the search bar at the top of Google Search Console and it returns Google’s own record for that single address. By default it describes the version Google already holds, gathered on its most recent crawl. A separate Test Live URL button fetches the page again, right now, and shows what Googlebot would get today.
The record covers whether the URL is indexed and why, how it was discovered — a sitemap entry, a referring page — how it was crawled, and which URL Google chose as the canonical. It also lets you open the rendered HTML, view a screenshot of the page as Googlebot saw it, read a list of resources that failed to load along with any JavaScript errors, and see which structured data types were detected.
Why URL Inspection matters
Two of those details are hard to get anywhere else. The first is the Google-selected canonical, printed next to the one you declared. When the two differ you have usually found the reason a page is invisible: Google is filing your content under a different address, and everything you do to the page you are looking at goes to the credit of another URL.
The second is the rendered HTML. If a page builds its main content with JavaScript, what you see in a browser and what Google indexed can be genuinely different pages. Reading the rendered output settles that argument in a minute rather than a week.
Common mistakes with URL Inspection
Confusing the two views is the frequent one. A Live Test that passes proves the page is healthy now; it says nothing about the version sitting in the index, and people announce a fix on the strength of the wrong tab. Read the last crawl date before drawing any conclusion about current search behaviour.
The other is using Request Indexing as a strategy. It moves a URL up a queue. It does not persuade Google that the page deserves to be kept, there is a daily cap on how often you can ask, and pressing it after every small edit spends the allowance for nothing. A tool that examines one URL is also the wrong instrument for a pattern — when a whole section has gone missing, the page indexing report will show what those URLs have in common far faster.
How to act on it
Treat it as a confirmation step rather than a monitoring habit. When a page has just been published or substantially rewritten, inspect it, check that crawling and indexing are allowed, confirm the canonical matches your intention, request indexing once, and leave it alone.
When something is genuinely wrong, read the record in order: did the fetch succeed, was crawling allowed, was indexing allowed, is the canonical the one you expected. Each answer rules out a whole class of cause, which is quicker than guessing. If the rendered HTML is missing your main content, the problem is JavaScript rendering and belongs with a developer. If the same failure appears on page after page, stop inspecting individual URLs and handle it as a technical SEO problem at site level.