Google Search Console Coverage Report Guide
The index coverage report (formerly Index Coverage, now presented as the "Page Indexing" report) is the core report in Google Search Console for understanding which pages are indexed, which are not, and why. It helps you spot indexing anomalies, locate technical issues, and verify fixes. This guide follows the official Google documentation.
Many site owners open this report for the first time and panic at tens of thousands of "not indexed" entries — but a large share of those are perfectly normal: tag pages, filter-parameter pages, and the like were never meant to enter the index. What actually matters are pages that should be indexed but aren't. Understanding the status categories and the "Source" column is the first step in telling "needs action" from "leave it alone".
Report Structure and Status
The summary page shows charts and counts for indexed and not-indexed (but requested) pages, plus a "Why pages aren't indexed" table grouped by reason. Page status falls into two main categories:
- Indexed: the URL is successfully in the index.
- Not indexed: may be due to indexing errors or legitimate reasons (such as robots.txt blocking or duplicate pages). The "Source" column tells you whether the issue comes from Google or the site — usually only issues marked "Site" require action from you.
The "Source" column is the key detail: Google-side issues (like "Crawled - currently not indexed") aren't something you can fix directly, and resubmitting just wastes crawl quota. Site-side issues (5xx, 404, noindex) are where you actually roll up your sleeves.
Common "Not Indexed" Reasons
| Reason | Meaning | Recommendation |
|---|---|---|
| Server error (5xx) | Server returned a 5xx error | Fix server/timeout issues |
| Redirect error | Too long redirect chains, loops | Debug with Lighthouse |
| Blocked by robots.txt | Page blocked from crawling | Remove the block or use noindex |
| Page with noindex | Page blocked by noindex | Remove the tag if you want it indexed |
| Soft 404 | Readable "not found" instead of 404 | Return a real 404 status |
| Not found (404) | Page returned 404 | Delete or 301 redirect |
| Crawled - currently not indexed | Crawled but not yet indexed | No need to resubmit |
| Discovered - currently not indexed | Discovered but not crawled (often load-related) | Improve site performance |
| Duplicate without user-selected canonical | No canonical specified | Add canonical tags |
| Alternate page with proper canonical | Correctly points to the canonical | No action needed |
The "Duplicate" states relate directly to canonical tags and duplicate content management; "Blocked by robots.txt" relates to robots.txt configuration.
A Real Triage Session
Say a news site has 5,000 not-indexed URLs in the report. Here's how a practical pass goes:
- Group by reason and look at the biggest buckets first. The largest turns out to be 4,000 URLs under "Blocked by robots.txt" — checking the file reveals a site rework accidentally wrote the wrong crawl rule for the whole
/news/directory. Fixing that one line resolves the bulk. - The next 800 are "Server error (5xx)", all clustered in one CDN origin-timeout window tied to a server scaling event. Once confirmed recovered, request re-validation.
- The remaining 200 are "Discovered - currently not indexed" — all low-quality auto-generated pagination pages that don't need indexing anyway, so adding noindex avoids wasting crawl quota.
Going from "raw numbers" to "root cause" took an afternoon. That's the value of grouping by reason: don't eyeball URLs one by one; attack the big buckets first.
Warnings and "Improve Page Experience"
The report also lists warnings (such as "Indexed, though blocked by robots.txt" or "Indexed, though not specified in sitemaps") and experience improvement suggestions. These don't prevent indexing but reduce Google's ability to understand pages. Crawl statistics and Core Web Vitals metrics can be observed together here.
"Indexed, though blocked by robots.txt" means your indexing status and crawl rules are out of sync — typically you tightened a rule and already-indexed pages haven't been recrawled yet to confirm. The status resolves itself after the next recrawl, usually without manual intervention.
Verifying Fixes
After fixing a category of issues, click "Validate fix" on the issue detail page and Google will recrawl the affected pages to confirm. It's faster to first submit a sitemap containing only important pages, filter the report by it, then request validation. For broader context see the website indexation guide, and for overall GSC usage see the Google Search Console tutorial.
Frequently Asked Questions
- How often does the report update? Data is aggregated daily, and crawling/indexing is a continuous process — fixes don't take effect instantly. Watch the trend over a few days.
- Should I resubmit "Crawled - currently not indexed"? No. It usually reflects crawl budget or quality thresholds; resubmitting just wastes quota.
- Page counts don't match the sitemap? Trust the report. Export it and compare against the sitemap, then remove invalid or duplicate entries.
- Do all 404s need action? Only 404s with external links or user entry points deserve a 301 or restoration; pure internal dead links can just be deleted.
Source: https://support.google.com/webmasters/answer/7440203
Reference: https://developers.google.com/search/docs/crawling-indexing/googlebot (Google crawling & indexing official docs)