How to diagnose a page Google hasn't indexed

Separate deliberate exclusions from real indexing problems. A worked example shows how to check directives, canonical versions, and incomplete pages before choosing a fix.

Uriel BittonPublished October 13, 20269 min read

The title “How to diagnose a page Google hasn't indexed” appears in bold charcoal text on the right, beside an amber glass card organizer, ivory page cards, and an amber inspection prism on pale stone.

In this guide

To diagnose a page Google hasn't indexed, first decide whether that exact URL should appear in Search. Then inspect the reported reason, compare Google's recorded crawl with the current page, and choose a fix you can verify. An intentional exclusion, a blocked public guide, and a duplicate URL need different responses.

Treat the investigation as a decision about a specific page. The goal is to make your important content eligible and discoverable, while keeping deliberate exclusions intact. A lower total of unindexed URLs is not enough to tell you whether the right pages are available.

This guide uses a fictional content library to show why one template repair can help two public guides without changing a confirmation page or a duplicate address.

Decide whether this URL should be indexed

One ivory page card stands inside an amber glass frame, beside cards in an ivory archive holder and another card on pale stone.

Decide which pages should appear before changing their exclusions.

Write down the expected result before changing anything. Is this the main public guide, a copy of it, a retired page, or a page that exists only to confirm an action?

For a public guide, you may want Google to index this address. For a duplicate, you may want the preferred version indexed instead. For a newsletter signup confirmation, exclusion may be deliberate.

Google's Page indexing report guidance says non-indexed URLs can be expected and that every URL on a site need not be indexed. It directs you to URL Inspection for the status of an individual page.

Record the exact address, including any parameters. A campaign-tagged copy and the main article may show the same content while having different URLs. Investigating the copy as though it were the only version can send you toward the wrong fix.

Add the page's purpose and owner to your notes. “Public setup guide; should be discoverable at this address” is a more useful starting point than “make the report green.”

Compare Google's recorded crawl with the current page

Two ivory cards show different sets of embossed lines, one in an amber archive holder and one in an amber inspection frame, with a small amber prism between them.

Compare the recorded evidence with the page delivered now.

Inspect the URL in Search Console and record the reported reason, last crawl time when available, and canonical information. A canonical is the representative URL selected from duplicate or very similar pages.

Use the URL Inspection documentation to distinguish the indexed results from a live test. The recorded result can describe an earlier version. A live test fetches the current page, but does not establish that it is indexed or guarantee future indexing.

This matters after a repair. If a guide was crawled with noindex on Monday and you removed it on Tuesday, the old crawl record may still describe Monday's page. Save both timestamps so you can tell whether you are looking at fresh evidence.

Check the page that is actually delivered. Google's crawling troubleshooting guide recommends inspecting the rendered content and response code when a useful page appears to be missing or fails to load properly.

A title and navigation can load while the instructions fail. Examine the main content, not just the page's frame. If you intended to publish a setup guide, check that the steps, relevant images, and supporting text are present in the tested view.

For canonical questions, use the recorded Google-selected canonical. The live test cannot predict which URL Google will choose.

Check the condition that could explain the result

Use the reported reason to decide what to inspect next. Avoid applying every possible SEO change to one page at once; that makes it harder to tell which defect you repaired.

If access or rendering failed

Confirm whether the intended public page is reachable and whether the reported failure persists. Check the actual response, redirects, and rendered content. If several affected pages share a template or data source, inspect that shared dependency.

A normal visit succeeding now does not establish that a previous failure never happened. Compare the test time with the recorded crawl and any relevant server evidence you have.

Google distinguishes crawling from indexing in its troubleshooting guide. Restoring a working page makes the content available to inspect; it does not establish that Google has indexed it.

If indexing is blocked by a directive

Google's noindex documentation describes two places to check: the page's robots meta tag and the HTTP response header. A CMS setting or a shared template may produce either.

Remove an accidental directive from a page you intend to index. Check other pages using the same setting, and verify the delivered response after the change. Keep deliberate exclusions in place.

Also distinguish a robots.txt crawl block from noindex. Google needs access to the page to see its indexing directive. Blocking the crawl does not reliably keep the URL out of Search, because Google may know about it through other sources.

Make the change at the level that caused the problem. A setting inherited by every public guide deserves a template review; a one-page exception may need a narrower edit.

If Google selected another version

Open the inspected page, your declared canonical when present, and Google's selected version. Compare their content and intended purposes.

Google's canonical guidance describes canonical declarations as signals for duplicate or very similar pages. Google makes the selection. Its documentation also recommends linking consistently to the preferred URL.

If the chosen version is the intended main page, the duplicate's exclusion may be correct. If the destination is unexpected, inspect the declarations and the content relationship before changing them.

Don't nominate an unrelated page merely because you would prefer it to appear. First establish whether these addresses represent the same content or genuinely different tasks.

A worked example: one repair and two deliberate exclusions

Two ivory page cards sit on amber glass supports joined by one fitting, with an amber glass adjustment tool beside them on pale stone.

Check whether a shared defect calls for one targeted repair.

Consider a fictional company with a small library of scheduling guides. The addresses, reported conditions, and inspection findings below are assumed inputs for the exercise. They are not results from a live website audit or customer study.

The owner reviews five URLs:

Page	Intended outcome	Assumed evidence	Next decision
Appointment reminder guide	Index the main public guide	Recorded exclusion due to `noindex`; current response still contains it	Repair the guide template's accidental directive
Calendar setup guide	Index the main public guide	Same directive, inherited from the same template	Verify that the shared repair covers this guide too
Newsletter signup confirmation	Keep it out of Search	Its `noindex` setting is intentional	Preserve the exclusion
Campaign-tagged copy of a scheduling overview	Use the main overview as the Search version	Recorded duplicate exclusion; selected canonical is the indexed overview	Preserve the intended representative URL
Booking migration guide	Index a useful public guide	Recorded as crawled but not indexed; current page shows an introduction while the steps fail to load	Repair the incomplete page, then reassess using fresh evidence

There are two immediate repair jobs in this example: the shared directive affecting the first two guides, and the missing instructions on the migration guide. The confirmation page and campaign copy do not need to become separately indexed to fulfill their purposes.

For the template repair, define a check before making the edit. The delivered responses for both public guides should stop carrying the unintended directive. The confirmation page should retain its deliberate setting.

That last check is important because it tests the boundary of the change. Removing a site-wide exclusion switch indiscriminately would fail the owner's intended outcomes even if more URLs became eligible.

The migration guide requires a different kind of care. Its current missing steps are a real defect within the assumed scenario. They do not prove what Google saw during an earlier crawl or explain Google's indexing decision by themselves.

Repair the incomplete guide because it fails its reader's task. Record when the steps began rendering correctly, compare that with later crawl evidence, and keep the indexing conclusion open until the report supports it.

Our guide to choosing which blog posts to update first gives a broader method for prioritizing defects that affect an important answer or decision.

Treat discovery and crawling as different starting points

Google's indexing reason definitions distinguish “Discovered - currently not indexed” from “Crawled - currently not indexed.” The first means Google knows the URL but has not crawled it; the second means it has crawled the page without indexing it.

The label narrows the next investigation. It does not provide a complete explanation of the page's value or prescribe a rewrite.

For a discovered page, review the paths that expose it and any reported access or availability problem. Google's crawling guide describes sitemaps and crawlable links as ways to expose new or updated pages, without promising immediate crawling.

For a crawled page without an obvious access defect, review the actual answer and its relationship to other pages. Does it complete the task promised by the title? Is a near-identical guide already available? Are essential details missing from the rendered page?

Those are editorial questions to investigate, not confirmed causes inferred from the status. Don't add words or change a title solely to produce the appearance of a refresh.

Our internal linking guide explains how to build useful routes into important content. Our guide to what makes a page worth citing covers the evidence and original value a reader should find when they arrive.

Define the evidence that would show the fix worked

Keep a short record of the intended outcome, reported reason, additional observation, change, and check. Give the check a concrete result:

An accidental directive no longer appears in the intended public page's response.
A broken guide now renders the missing instructions.
A duplicate still identifies the intended representative page.
A deliberate exclusion remains in place.

Then track indexing as a separate outcome. A verified repair and a new indexed result are different pieces of evidence, potentially recorded at different times.

For an eligible URL you materially repaired, follow Google's URL Inspection instructions if you request indexing. A request does not guarantee inclusion. Google's indexing report documentation also says a crawled-but-unindexed URL does not need to be repeatedly resubmitted for crawling.

Save the next crawl time and result when they become available. If the result still differs from your intended outcome, use the new evidence to choose the next investigation. Repeating the same request without a new observation adds little to the diagnosis.

Keep indexing separate from rankings and AI visibility

An indexed page is eligible to appear in Search; it is not assured a visible position for every query. Google makes that distinction in its Page indexing report guidance.

Google's AI features documentation says a supporting link in AI Overviews or AI Mode must be indexed and eligible for a Search snippet. Meeting the requirements does not guarantee inclusion.

An indexing repair can address an eligibility problem. A claim that the repair improved ranking, brought qualified visits, or earned an AI citation needs evidence of that outcome. Our AI visibility measurement guide explains how to record those outcomes separately.

Start your next investigation with one important URL. State whether that address should be indexed, save the reported reason, and compare it with the current page. Make the smallest supported repair and define how you will verify it before submitting another request.

References

Back to the journal