What Is Index Coverage? SEO Glossary

Index coverage refers to the status of your website's pages within Google's index. It tells you which of your pages Google has successfully indexed, which ones it has not indexed, and why. The report in Google Search Console that monitors this is now called the Page indexing report (Google renamed the former "Index Coverage report" and simplified its status model). According to Google Search Central, indexing is when Google finds (crawls) a page, processes its content, and stores it in the Google index, where the page can become eligible to appear in Search and other Google surfaces. The Page indexing report gives a detailed breakdown of how many URLs on your site have been crawled and indexed, plus the reasons any URL was not indexed.

Understanding index coverage is essential because a page that is not indexed cannot appear in search results. You could have the best content in the world, but if Google has not added it to its index, no one will find it through organic search.

Why Index Coverage Matters for SEO

Your pages can only rank and drive organic traffic if they are indexed. Index coverage gives you visibility into the gap between the pages you want indexed and the pages Google has actually indexed. On a healthy site, these numbers should be closely aligned. When they diverge, something is wrong.

Index coverage issues directly impact revenue. If product pages are not indexed, those products are invisible in search. If new blog posts are not getting indexed, your content strategy is not producing results. If important landing pages are excluded, you are losing potential conversions every day.

Beyond individual page issues, index coverage trends reveal broader site health problems. A sudden drop in indexed pages might indicate a robots.txt misconfiguration, a server issue, or an accidental noindex deployment. A gradual decline might signal thin content issues, crawl budget problems, or growing duplicate content.

In its current form the Page indexing report sorts every known URL into two top-level groups, Indexed and Not indexed, and then lists the specific reason behind each "Not indexed" URL. This was a change from the older Index Coverage model, which used four buckets named Valid, Valid with warnings, Error, and Excluded. Either way, the per-reason breakdown is what makes this one of the most actionable reports in SEO, because each reason maps to a concrete fix.

How Index Coverage Works

When Google discovers a URL on your site, through crawling, sitemaps, or external links, it goes through a process to decide whether to index it:

1. Discovery: Google finds the URL through your sitemap, internal links, external links, or previous crawl data.

2. Crawl: Googlebot requests the URL and downloads the response. The HTTP status code, response headers, and page content are all recorded.

3. Processing: Google analyzes the page content, checks for duplicate content, evaluates canonical tags, and assesses quality signals.

4. Decision: Google decides whether to add the page to its index, exclude it for a specific reason, or flag it with a warning.

The Page indexing report groups URLs by their final status:

Indexed: The page is in Google's index and can appear in search results. This is the status you want for all your important pages.

Not indexed: Google did not index the page. Every URL here carries a reason string straight from Google Search Central. The exact reasons Google documents include:

• "Crawled - currently not indexed" (Google saw the content but chose not to index it yet)
• "Discovered - currently not indexed" (Google knows about the URL but has not crawled it yet)
• "Duplicate without user-selected canonical" (Google picked a canonical version it prefers)
• "Duplicate, Google chose different canonical than user" (you declared a canonical but Google overrode it)
• "Alternate page with proper canonical tag" (this page correctly points at a canonical, so the canonical is indexed instead)
• "URL marked 'noindex'" (you explicitly told Google not to index it)
• "URL blocked by robots.txt" (Google could not access the page)
• "Not found (404)", "Soft 404", "Server error (5xx)", "Redirect error", and several blocked-access reasons such as "Blocked due to unauthorized request (401)" and "Blocked due to access forbidden (403)"

Some of these reasons are genuine errors that block indexing, while others are non-error outcomes that are working exactly as intended, such as a canonical alternate or a page you deliberately marked noindex. Google no longer surfaces a separate "Valid with warnings" bucket the way the old Index Coverage report did.

Best Practices for Index Coverage

Review the Page indexing report weekly. Set a regular schedule to check for new errors, unexpected "Not indexed" reasons, and trend changes. Catching issues early prevents them from snowballing.

Prioritize the "Crawled - currently not indexed" category. These are pages Google saw but chose not to index. This often indicates thin content, low quality, or duplicate content issues. Improving the content or consolidating these pages can recover lost indexing.

Investigate sudden drops immediately. If your indexed page count drops significantly, check for recent technical changes: new robots.txt rules, accidental noindex tags, server issues, or redirect problems.

Submit an accurate XML sitemap. Your sitemap should include only the pages you want indexed, all returning 200 status codes. Do not include redirected, noindexed, or blocked URLs. Google uses your sitemap as a signal of which pages matter to you.

Use the URL Inspection tool for specific pages. When a critical page is not indexed, inspect it individually to see exactly what Google sees, including the rendered HTML, detected canonical URL, and any indexing issues.

Separate intentional exclusions from problems. Not every excluded page is a problem. Paginated pages, tag archives, search result pages, and admin URLs are often intentionally excluded. Focus your attention on pages that should be indexed but are not.

Common Mistakes

The most common mistake is ignoring the Page indexing report entirely. Many site owners never check it and remain unaware that significant portions of their site are not indexed. This is especially damaging on large sites where thousands of pages might be silently left out of the index.

Submitting a sitemap full of non-indexable URLs confuses the signals you send to Google. If your sitemap contains 10,000 URLs but only 3,000 are indexed, Google may question the quality of your sitemap and crawl it less frequently.

Not investigating "Crawled - currently not indexed" pages is a major missed opportunity. These pages represent content Google has seen but rejected. Often, adding more depth, uniqueness, or internal links can push these pages into the index.

Panicking about normal exclusions wastes time. Pages excluded because of user-selected canonical, noindex tags you intentionally set, or alternate page with proper canonical tag are working as expected. Focus on genuine problems.

Deploying site-wide changes without monitoring index coverage afterward is risky. A redesign, migration, CMS update, or CDN change can introduce indexing issues that only appear in the Page indexing report days later.

In Practice

Say a new blog post has been live for two weeks but is not bringing in any organic traffic. You open Search Console, run the URL Inspection tool on it, and the result reads:

URL is not on Google
Page indexing
  Discovery: Sitemaps -> https://example.com/sitemap.xml
  Crawl: Crawled on May 18, 2026
  Indexing: URL is not indexed: Crawled - currently not indexed
  Google-selected canonical: https://example.com/blog/old-similar-post

That single block tells the whole story. Google reached the page through your sitemap, crawled it successfully, but then chose a different URL as the canonical, which means it judged your new post to be a near-duplicate of an older one. The fix is not technical. You differentiate the content (new angle, original data, distinct title and headings), add internal links pointing at the new URL so its importance signal rises, then click "Request indexing" in the same tool to push it back into the queue. Compare that with a server-side failure, where the same tool would instead report an error reason such as the following:

HTTP/1.1 503 Service Unavailable

A 5xx response surfaces under "Server error (5xx)" rather than "Crawled - currently not indexed", and the fix lives in your hosting or application layer, not your content. Reading the exact reason string is what tells you which of those two very different problems you actually have.

Related Terms

• What Is Indexing? covers the underlying process that produces a page's coverage status.
• What Is Crawling? explains the discovery and fetch step that has to happen before a page can be indexed.
• What Is a Noindex Tag? details the directive behind the "URL marked 'noindex'" reason.
• What Is robots.txt? explains the file behind the "URL blocked by robots.txt" reason.
• What Are Canonical Tags? unpacks the duplicate and alternate-canonical reasons you will see in the report.
• What Is Google Search Console? is the tool that hosts the Page indexing report itself.

Sources

• Page indexing report, Search Console Help (checked 2026-05-30)
• URL Inspection tool, Search Console Help (checked 2026-05-30)
• Build and submit a sitemap, Google Search Central (checked 2026-05-30)
• Googlebot, Google Search Central (checked 2026-05-30)

Conclusion

Index coverage is your window into how Google processes and stores your website's pages. Monitoring it regularly reveals whether your content is actually reachable through search, identifies technical problems before they impact traffic, and shows you where content quality improvements can unlock new indexing. Make the Page indexing report in Google Search Console a regular part of your SEO workflow, investigate anomalies quickly, and ensure every page you want ranking is actually making it into Google's index.