Reference guide · search-console · Published 2026-08-15 · 4 min read
Search Console Pages report, the crawl and index health check
Search Console Pages report: indexed versus not-indexed buckets, common reasons, and turning page-level causes into site-wide fixes.
- ·Why many not indexed
- ·Read the reason, not the count
- ·Turn rows into fixes
What the Pages report shows
The Pages report (formerly Index Coverage) is the site-wide counterpart to URL inspection. It lists every URL Google knows about for the property and buckets each one into indexed or not indexed, with the reason.
The two headline buckets are:
- Indexed: pages Google evaluated and stored in the index.
- Not indexed: everything else, with a reason such as Crawled currently not indexed, Discovered currently not indexed, Page with redirect, Duplicate without user-selected canonical, Page with noindex, 404, or Blocked by robots.txt. (Google merged the former Excluded and Error groups into the single Not indexed bucket, so what older posts call "Excluded" is now grouped there.)
Read the count, then the ratio
The raw counts matter less than the ratio. A site with 12,000 pages and 9,000 indexed is healthy if the not-indexed tail is the low-value tail: paginated archives, filtered faceted-URLs, thank-you pages, or content no longer meant to rank. The same 3,000 not-indexed is a problem when the not-indexed set includes your commercial pages.
So the workflow is always the same:
- Open the Pages report and group by reason.
- Identify which reason owns the biggest share.
- Open that reason and look at the URL list: sample the URLs, not just the count.
- Decide on a batch fix in the SSOT, then re-fetch and inspect.
The common reasons in plain words
| Reason | What it means to do |
|---|---|
| Discovered now not indexed | Google knows the URL (often via sitemap) but has not crawled and indexed it yet, usually a priority and volume issue. Fixes: value, links, less junk to crawl |
| Currently not indexed | Google crawled and decided against indexing. Almost always a quality or standalone-value problem. Improve the page or consolidate it |
| Duplicate without user-selected canonical | Multiple URLs resolve to the same content and Google picked one. Fix: canonical, redirects or distinct content |
| Duplicate, Google-selected different canonical | Same, but Google's choice surprised you. Fix the canonical signalling and internal links first. |
| Page with redirect | Google follows a 301 and indexes the target. Only matters if too many or wrong |
| 404 or soft-404 | The page returns a 404 status or a "looks like 404" page. Confirm the URL should be gone |
| Blocked by robots.txt | Google never fetched the page. Read robots.txt before fixing |
| noindex | The page has a meta robots noindex or X-Robots-Tag. Read noindex before fixing |
The reason column is a hint, not a verdict
"Discovered not indexed" is a state, not a diagnosis. About half its entries are the natural crawl queue for a large site. The report's own context line says the same URL was not crawled significantly before, which is the operative part: Google crawled less of your site because crawling resources are bounded. Fixes therefore target site architecture ("make fewer, better pages") and crawl waste, which the crawl budget guide covers.
Similarly "Currently not indexed" is normally a quality decision. The URL inspection live test cannot prove a quality reason, because there is no HTTP header to inspect. So the correct reaction is to improve the content and the page's link authority, then wait a few weeks before re-requesting. Requesting indexing repeatedly over a thin page will not override a quality decision.
Turning rows into fixes
A staged fix list:
- Export or screenshot each reason group.
- Sort by the number of URLs, not alphabetically.
- Attack the biggest reason that is actionable. For a canonical conflict this is a redirect change; for a 404 tail it is a redirect map; for a noindex tail it is a template change.
- Re-validate with the URL inspection live test on a few pages, then wait for the report to catch up, because the report updates on crawls.
The report is the surface; the deeper diagnostics belong in the indexing analysis workflow, and the timing of re-requests in request indexing.