Using Search Console to Diagnose an Unindexed Page

When an important page is missing from Google, start with its exact URL. A sitewide indexing total cannot tell you whether that page returns an error, blocks crawling, points to another canonical URL, or is simply absent from Google’s index. The useful question is narrower: what can be verified about this URL now, and what did Google report when it last assessed it?

This is a practical way to use Search Console page indexing data: establish the page’s current technical state, compare it with Google’s recorded state, then decide whether to fix the page, improve its discovery, or wait and recheck. Google’s Search Console guidance describes the Page indexing report, sitemaps and URL Inspection as tools for related but different questions. Use each for the evidence it can provide.

Begin with one URL and its actual response

Write down the full URL, including its protocol, host and trailing slash. For illustration, suppose a site owner wants https://example.com/guides/choosing-a-desk/ indexed. This is a hypothetical page, not a report of a live inspection. Its purpose is to show what a complete diagnosis would record.

Fetch that exact address and follow the response carefully. Does the requested URL itself return HTTP 200, or does it redirect to a different address? Does the final response deliver the intended article to a visitor without requiring a login? A browser can display a helpful-looking page while the underlying response is a redirect, an error, or a thin “not found” message. Record both the status and the content received, rather than assuming that a page is sound because it opens in a tab.

Google’s minimum technical requirements are a useful baseline: Googlebot must be able to access the page, Google must receive a successful 200 response, and the page must have indexable content. Meeting those requirements makes a page eligible for indexing; it does not ensure that Google will index it.

Next, inspect the controls that apply to this URL:

Robots: Check the relevant robots.txt rules and whether they allow Googlebot to crawl the path. Separately check the page’s robots meta tag and any X-Robots-Tag response header for noindex. A crawl rule and an indexing directive answer different questions.
Canonical: Read the page’s declared canonical URL. Does it name this exact page, another version of it, or an unrelated page? Also check for a canonical declaration in the HTTP headers if the site uses one.
Sitemap: Check whether the submitted sitemap contains the intended canonical URL. Note whether it lists a redirect, an alternate host, or a different trailing-slash version instead.
Discovery: Find a normal, relevant internal link to the page. A sitemap entry helps discovery, but it should not stand in for a route visitors can follow through the site.

A canonical declaration is a preference, not a command. Google weighs signals and may select another representative URL for similar content. Sitemap inclusion is also a weaker canonical signal than a canonical annotation, so conflicting entries deserve attention. Google’s canonical URL guidance recommends consistent signals rather than naming different preferred URLs through different methods.

Compare Google’s recorded view with the live test

Open URL Inspection in the correct Search Console property and enter the complete URL. First read the Google index result: the page verdict, the reason under Page indexing, the last crawl date, the last page fetch, whether crawling and indexing were allowed, and any user-declared and Google-selected canonical URLs shown. Save those details before running a live test.

Then select Test live URL and inspect its availability result. If needed, use the tested page details to examine the rendered page, response information and loaded resources. Google’s URL Inspection documentation distinguishes the information Google has about the URL in its index from a live test of whether the current page might be indexable. The live test does not predict Google’s canonical choice or guarantee inclusion in the index.

The last crawl date makes disagreements understandable. If the indexed result records noindex from an earlier crawl but the live test now finds no such directive, a repair may already be in place. If the live test fails while the indexed result reflects an older successful fetch, investigate what changed after that crawl. Record the time of each observation. Do not describe an old Google result as the page’s current response, or a successful live test as proof that the page is indexed.

Turn the exclusion reason into a check

Search Console’s Page indexing report separates several reasons that can look alike in a headline count. “Not indexed” can describe an intended duplicate or removed page as well as a problem. Use the reason attached to the URL to choose the next check:

Blocked by robots.txt: Test the rule against the exact path and Googlebot. Confirm whether the block is intentional. If this page should be crawled, correct the applicable rule. Recheck access before asking Google to revisit it.
URL marked “noindex”: Look for the directive in the current HTML and response headers, then compare it with the indexed and live inspection details. Remove an unintended directive and verify that the live test no longer detects it.
Server error, access error or soft 404: Check the real response and the content served to an unauthenticated visitor. Compare intermittent failures with the last Google fetch. Repair the response or supply a genuine page. If the content is deliberately gone, use the appropriate missing-page response.
Page with redirect: Trace the requested URL to its destination and inspect the destination separately. Decide whether the redirect is intended. Judge indexing of the final page on its own evidence.
Duplicate or alternate; different canonical selected: Compare the inspected page with Google’s selected canonical, the declared canonical, sitemap entries and internal links. If Google selected the appropriate representative, leave the duplicate alone. If the pages serve distinct needs, clarify their content and align canonical signals.
Discovered but not yet indexed: Confirm that the URL is linked, listed correctly in the sitemap and available when fetched. Check whether Search Console records a crawl date. Resolve discovery or availability issues you can demonstrate, then allow time for a crawl.
Crawled but not yet indexed: Compare the last crawl with recent edits. Review the page’s substantive content and its overlap with other pages. Improve a weak or redundant page when the comparison warrants it. Do not assume another crawl request fixes the decision.

Complete the single-URL diagnosis

Return to the hypothetical guide. Its current response and directives pass the basic checks. Its sitemap and internal link use the same URL. Search Console says it was crawled but is not indexed; the recorded crawl predates a substantial edit. The next editorial check is to compare the guide with other pages on the site. Does it answer a distinct reader question, or repeat an existing desk-buying overview with a new title? Is the main explanation present in the content Google can retrieve? Those questions matter more here than repeatedly changing a canonical tag that already points to the intended URL.

If the revised guide offers a distinct, complete answer, record that assessment and the date of the edit. A request for indexing may be appropriate after a meaningful repair, but it is a request for Google to revisit the URL, not an indexing order. If the guide remains substantially redundant, decide whether to improve it, consolidate it with the stronger page, or accept that the other page is the useful canonical. The report should lead to a content decision supported by the comparison, not an automatic instruction to make every listed URL indexable.

Close with a decision log and a recheck date

Finish the investigation in a short record that another editor or developer can verify. For the example, it might read:

URL and intent: https://example.com/guides/choosing-a-desk/; intended as the site’s distinct guide to choosing a desk.
Current site evidence: HTTP 200, crawl allowed, no noindex, self-declared canonical, sitemap entry and relevant internal link; checked on the recorded investigation date.
Google evidence: Crawled but not yet indexed; last crawl predates the most recent content revision; live test finds the current URL accessible.
Decision: Keep the page if the revised guide answers a separate need; otherwise consolidate the overlap. Record any actual edit and whether an indexing request was submitted.
Recheck: Set a calendar date after the edit or request. Compare the URL Inspection status, last crawl date and Google-selected canonical at that review.