Search Console Coverage Report (Page Indexing)

Short answer: The Search Console Coverage report is the old name for what Google now calls the Page indexing report (Indexing, then Pages). It shows how many of your URLs Google has indexed, lists the reasons other URLs are not indexed, such as noindex, redirects, 404s, duplicates or “Crawled, currently not indexed”, and lets you validate fixes. Not every non-indexed URL is a problem; what matters is whether your important pages are indexed.

1,000 rowsthe most example URLs the report lists for any one reasonSearch Console Help

~2 weekshow long Google says validation of a fix typically takes, sometimes longerSearch Console Help

90 daysan issue drops off the table after ninety days without recurringSearch Console Help

This guide is for site owners, developers and SEOs who open Search Console, see a large grey “Not indexed” number and are not sure whether to worry. I will explain what the report shows, what each reason means in plain language, which ones need fixing and which are expected, and the order I work through them when I audit a site. A triage table and a worked example are included so you can apply it to your own property today.

Coverage report vs Page indexing report: what changed

Older guides talk about the Index Coverage report with four tabs: Error, Valid with warnings, Valid and Excluded. Google has since replaced that layout with the Page indexing report, which you find under Indexing > Pages in the left menu. The data is similar, but the structure is simpler:

Old Coverage report	Current Page indexing report
Valid	Indexed (green)
Error and Excluded	Not indexed (grey), with a “Why pages aren’t indexed” table of reasons
Valid with warnings	Indexed, with a separate “Improve page appearance” table for issues such as “Indexed, though blocked by robots.txt
“Submitted URL…” error variants	The same reasons, viewed through the sitemap filter instead of separate rows
Crawl anomaly	Retired; these now appear under more specific reasons

If you follow an old tutorial and cannot find a row it mentions, this is usually why. Everything below uses the current names.

How to read the report

Start with the chart. The green line is indexed pages, the grey line is not indexed. A steady shape is normal. A sudden fall in green, or a sharp jump in grey after a release or migration, is what you investigate first.
Switch the sitemap filter. The dropdown above the chart offers All known pages, All submitted pages, Unsubmitted pages only, or a specific sitemap. I almost always switch to All submitted pages, because your sitemap should list the URLs you actually want indexed. A non-indexed URL in that view is far more important than one Google found by itself.
Read the “Why pages aren’t indexed” table. Each row is a reason, with its source (Website or Google), a validation status and a page count.
Open a row and inspect examples. You get a trend for that reason and up to 1,000 example URLs. Click any URL and use URL Inspection to see Google’s view: last crawl, the canonical Google chose, and whether the live version is indexable.
Fix, then validate. Once the cause is fixed across the site, click Validate fix on that reason. Google rechecks the URLs and reports Started, Looking good, Passed or Failed.

Google’s Page indexing report help page is clear that “Not indexed” is not necessarily bad: most sites have unindexed pages, and duplicates, redirects and intentionally blocked pages should stay out. If you have not set up Search Console yet, my guide on submitting a website to Search Console covers verification and sitemaps. A separate report covers links, explained in the Search Console links report.

Rather have an expert do this for you?

Hand it over and get back to running your business.

Hand it over to me

Every “not indexed” reason and what to do

This is the triage table I use. The priority column assumes the URL is one you want indexed; if it is not, most of these rows need no action.

Reason	What it means	Usually	What I do
Server error (5xx)	Your server failed when Googlebot requested the page	Fix now	Check hosting logs, resource limits, firewall or security plugin blocking Googlebot
Redirect error	Loop, overly long chain, too-long or broken URL in the chain	Fix now	Point every redirect straight to the final 200 URL
URL marked ‘noindex’	A noindex tag or header stopped indexing	Check	Fine for thank-you, tag or login pages. If a key page, remove the noindex (often a staging setting or SEO plugin rule)
Blocked by robots.txt	robots.txt stops Google crawling the URL	Check	If the page should be indexed, allow it. If it should not, use noindex instead, as a block alone does not guarantee exclusion
Not found (404)	The URL returns 404	Usually fine	Redirect only if the page moved or has valuable links; otherwise leave it
Soft 404	The page looks empty or “not found” but returns 200	Fix	Return a real 404/410, or add proper content (common on empty category and search pages)
Blocked (401), (403) or other 4xx	Login, permissions or other client error	Check	Expected for private areas; otherwise fix server or firewall rules
Page with redirect	The URL redirects elsewhere	Expected	Only update sitemaps and internal links so they use the final URL
Alternate page with proper canonical tag	A variant correctly points to its canonical	Expected	No action
Duplicate without user-selected canonical	Google sees duplicates and you declared no canonical	Check	Add a canonical, or consolidate the duplicates
Duplicate, Google chose different canonical than user	You declared a canonical; Google picked another URL	Check	Align signals: internal links, sitemap, redirects and canonical tags should all agree
Discovered, currently not indexed	Google knows the URL but has not crawled it yet	Watch	Improve internal links to it, keep it in the sitemap, check server capacity and crawl budget on large sites
Crawled, currently not indexed	Google crawled it and chose not to index it for now	Improve	Usually a quality or duplication signal: strengthen, merge or remove thin pages

The two canonical rows are the ones I see misread most. Google’s documentation on duplicate URLs ranks redirects and rel=”canonical” as strong signals and sitemap inclusion as a weak one. If your canonical tag says one thing and your internal links and sitemap say another, Google may well choose its own canonical. My guide to canonical tags explains how to make the signals agree.

Page indexing report: monthly review checklist

Filter to All submitted pages: start with the URLs you asked Google to index.
Compare indexed count with reality: roughly how many pages should be indexed? A big gap either way needs explaining.
Check the chart for sudden changes: and match any change to releases, migrations or plugin updates.
Clear 5xx and redirect errors first: they waste crawling and can hide pages entirely.
Confirm noindex is intentional: open the noindex row and scan for key pages.
Review robots.txt blocks: blocked URLs that should rank need to be allowed.
Fix soft 404s: empty categories and filtered pages are the usual culprits.
Inspect canonical mismatches: sample URLs from both duplicate rows in URL Inspection.
Sample “Crawled, currently not indexed”: decide whether to improve, merge or remove each pattern.
Check “Discovered, currently not indexed” on large sites: look at internal linking and server response times.
Clean the sitemap: remove redirected, noindexed and 404 URLs so it lists only indexable pages.
Validate fixes: click Validate fix only after the cause is fixed everywhere.

Ticks are saved in your browser, so you can run the same review each month.

“Crawled” vs “Discovered, currently not indexed”

These two rows cause the most worry, and they mean different things.

Discovered, currently not indexed means Google has the URL in its queue but has not fetched it yet. Google’s help page says this is typically because crawling would have overloaded the site, so it was rescheduled. On small sites it usually clears on its own. On large sites, especially e-commerce sites with filter and parameter URLs, it can be a sign that Google is spending its crawl effort on the wrong URLs. My guide to crawl budget covers how to fix that, and index bloat explains how low-value URLs crowd out important ones.

Crawled, currently not indexed means Google fetched the page and decided not to index it, at least for now. When I audit sites, the pages in this row are usually thin (short tag or archive pages, near-identical location or product pages), duplicated elsewhere, or new pages with weak internal links. Requesting indexing again rarely helps on its own. What helps is giving Google a reason: more unique content, merging similar pages, and linking to the page from relevant, already-indexed pages. My guide to thin content shows how to decide between improving and consolidating.

Worked example: a WooCommerce shop with 3,000 “not indexed” URLs

This is an illustrative pattern, not a specific client. A shop has around 400 products and 40 categories, yet the report shows about 900 indexed and 3,000 not indexed. Filtering to All submitted pages tells a different story: 430 submitted, 410 indexed. The 3,000 are mostly:

Page with redirect: old http and non-www URLs, all correctly redirecting. No action.
Alternate page with proper canonical tag: ?orderby= and ?add-to-cart= variants. No action, though blocking add-to-cart links from crawling saves crawl effort.
Soft 404: 60 empty category and tag archives. Fix by removing empty archives or noindexing tag pages.
Crawled, currently not indexed: 20 submitted products with one-line manufacturer descriptions. Fix by writing real descriptions and linking them from their categories.

The headline number looked alarming; the real work was 80 URLs.

Validating fixes and using URL Inspection

Validate fix tells Google you believe an issue is resolved and asks it to recheck the affected URLs. Google says validation typically takes up to about two weeks. Only start it once the cause is fixed everywhere, because if too many URLs still fail, the whole validation fails and you have to start again.

For individual important pages, URL Inspection is faster: Test live URL confirms Google can fetch and index the current version, and Request indexing puts it in the crawl queue. There is a daily limit, so use it for key pages, not hundreds of URLs. The separate Indexing API is not a shortcut either: Google’s Indexing API documentation says it can only be used for pages with JobPosting or livestream BroadcastEvent markup.

For pages that keep failing, I check the basics in this order: the HTTP status with the redirect and status code checker, robots rules with the robots.txt tester, and the sitemap itself with the XML sitemap validator.

Mistakes I see with this report

Trying to get “Not indexed” to zero. Redirects, canonical alternates and intentional noindex pages belong there.
Blocking a page in robots.txt to remove it from Google. A blocked page can still be indexed from links. Use noindex, and do not block it, so Google can see the tag.
Leaving a staging noindex in place after launch. One of the most common causes of a site-wide drop I am asked to investigate.
Sitemaps full of redirected or noindexed URLs, which sends mixed signals and makes the submitted view useless.
Clicking Validate fix before fixing, which only produces a Failed status.

Frequently asked questions

Where is the Coverage report in Search Console now?

It is now the Page indexing report. Open Search Console, choose your property, and go to Indexing, then Pages. The reasons table under the chart replaces the old Error and Excluded tabs.

Is it bad to have many pages not indexed?

Not necessarily. Redirects, duplicates with a proper canonical, 404s for deleted pages and intentionally noindexed pages should not be indexed. Filter to All submitted pages and check whether the URLs you actually care about are indexed.

How do I fix “Crawled, currently not indexed”?

Treat it as a quality and relevance signal. Make the page more useful and unique, merge it with similar pages if it overlaps, link to it from relevant indexed pages, and keep it in your sitemap. Then request indexing for the most important URLs.

How long does Validate fix take?

Google says validation typically takes up to about two weeks, and sometimes longer. You will see the status move through Started and Looking good to Passed or Failed.

Why does Google choose a different canonical from mine?

Because other signals disagree with your canonical tag, for example internal links pointing to a different version, the other URL in your sitemap, or redirects. Make every signal point to the same URL, and make sure the pages really are duplicates if you want them consolidated.

Sources

Search Console Help, “Page indexing report” (accessed 2026).
Google Search Central, “How to specify a canonical URL with rel=”canonical” and other methods” (accessed 2026).
Google Search Central, “Indexing API quickstart” (accessed 2026).

If the report shows patterns you cannot explain, or important pages that will not index, my technical SEO service starts with exactly this report, server logs and a crawl of the site.