Google Search Console URL Inspection: How to Read It

Where URL inspection fits

Picture a Tashkent furniture shop that sells on Uzum and OLX but also wants its own website to bring in direct orders. A new category page goes live, yet a search for its name shows nothing. Instead of guessing, paste the address into the search bar at the top of Search Console. The address has to belong to a verified property.

Keep the scope in mind: the tool explains one page. For a sitewide picture, use the page indexing report, and use URL inspection to investigate a specific case.

What the Google Search Console URL inspection report shows

The report describes how the page is stored in Google’s index. These are the fields worth reading first:

All of this reflects the moment of the last crawl. If you fixed the page yesterday and Googlebot last visited a week ago, the report still shows the old state. That is how the index works, not a bug.

• Whether the page is in the index and, if not, why.
• How Google found it: a sitemap or links from other pages.
• The last crawl date and which crawler, mobile or desktop, fetched it.
• Whether crawling and indexing are allowed.
• The canonical you declared versus the one Google chose.
• Structured data detected on the page, and errors in it.

Live test: what Google sees right now

The live test fetches the current version of the page. After a fix, this is the step that matters: you confirm the obstacle is gone without waiting for a recrawl. You can open the rendered HTML, a screenshot and the list of resources that failed to load.

If your site is built on a template builder or leans on JavaScript, look here first. When the main text appears in a browser but not in the rendered HTML, Google effectively has nothing to rank.

Google mostly crawls with its mobile crawler, and many local visitors arrive from an Instagram or Telegram link on a phone. Compare the screenshot with what a person sees on a smartphone. Blocks that are hidden or fail to load on mobile may never reach the index.

The canonical trap

The most revealing field is the Google-selected canonical. When it differs from yours, Google treats your page as a copy of another one and shows that one instead. Imagine a clinic with two pages, one about teeth treatment and one about dentistry in Tashkent, with nearly identical text. Google picks one and the other quietly disappears, even though money went into writing it.

Usual causes are near-duplicate content, internal links pointing to another version of the URL (with or without www, with or without a trailing slash), and a redirect that contradicts the canonical tag. The fix is to make the pages genuinely different or merge them, align links and canonical on one address, request indexing and recheck after a few days.

Common statuses and what to do about them

The status at the top of the report is your starting point. These come up most often:

• “URL is on Google”: indexed and eligible to appear; the question moves to content and rankings.
• “URL is not on Google”: read the reason listed under the status.
• “Excluded by noindex tag”: remove the directive if the page should rank. A leftover from development is a frequent culprit.
• “Blocked by robots.txt”: the crawler cannot get in; review the file’s rules.
• “Page with redirect”: fine if intended, a problem if not.
• “Crawled, currently not indexed”: Google saw the page and has not included it. Stronger content and internal links usually help more than repeated requests.

When to request indexing, and when not to

The request button puts the URL into a priority crawl queue. It makes sense after publishing an important page, after a substantial content change, after fixing the error that dropped a page, or after rewriting a title and description to refresh the snippet.

There is a daily quota, and a request guarantees nothing: it speeds up crawling, not inclusion. If Google considers a page low-value or a duplicate, ten requests will not change that. Skip unchanged pages, utility URLs and pages under noindex. When hundreds of product cards change, say after a price update in soums, a sitemap with honest lastmod dates and solid internal linking works better than manual requests.

Make it a routine, then connect it to strategy

The habit is simple: publish or edit an important page, inspect the URL, run the live test, request indexing if needed. It takes minutes and catches problems before they cost you leads. For bulk checks there is the URL Inspection API, which also has daily limits.

Still, the tool answers “what is wrong with this page”, not “which pages does the business need”. Choosing which services to push, how to split them across pages and how search should work alongside Meta and Google Ads is a strategy question. markdev helps companies in Uzbekistan set those priorities through marketing strategy and consulting. Describe your task and we will discuss where to start.