Most people open the index coverage report in Search Console, see a big number of “not indexed” URLs, and either panic or ignore it. Both reactions are wrong. That report isn’t a health score you want to zero out — it’s a verdict, page by page, on whether Google thinks each URL earns a place in the index. Half the “problems” it flags are Google correctly obeying instructions you gave it. The other half are a quality judgment you actually need to argue with. Learning to tell those two apart, fast, is the whole skill.
Where the report lives and what the top number really counts
You’ll find it under Indexing > Pages in Google Search Console (Google renamed the old “Index Coverage” report to “Page indexing,” but everyone still calls it the index coverage report). The chart splits every known URL into two buckets: indexed, and not indexed. Below that sits a list of reasons, each with a URL count and a trend line.
The first move most people skip: filter to “Submitted pages only” or select a specific sitemap. Your unfiltered report includes every URL Google has ever discovered — old parameter URLs, staging leaks, faceted-navigation combinations, URLs from a scraper’s copy of your site. A “not indexed” count of 40,000 is meaningless if 38,000 of those are junk you never wanted indexed. Filtering to your sitemap answers the only question that matters: are the pages I care about getting in?
The three verdicts hiding inside a dozen status labels
Google shows you roughly a dozen status strings, which is why the report feels overwhelming. But every one of them collapses into three verdicts, and the fix depends entirely on which verdict you’re looking at:
- “I obeyed you.” The URL is excluded because a signal on your site told Google to exclude it — a noindex tag, a canonical pointing elsewhere, a robots block, a redirect. Usually correct. Occasionally an accident.
- “I couldn’t.” A technical failure stopped indexing — a server 5xx, a soft 404, a redirect loop. Always worth fixing.
- “I chose not to.” Google crawled the page, understood it, and decided it wasn’t worth indexing. This is a quality verdict, and it’s the one that actually costs you traffic.
Read every status through that lens and the report stops being a wall of jargon. You’re only ever asking: did I cause this, did the server break, or did Google reject the page on merit?
Statuses that mean “working as intended” — leave them alone
A large chunk of your “not indexed” pages belong here, and chasing them is wasted effort:
- Excluded by ‘noindex’ tag — you told it not to index. Fine, unless a template accidentally noindexed a whole section.
- Alternate page with proper canonical tag — Google consolidated a duplicate into its canonical. This is healthy consolidation, not a loss.
- Page with redirect — the URL 301s elsewhere; the destination is what gets indexed.
- Not found (404) and blocked by robots.txt — expected for retired pages and intentionally blocked paths.
The one label in this group that lies to you is “Indexed, though blocked by robots.txt.” It sounds fine because it says “indexed” — but it’s a warning. When you block a URL in robots.txt, Google can’t crawl it, which means it can’t read your noindex tag either. So it may index a bare URL with no useful snippet, pulling title text from anchor links. If you want a page out of the index, use noindex and let Google crawl it; don’t block it and hope.
The statuses that quietly cost you traffic
Two labels deserve most of your attention because they mean Google saw your page and passed:
Discovered — currently not indexed means Google knows the URL exists (usually from your sitemap or an internal link) but hasn’t bothered to crawl it yet. On a small site, a handful is normal. At scale, a growing pile here is a crawl-demand signal: Google isn’t allocating crawl budget to your site because it doesn’t yet trust that new URLs are worth fetching. The fixes are structural — stronger internal links to the stranded pages, a cleaner sitemap, fewer low-value URLs diluting your crawl budget, and demonstrably useful content so Google raises its crawl rate.
Crawled — currently not indexed is the harsher one. Google fetched the page, rendered it, evaluated it, and decided it wasn’t worth a slot. There’s no technical error to fix — it’s a quality verdict. Common triggers: thin or templated content that adds nothing over what already ranks, near-duplicate pages Google folded together, or a page that answers a query worse than the results already on page one. This is where the helpful-content mindset bites: pages that don’t add information gain over the existing top results increasingly just sit in this bucket, uncrawled or unindexed, indefinitely.
The mechanism behind “Crawled — currently not indexed”
It helps to know what’s actually happening. Google’s indexing pipeline is a series of gates: discover the URL, decide it’s worth crawling, crawl and render it, then decide it’s worth storing. “Crawled — currently not indexed” is a failure at that last gate. The page passed the effort test but failed the value test.
The lever you have is information gain — does this page say something the pages already indexed for its topic don’t? A programmatically generated location page that swaps one city name into a template will keep failing this gate no matter how many times you request indexing, because from Google’s side it’s a duplicate of 200 other pages. The fix is never “resubmit.” It’s making the page genuinely differentiated, or consolidating a hundred thin pages into ten strong ones and redirecting the rest. This is exactly the judgment SEO Rocket’s AI article writer bakes in with validation gates — a real word-count floor, section-structure checks, and a repair loop that catches thin drafts before they publish — because a page that can’t clear an editorial bar rarely clears Google’s indexing bar either.
Canonical conflicts: when Google picks the wrong page
Two labels overlap here and confuse everyone. Alternate page with proper canonical is Google agreeing with your canonical tag — good. Duplicate, Google chose different canonical than user is Google overruling you. You declared page A canonical; Google decided page B is the real one and indexed that instead. That happens when your signals contradict each other: your canonical says A, but your internal links and sitemap point at B, so Google trusts the majority vote over the tag.
The fix is signal alignment. Pick the URL you want indexed and make every signal agree — canonical tag, internal links, sitemap entry, and any hreflang cluster all pointing at the same URL. Then use URL Inspection on the affected page to see which canonical Google currently selects, and re-request indexing once the signals are consistent.
A worked example: diagnosing a sudden drop in indexed pages
Say your indexed count falls from 1,200 to 900 over two weeks and traffic follows. Don’t guess — triage the report in order. First, filter to your sitemap so you’re only looking at pages you want indexed. Second, sort the “not indexed” reasons by which one grew. If the spike is in Excluded by noindex tag, a recent deploy almost certainly shipped a noindex on a template — a five-minute code fix, and the biggest single cause of self-inflicted drops. If it’s Crawled — currently not indexed, you have a quality problem that predates the deploy and is now surfacing. If it’s Server error (5xx) or Soft 404, Googlebot hit failures during recrawl and dropped those pages until they respond cleanly again. Confirm your top suspect with URL Inspection on three or four affected URLs — the live test shows exactly what Googlebot sees now, including whether your JavaScript renders or returns an empty shell. Most “why did indexing drop” cases resolve here, because the report already told you which gate failed; you just had to read it in the right order.
What the index coverage report can’t see
The report’s biggest blind spot is the pages Google never discovered. If a URL isn’t linked internally and isn’t in a sitemap, it’s an orphan — and orphans don’t appear as a problem, they simply don’t appear at all. The report can’t flag a gap it doesn’t know exists. So a site can show a clean, healthy report while quietly leaving hundreds of pages uncrawled because nothing links to them.
The only way to catch this is to crawl your own site the way Google does and compare that crawl against what Search Console reports. Pages your crawler finds that Search Console doesn’t know about are your orphans; pages Search Console lists that your crawler can’t reach are your internal-linking failures. SEO Rocket’s site audit runs a real crawler for exactly this reconciliation — surfacing orphaned URLs, broken internal links, and indexation gaps the coverage report structurally cannot show you, so you’re auditing the whole site, not just the slice Google chose to tell you about.
A monthly triage routine that scales
You don’t need to live in this report. A disciplined monthly pass catches almost everything:
- Filter to your sitemap and record the indexed count as a trend line, not a snapshot — the number jitters day to day.
- Scan for any reason that grew since last month. A rising “not indexed” bucket is your only real alarm; a stable one is noise.
- Triage by verdict — obeyed-you issues get a config fix, couldn’t issues get a technical fix, chose-not-to issues get a content decision.
- Validate fixes with URL Inspection and the “Validate Fix” button, then let Google reprocess over the following days.
- Reconcile against a full crawl quarterly to catch orphans the report can’t see.
This isn’t guesswork. The playbook behind it has been proven across 1,000,000+ ranking pages, and the pattern holds every time: the sites that stay indexed are the ones that treat coverage as a monthly diagnostic, not a fire alarm they only check after traffic has already fallen.
Honest caveats: why the numbers never quite line up
Trust the report, but know its limits. It samples up to 1,000 example URLs per issue, so on a large site the examples are a sample, not the full list. The data lags several days, which means a fix you shipped this morning won’t reflect until later in the week — resist the urge to re-validate hourly. And the indexed count will disagree with a site: search and your sitemap total; those numbers measure slightly different things and never perfectly agree. Chasing exact reconciliation is a waste — watch the trend and the growing buckets instead.
Frequently asked questions
Why is my page “Crawled — currently not indexed”?
Google fetched and evaluated the page but judged it not worth indexing — almost always a quality or duplication verdict, not a technical bug. Resubmitting won’t help. Make the page genuinely more useful than what already ranks, or consolidate it with similar thin pages, then request indexing once it’s substantively different.
How long does it take for a fixed page to get indexed?
After you fix the issue and click “Validate Fix,” Google reprocesses over days to a few weeks depending on your site’s crawl rate. Report data also lags several days, so give it a week before concluding a fix didn’t work. Higher-authority sites with strong crawl demand reprocess faster.
Should I worry about a high “not indexed” count?
Not by itself. Filter to your submitted sitemap first — if the pages you actually care about are indexed, a large “not indexed” total made up of parameters, redirects, and duplicates is normal and healthy. The alarm is a rising count of sitemap pages that won’t index, not a big raw number.
What’s the difference between “Discovered” and “Crawled” not indexed?
“Discovered — currently not indexed” means Google knows the URL but hasn’t crawled it yet, usually a crawl-budget or internal-linking signal. “Crawled — currently not indexed” means Google already fetched and rejected it, which is a content-quality signal. Different diagnosis, different fix.
The bottom line
The index coverage report rewards people who read it as a verdict, not a scoreboard. Filter to the pages you care about, sort every status into obeyed-you, couldn’t, or chose-not-to, and spend your effort only on the last two. Fix the technical failures fast, argue with the quality verdicts by making pages genuinely better, and reconcile against a full crawl to catch the orphans Google never mentions. Do that monthly and indexing stops being a mystery you diagnose in a panic — it becomes a signal you read before anyone notices a problem.
