URL Inspection is the most useful diagnostic in Search Console and the most underused. It answers, for one URL, what Google actually knows: whether it is indexed, when it was crawled, what canonical was chosen, and what the rendered page looked like.
Most indexation arguments are settled in thirty seconds by inspecting a URL rather than theorising about it.
What it tells you
Index status and reason
Whether the URL is indexed, and if not, the specific reason. That reason determines the fix entirely, which is why guessing without it wastes time. See crawlability vs indexability.
Last crawl date
Frequently the answer to “why has our fix not worked?” If the page has not been recrawled since the change, nothing could have changed. This single field prevents a great deal of unnecessary further work.
Google-selected canonical
Reported alongside your declared canonical. Where they differ, Google overruled you, which is a specific situation with a specific remedy. See Google chose a different canonical.
Discovery method
Whether the URL was found via sitemap or referring page. A page discovered only through the sitemap usually has an internal linking problem.
Rendered HTML
The most valuable and least used part. It shows what Google actually saw after rendering, which on JavaScript-heavy sites is frequently not what you see in the browser.
Indexed page versus live test
Two different things, and confusing them causes confusion.
- Indexed page: what Google has stored from its last crawl. This is what is currently affecting search results.
- Live test: fetches the page now. This shows whether your fix works, before waiting for a recrawl.
The sequence that answers most questions: check the indexed version to see the problem, run a live test to confirm the fix, then request indexing.
Using it well
- Inspect a representative URL per template rather than only the homepage, since faults are usually template-level.
- Compare rendered HTML against source on any page where content loads via JavaScript.
- Check the crawl date before concluding a fix failed.
- Use the live test after every fix, rather than waiting weeks to find out.
- Request indexing sparingly and only after something has genuinely changed.
What it will not do
- Requesting indexing does not override a directive or improve a quality assessment.
- It works one URL at a time, so it diagnoses rather than surveys. Use the Page indexing report for patterns.
- It does not report ranking, only inclusion.
Frequently asked questions
How often can I request indexing?
There is a daily quota, and repeated requests on an unchanged page achieve nothing anyway. Change something first, then request.
The live test passes but the page is not indexed. Why?
The live test shows the page is fetchable now. Indexing is a separate decision, and the stored version may still reflect an earlier state. Check the crawl date and the stated reason.
Rendered HTML differs from what I see. Is that a problem?
It can be a significant one. If content is missing from the rendered version, it effectively does not exist for search. See JavaScript SEO.
Can I inspect any URL?
Only URLs in a property you have verified. That is one reason to verify both properties during a domain migration.
Consulting CTA
If URL Inspection is reporting something you cannot interpret, book an SEO consultation.