Indexing Diagnosis Worksheet for Search Console

Confirm the Problem

When to use: You think a page should be indexed but aren't sure it actually isn't.

Start by proving the page is genuinely excluded

Before changing anything, confirm the URL is truly missing from Google's index. A page that ranks for its own title is already indexed.

• Search Console URL Inspection: paste [Full URL] into the inspection bar and read the verdict at the top. "URL is on Google" means it is indexed; "URL is not on Google" means it is not.
• site: query: run a search for [site:example.com/path]. No result is a strong signal, but trust URL Inspection over [site:], which can lag.
• Coverage context: open the Page Indexing report and find which excluded reason this URL falls under.

Record the exact reason string Google reports. The fix for "Crawled - currently not indexed" is completely different from "URL blocked by robots.txt," so capturing the precise state now saves wasted effort later.

Inspected URL: [URL]   Reported state: [State]

Crawled-Not-Indexed & Discovered-Not-Indexed

When to use: Google knows your URL but has chosen not to index it (yet).

Two different signals, two different responses

These states usually point to value or crawl-budget issues rather than a technical block, so resist the urge to just hit "Request indexing" repeatedly.

• Crawled - currently not indexed: Google fetched the page but decided it wasn't worth indexing. This is most often a quality or value signal: thin, duplicative, or low-demand content.
• Discovered - currently not indexed: Google found the URL (often via your sitemap) but hasn't crawled it yet. This frequently reflects crawl-budget limits or a slow, large site.

For Crawled-not-indexed, strengthen the page: deepen the content, add internal links from relevant indexed pages, and make sure it serves clear intent. For Discovered-not-indexed, reduce crawl waste: fix slow responses, prune low-value URLs, and improve internal linking so important pages are reachable in fewer clicks.

State: [State]   Likely cause: [Quality / Crawl budget]

URL Blocked by robots.txt / Marked 'noindex'

When to use: A directive is actively keeping the page out of the index.

Check for self-inflicted blocks

These are the most fixable causes because the page is excluded by an explicit rule you control. URL Inspection will name the directive directly.

• URL blocked by robots.txt: Google was disallowed from crawling. Open your robots.txt and find the rule matching [URL path]. Remember that a robots block prevents crawling, not always indexing, but it stops Google from seeing your content.
• URL marked ‘noindex’: the page returns a [noindex] meta robots tag or X-Robots-Tag header. Run the live test in URL Inspection to confirm the directive is still present right now.

Remove or correct the offending rule, then verify with the live test that Google can both crawl the page and that no noindex remains. Watch the order of fixes: if robots.txt blocks a page, Google can't see its noindex tag either. To remove a page from search, allow crawling and keep noindex until it drops out. Once clean, move on to requesting indexing.

Directive found: [robots.txt / noindex]

Canonical & Duplicate Issues

When to use: Google indexed a different URL than the one you submitted.

When Google picks its own canonical

If a page shows "Duplicate, Google chose different canonical than user" or "Alternate page with proper canonical tag," the content is likely indexed, just under another URL.

• Compare canonicals: in URL Inspection, check "User-declared canonical" against "Google-selected canonical." A mismatch is the heart of the issue.
• Find the chosen page: note which URL Google preferred and decide whether that is acceptable or wrong.

If Google's choice is acceptable, no action is needed: the content is covered. If you want the inspected URL to win, send consistent signals: a self-referencing canonical, internal links pointing to the preferred URL, matching sitemap entries, and genuinely distinct content so the pages aren't seen as duplicates. Conflicting signals are the usual reason Google overrides your declaration.

Declared canonical: [URL]   Google-selected: [URL]

Quality & Thin-Content Causes

When to use: The page is crawlable and unique but still not indexed.

Earn the index, don't just request it

When there is no technical block and no canonical conflict, "Crawled - currently not indexed" almost always reflects Google's judgment that the page doesn't add enough value. Treat this as a content problem, not a bug.

• Assess uniqueness: does the page offer something the indexed competitors and your own other pages don't?
• Check depth and intent: thin, templated, or auto-generated pages are common non-index candidates.
• Review internal authority: orphaned pages with no internal links read as low priority.

Improve the page substantively (original detail, clear purpose, and helpful structure) then link to it from related, already-indexed pages to pass relevance and discovery signals. Accept that some pages, like near-empty tag archives or duplicate paginated views, may simply not warrant indexing. Consolidating or removing those can lift the pages that do.

Page value gap: [Notes]

Request Indexing & Validate Fixes

When to use: You've fixed the root cause and want Google to recheck.

Close the loop the right way

Once the underlying issue is resolved, prompt Google to recrawl and confirm the fix held. Do this only after the real cause is fixed: requesting indexing on an unfixed page wastes the request.

1. Run the live test: in URL Inspection, click "Test live URL" to confirm the page is now crawlable, indexable, and free of noindex.
2. Request indexing: click "Request indexing" for the single corrected URL. Avoid repeatedly submitting the same page: it does not speed things up.
3. Validate at scale: in the Page Indexing report, open the affected reason and click "Validate fix" so Google rechecks all URLs in that group.

Google says validation typically takes up to about two weeks, sometimes longer; monitor the status until it reads "Passed." For sitewide fixes, lean on Validate Fix rather than inspecting URLs one at a time.

Fix applied: [Description]   Validation status: [Status]

Diagnosis Worksheet (fill-in)

When to use: One row per URL or URL pattern: exact status, robots, meta robots, canonicals, sitemap, internal links, evidence, fix, owner and validation date.

Indexing diagnosis worksheet

Fill the evidence columns before the fix column. If a row has a fix but no evidence, it's a guess.

Columns

• URL or pattern and page type [product, category, article]
• Status in Search Console: [exact label, e.g. Crawled - currently not indexed]
• robots.txt: [allowed / blocked by rule]
• Meta robots / X-Robots-Tag: [index / noindex, and where it is set]
• Declared canonical and Google-selected canonical [from URL Inspection]
• In sitemap: [yes / no] · Internal links in: [number, from crawl]
• Evidence: [inspection date, live test or indexed version, screenshot file]
• Should it be indexed? [yes / no, and why]
• Fix, owner, validated on [one change, one name, one date]

Evidence rules

• Live test vs indexed version: the live test shows the page now. The indexed version shows what Google saw at its last crawl, with the date. Record which one you used.
• The live test doesn't check everything. Google notes it doesn't test duplicate and canonical conditions, so a passing live test doesn't clear a canonical problem.
• Example lists are capped at 1,000 rows. For big sites, diagnose by pattern (one row per template) rather than chasing every URL.

Status-to-Cause Lookup

When to use: Match each Search Console status to what it usually means, the first thing to check and who normally owns the fix.

Status-to-cause lookup

Labels as they appear in Search Console's Page indexing report, checked October 2026. Use this to pick your first check, not to skip the evidence.

Worked Example (fictional recipe site)

When to use: Four filled-in rows from an invented site, including one page that should stay out of the index and one fix that needed a different owner.

Worked example: a recipe site

Example only. The company, people, URLs and figures are invented to show what a usable, filled-in version looks like.

What the evidence changed

The team assumed the noindex on /collections/ came from the CMS. The page source showed no meta robots tag at all. It was an HTTP header added by a caching plugin, so the fix belonged to hosting, not content. Row 4 needed no fix: internal search pages should stay out of the index.

Next step

Use Get Source Code of Webpage to see the meta robots and canonical a page really serves, and the Redirect Checker for any Page with redirect or Redirect error rows. Run a website audit to find noindex and canonical issues across templates. If the fixes need a technical team, our SEO & GEO services include implementation.