Index coverage is the measure of which URLs of a website a search engine has discovered, crawled and stored in its index, and which it has left out, together with the reason for each outcome. In SEO and indexing work, the term refers both to the underlying state of a site in the index and to the diagnostic reports that expose it, most prominently the page indexing report in Google Search Console, which earlier carried the name Index Coverage.
Coverage matters because a page that is not indexed cannot rank for any query, no matter how good its content or links are. Analyzing coverage therefore answers a basic question before any ranking work begins: does the search engine hold the pages that the site wants to be found, and does it hold pages that should never appear in results?
How index coverage is determined
Index coverage is the result of a pipeline with several gates, and a URL can stop at any of them. A search engine first discovers a URL through links, sitemaps or redirects, then decides whether and when to crawl it, renders the fetched content, evaluates indexing signals such as robots meta tags and canonical hints, and finally decides whether the page is worth storing at all.
The last gate is often misunderstood. Being crawlable and technically valid does not oblige a search engine to index a page; it applies a quality and duplication threshold, and pages judged thin, redundant or low in value may be crawled repeatedly yet never stored. Coverage is therefore a mix of technical eligibility and editorial selection by the engine.
The table below shows the main stages a URL passes through and what typically stops it at each stage.
| Stage | What happens | Typical blocker |
|---|---|---|
| Discovery | URL found through links, sitemaps or redirects | Orphan page with no internal links |
| Crawling | Crawler requests the URL and receives a response | Disallow rule in robots.txt, server errors |
| Rendering | HTML and scripts are processed into final content | Content injected only after failed scripts |
| Indexing decision | Signals and content quality are evaluated | Noindex, canonical to another URL, thin content |
| Serving | Indexed page becomes eligible for results | Manual action or legal removal |
Coverage statuses and what they mean
Coverage reports group every known URL into indexed and not indexed, and attach a reason to each excluded URL. Reading those reasons correctly is the core skill, because many exclusions are intended and healthy, while a few indicate real problems that cost traffic.
The following statuses appear most often in practice; the wording follows the common Google Search Console labels, and other engines use similar categories in their webmaster tools.
| Status | Meaning | Usually a problem |
|---|---|---|
| Indexed | Stored and eligible to appear in results | No |
| Excluded by noindex | Page carries a noindex directive | Only if the page should rank |
| Alternate page with proper canonical | Duplicate correctly points to its canonical URL | No |
| Duplicate, Google chose different canonical | Engine ignored the declared canonical | Often yes |
| Crawled, currently not indexed | Fetched but not judged worth storing | Yes for important pages |
| Discovered, currently not indexed | Known but not yet crawled | Yes if it persists for weeks |
| Not found (404) | URL returns a missing-page status | Only if linked internally |
| Blocked by robots.txt | Crawling is disallowed | Only if the page should rank |
Two statuses deserve particular attention. Crawled, currently not indexed usually signals a content quality or duplication issue rather than a technical fault. Discovered, currently not indexed usually points to crawl prioritization, for example a large site with weak internal linking or a server that slows down under crawler load.
Index coverage compared with related indexing concepts
Index coverage is the site-level outcome, while neighboring indexing concepts describe the individual mechanisms that shape it. Indexing itself is the process of storing a page; noindex, canonical URL and duplicate content are the controls and conditions that push URLs in or out of the index.
| Concept | Scope | Relation to coverage |
|---|---|---|
| Indexing | Process for a single URL | Coverage is the aggregate result of indexing |
| Noindex | Directive on a page or header | Deliberately removes URLs from coverage |
| Canonical URL | Hint about the preferred version | Consolidates duplicates into one indexed URL |
| Duplicate content | Condition across several URLs | Main cause of excluded duplicate statuses |
| Crawl budget | Crawling capacity and demand | Limits how fast new URLs reach the index |
A practical consequence follows from this distinction: coverage problems are diagnosed at the report level but fixed at the mechanism level, by changing internal links, directives, canonical tags or the content itself.
How to measure and improve index coverage
Useful coverage analysis starts from the set of URLs the site wants indexed, usually the XML sitemap, and compares it with what the engine actually holds. The goal is not the highest possible number of indexed URLs but a close match between intended and indexed pages.
- Submit clean XML sitemaps that contain only canonical, indexable URLs returning status 200.
- Segment sitemaps by template or section so coverage per page type becomes visible.
- Use the URL inspection tool for individual pages to see the last crawl, the chosen canonical and the rendered HTML.
- Cross-check with server log files to confirm whether crawlers actually request the affected URLs.
- Track coverage over time; a sudden drop in indexed pages after a release usually points to a template-wide directive or canonical error.
The next table maps frequent coverage symptoms to their likely causes and the fixes that usually work.
| Symptom | Likely cause | Recommended fix |
|---|---|---|
| Many product pages crawled but not indexed | Thin or near-identical descriptions | Add unique content or consolidate variants |
| New articles stay discovered but not crawled | Weak internal linking, slow server | Link from strong hubs, improve response times |
| Sitemap URLs reported as noindex | Conflicting template settings | Remove noindex or drop URLs from the sitemap |
| Engine selects a different canonical | Mixed signals from links and redirects | Align internal links, canonicals and redirects |
| Indexed count far above sitemap count | Parameter and filter URLs being indexed | Canonicalize or noindex facet combinations |
Common mistakes when interpreting coverage
The most frequent error is treating every excluded URL as a defect. Redirected URLs, alternates with correct canonicals and deliberately noindexed pages are exactly where they should be, and chasing them wastes effort that should go to genuinely missing important pages.
- Blocking with robots.txt to deindex: a disallowed URL cannot be crawled, so a noindex on it is never seen and the URL can stay indexed without content.
- Requesting indexing repeatedly: manual requests do not override a quality decision and have a daily limit.
- Ignoring reporting delay: coverage reports typically lag reality by several days, so changes need time before they show.
- Inflating the sitemap: listing redirected, noindexed or duplicate URLs sends contradictory signals and blurs the report.
Coverage data is also sampled and simplified; example URLs in a report are not a complete list. For large sites, conclusions should rest on segmented sitemaps and log analysis rather than on the example rows alone.
A plain-language summary
A search engine works a little like a huge library catalog. Before a book can be lent out, it has to be listed in the catalog. Index coverage tells a website owner which of their pages made it into that catalog, which did not, and why.
Some pages are left out on purpose, such as login screens or duplicate versions of the same product. Others are left out by mistake, and those are the ones worth fixing. If a page is not in the index, nobody can find it through search, so checking coverage is one of the first steps in any search optimization work.
An example from practice
An online furniture retailer with about 12,000 product URLs in its sitemap notices that organic traffic to new products has stalled. The page indexing report shows only around 7,500 of the sitemap URLs as indexed, with roughly 3,000 marked crawled, currently not indexed and most of the rest discovered but not yet crawled.
Inspection reveals that color and size variants each have their own URL with an almost identical description. The team merges variants onto one canonical product page, writes distinct descriptions for the top sellers and adds links from category hubs to new arrivals. Over the following two months, indexed sitemap URLs rise to about 9,800, the excluded duplicates now appear as alternates with a proper canonical, and new products start to receive search impressions within days of launch.