What "Crawled — Currently Not Indexed" Actually Tells You

The Page indexing report in Search Console reads like a list of diagnoses. It isn't. Each label records where in Google's pipeline a URL stopped, and almost nothing about why. "Crawled — currently not indexed" and "Discovered — currently not indexed" sit one word apart in the UI and describe failures at completely different stages, with completely different fixes.

The second problem is that the report is a snapshot count, recomputed over time, with a capped sample of example URLs. A bar that shrinks is not evidence that your pages got indexed. It's equally consistent with those URLs moving into a different not-indexed bucket, or with Google re-evaluating the set entirely. If you want to know whether a change worked, you have to track the same URLs yourself.

Which pipeline stage does each state correspond to?

Google's crawl-and-index flow has a rough sequence: discovery → scheduling → fetch → parse/render → canonicalization → index selection. Every coverage state is a checkpoint along it.

The useful split is deterministic versus discretionary. noindex, robots blocks, and canonical-with-a-correct-target are rule-following outcomes; you can predict them. "Discovered" and "Crawled — currently not indexed" are discretionary. Google has documented that it does not index every page it knows about and gives no per-URL reason for these two states. Treat any tool that claims to tell you the reason as inference, not documentation.

Why is "Discovered" a different problem from "Crawled"?

Discovered means Googlebot never fetched the URL. Whatever is on the page is irrelevant, because nobody read it. Google has documented that crawl scheduling is bounded by what your server can handle and by crawl demand — popularity and staleness signals. So the causes cluster on the infrastructure and site-architecture side: slow or error-prone responses under load, a URL space that's far larger than the value it contains (facets, calendars, session parameters), or pages sitting at the end of a weak discovery path.

A large and growing "Discovered" bucket on a site with millions of generated URLs is not a mystery. It's Google declining to spend fetches on a set it predicts is low value. Improving the individual pages does nothing until the set shrinks or the server gets faster.

Crawled — currently not indexed means Google fetched it, parsed it, and selection said no for now. "For now" is real: URLs do move out of this state without any change, and they move into it after previously being indexed. The causes here are page- and cluster-level: the content substantially overlaps other pages on your site or elsewhere, it's thin relative to its template, or nothing on the site points at it with any weight.

Why can't you just watch the chart go down?

Three measurement properties of the report break naive before/after reading:

1. It's a state count, not a cohort. URLs enter and leave. A 40% drop in "Crawled — currently not indexed" can mean 40% got indexed, or that a tranche moved to "Duplicate", or that you removed them from sitemaps and Google stopped tracking them as candidates.
2. Examples are sampled and capped. You get example URLs per issue, not the full membership list. You cannot reconstruct the set, so you cannot diff the set.
3. It lags and it's recomputed. Comparing a data point from three weeks ago to today mixes pipeline latency with real change.

None of this makes the report useless. It's a good prioritisation signal — it tells you which stage is bleeding. It's a bad experiment readout.

How do you build a cohort you can actually measure?

Define the URL set yourself, then poll it. The URL Inspection API is the instrument. Google documents a quota of 2,000 queries per day and 600 per minute per property, which means you sample rather than crawl your whole index status.

Stratify the sample by template (product, category, editorial, tag page), 100–300 URLs per stratum, drawn from your own crawl or sitemaps — not from the report's examples, which are already biased toward the state you're studying. Then record, weekly:

indexStatusResult.verdict            # PASS / NEUTRAL / FAIL
indexStatusResult.coverageState      # "Submitted and indexed", "Crawled - currently not indexed", ...
indexStatusResult.lastCrawlTime
indexStatusResult.googleCanonical
indexStatusResult.userCanonical
indexStatusResult.pageFetchState
indexStatusResult.robotsTxtState

The pair you should not skip is googleCanonical versus userCanonical. A large share of "why isn't this indexed" investigations end at the discovery that the URL is represented in the index — under a different canonical you chose or Google chose for you. That is a content-differentiation problem, not an indexing problem, and the remedies are different.

With weekly snapshots you can compute a transition matrix per template: of the URLs in state X last week, what fraction are in state Y now. That is the readout the UI can't give you. Baseline it for three or four weeks before you ship anything, because the background churn rate is non-trivial and you need to know it to recognise a real effect.

What moves a URL out of "Crawled — currently not indexed"?

Honestly: nothing is guaranteed, and the evidence here is weaker than practitioners usually admit. What follows is reasoning from the mechanism, not documented cause and effect.

• Reduce the candidate set. Consolidating or removing near-duplicate pages raises the average predicted value of what remains. This is the intervention with the clearest mechanism, because selection is comparative.
• Add internal links from pages Google crawls often. Not "add links somewhere" — link from URLs whose lastCrawlTime is recent. Your log files or the API tell you which those are.
• Make the page distinct at the text level, not the template level. If two URLs differ only in a heading and a price, they are competing for one slot.
• Fix the server first if the bucket is "Discovered". Selection-side work on unfetched URLs is wasted effort.
• Request indexing sparingly. The Inspect tool's request queue can get a URL fetched; it does not force selection, and it doesn't scale past a handful of URLs.

What to do this week

1. Split your not-indexed volume into discretionary (Discovered, Crawled) and deterministic (noindex, robots, canonical). Only the discretionary half is a decision you can argue with.
2. Pull a stratified sample of 500–1,000 URLs from your own crawl, not from the report's examples.
3. Run the URL Inspection API against it weekly and store the full indexStatusResult, keyed by URL and date.
4. Before shipping a fix, measure four weeks of baseline transitions so you know the natural churn rate.
5. Check googleCanonical before you diagnose anything. A meaningful share of "not indexed" URLs are indexed under another address.
6. If "Discovered" dominates, stop working on content and go look at response times and URL-space size instead.