The Index Coverage Report: Every Status and What It Means
Google renamed this screen the Page indexing report some time ago, but the name that stuck is the older one: the index coverage report. Whatever you call it, it is the one place where Google states, in its own words, what it did with your pages and why. This guide walks through every status the index coverage report can show, what each one actually means, and which ones deserve attention this week rather than someday.
One framing before the list. The report splits your known URLs into two buckets, indexed and not indexed, then explains the second bucket with reasons. Not every reason is a problem. Several describe pages you never wanted indexed, and the report counts them alongside genuine failures. Reading it well is mostly the skill of telling those apart.
How the report is organised
You will find it in Search Console under Indexing, then Pages. The top chart tracks the two buckets over time. Below it, a table lists every “why pages aren’t indexed” reason, sorted by how many URLs it affects. Clicking a reason shows sample URLs, and once you believe you have fixed the cause, a Validate Fix button asks Google to recheck the affected set. Google’s documentation for the report describes each reason briefly; what follows is the longer version, grouped by what the status implies about intent.
Indexed: the bucket you want, mostly
Indexed means Google crawled the page, judged it worth keeping, and can return it in results. Two cautions. First, indexed is not the same as ranking; the report says nothing about position. Second, the indexed bucket deserves an occasional scan of its own, because it can contain URLs you would rather not have indexed: parameter variants, staging paths, tag archives. An unwanted page in the index is a canonical or noindex decision waiting to be made.
Statuses that mean “you told Google not to”
Excluded by ‘noindex’ tag. The page carries a noindex directive and Google honoured it. Perfect for login pages and internal search results. A problem only when the tag is a leftover, commonly from a development environment that shipped to production with its safety settings intact.
Blocked by robots.txt. Google was told not to crawl the URL. The subtlety worth knowing: robots.txt controls crawling, not indexing, so a blocked URL can still appear in the index without its content if enough links point at it. If you want a page out of the index, noindex is the tool, and the page must be crawlable for Google to see the tag.
Blocked due to unauthorized request (401) or access forbidden (403). The server demanded credentials or refused the request. Expected for genuinely private areas. If public pages show here, your server or firewall is treating Googlebot as an intruder.
Statuses about duplicates and canonicals
Alternate page with proper canonical tag. The page points at another URL as the preferred version, and Google agreed. This is the system working. No action.
Duplicate without user-selected canonical. Google found near-identical pages and you expressed no preference, so it chose one for you. The fix is to declare canonicals yourself rather than leaving the choice to inference.
Duplicate, Google chose different canonical than user. You declared a preference and Google overruled it, usually because signals such as internal links or redirects point the other way. The fix is to make every signal agree with the canonical you declared.
Page with redirect. The URL redirects, so the destination gets indexed instead. Normal after a migration. Worth investigating only if the redirect is one you did not put there.
Statuses that are plain errors
Not found (404). The page is gone. Fine if it is meant to be gone; a redirect is better if a replacement exists.
Soft 404. The page returned a success code but looked like an error or empty page to Google, so it was treated as missing. These hide well because the page loads normally in a browser.
Server error (5xx). The server failed when Googlebot called. Intermittent errors here throttle crawling across the whole site, which makes this the most urgent status in the report.
Redirect error. A loop, an overly long chain, or a redirect to a bad URL. Google gave up before reaching a destination.
The waiting room: discovered and crawled
Two statuses describe pages with nothing technically wrong, and they are usually the largest and most frustrating rows in the table.
Discovered - currently not indexed means Google knows the URL exists but has not crawled it yet, a queueing decision on Google’s side. Crawled - currently not indexed is more pointed: Google fetched the page, read it, and declined to index it for now, which is a quality judgement rather than a backlog. The diagnosis paths differ, and we have written them up separately: causes and fixes for Discovered - currently not indexed and what Crawled - currently not indexed actually means.
What the report does not tell you
The index coverage report is an aggregate view that updates on Google’s schedule, not yours. It cannot tell you whether the page you published on Tuesday was indexed by Thursday; by the time a URL appears in the counts, days may have passed. The URL Inspection tool answers for one URL at a time, which does not scale past a handful. This is the gap AIndexify covers: each submitted URL is checked against live Google results on a fixed schedule and reported as two separate events, submitted and then indexed with the date found, with no Search Console connection required. The report tells you the shape of the problem; per-URL checks tell you what happened to the pages you care about this week.
A triage order that works
Work the table in this order: server and redirect errors first, since they degrade crawling everywhere. Then unintentional noindex and robots.txt blocks, because those are self-inflicted and fully within your control. Then duplicates, by declaring canonicals deliberately. Then soft 404s. Only after that is it worth staring at the waiting-room statuses, which respond to content and site quality rather than quick fixes. For the wider mechanics behind all of this, the guide to Google indexing connects each status to the pipeline that produces it.
The report tells you what Google decided, eventually and in aggregate. If you want the same question answered per URL, on dates you can point to, submit your URLs and see where your pages actually stand.