Search Console Index Coverage Report Explained

Where to find it

In Search Console, open Indexing → Pages for your property. Google splits every URL it knows about into two buckets: Indexed (currently eligible to appear in search results) and Not indexed, broken down further by reason. The reason labels are the part people usually don't know how to act on — most of them are not errors.

Reasons that are normal, not problems

• Excluded by 'noindex' tag — you told Google not to index it. Only worth checking if you didn't mean to (see robots.txt vs noindex).
• Alternate page with proper canonical tag — a duplicate correctly pointing at the version you want indexed. Working as intended.
• Page with redirect — the URL forwards somewhere else, so Google indexes the destination instead. Fine for permanent redirects; worth a look if it's an old URL you expected to still resolve directly.

Reasons that usually need a decision

• Discovered - currently not indexed — Google knows the URL exists but hasn't crawled it yet. See the dedicated guide.
• Crawled - currently not indexed — Google fetched the page and decided not to index it, usually a content-quality signal. See the dedicated guide.
• Duplicate without user-selected canonical — Google found near-identical pages and picked a canonical itself, which may not be the one you want. Fix with an explicit canonical tag — see duplicate content and canonical tags.
• Soft 404 — the page returned HTTP 200 but looks empty or broken to Google. See the dedicated guide.
• Blocked by robots.txt — worth checking whether that block was intentional; see robots.txt vs noindex.

How to prioritize when you see a long list

Sort by URL count, then check whether the pages under each reason are ones you actually want indexed. A thousand paginated or filtered URLs sitting under "Duplicate without user-selected canonical" is often a non-issue; twenty product pages sitting under "Crawled - currently not indexed" is worth investigating today. The count alone doesn't tell you which is urgent — the URLs underneath it do.

After you fix something

The report itself can take days to refresh a given URL's status even after you've fixed the underlying cause, since it reflects Google's last crawl, not your current code. Use the URL Inspection tool's "Request Indexing" for a single fixed URL, and notify the engines that support IndexNow (Bing and others, not Google) rather than waiting for the report to catch up on its own schedule.

Reading the report’s controls

The Page indexing report has a few controls that change what you are looking at. Most misreadings come from not noticing them.

• The page filter at the top. It defaults to All known pages, which includes every URL Google has seen, from links, old sitemaps, redirects and parameter variants. Switch to All submitted pages to see only URLs in your sitemaps, or pick a single sitemap. The submitted view is the one that answers “are the pages I care about indexed?”
• The Source column in the “Why pages aren’t indexed” table. “Website” means something you control caused it (a noindex, a redirect, a robots.txt rule). “Google systems” means Google made the decision, as with “Crawled - currently not indexed”.
• The Validation column shows whether you have started a fix validation for that reason and how far it has progressed.
• The chart shows totals over time. Click a reason row to open its detail page, which has its own trend chart and a list of example URLs with the date each was last crawled.

The example list is a sample, capped at 1,000 rows. On a large site, use sitemap filtering to narrow the view, or add URL-prefix properties for key sections (for example https://example.com/blog/) so each section gets its own report and its own sample.

Every not-indexed reason, with its usual fix

The reasons below are the ones Google documents in its Page indexing report help page. The ones already covered above are summarized briefly.

You may also see Indexed, though blocked by robots.txt on the indexed side. That means Google indexed the URL from links without being allowed to crawl it. If you want it out of search, remove the robots.txt block and add noindex, because Google cannot see a noindex on a page it is not allowed to fetch. The robots.txt vs noindex guide walks through that sequence.

A repeatable weekly triage routine

Checking the report occasionally and reacting to the biggest number tends to waste effort. A short, fixed routine catches real problems early.

1. Set the filter to All submitted pages. Note the indexed and not-indexed totals. A sharp rise in not-indexed submitted pages is the main thing to watch for.
2. Sort the reasons table by Pages. For each reason whose count grew since last week, open it and look at the example URLs and their “Last crawled” dates.
3. Classify each sample URL: should it be indexed or not? If not, remove it from the sitemap so it stops showing up in the submitted view.
4. For URLs that should be indexed, run URL Inspection, then Test live URL to see the current state rather than the state at the last crawl.
5. Fix the cause, deploy, then click Validate fix on that reason’s detail page.
6. Use the export button (Google Sheets, Excel or CSV) to save the sample each week. Comparing exports is the simplest way to see which URLs moved between reasons.

Between checks, the free Google index checker is handy for spot-checking a handful of important URLs without opening Search Console.

How fix validation works

Validation tells Google you believe the issue is fixed for every URL under that reason. Google then recrawls the affected URLs on its own schedule and reports progress. The states you will see are Not started, Started (or Looking good), Passed and Failed.

• Validation commonly takes up to about two weeks and can take longer on large sites. Starting it again does not speed it up.
• If any URL in the set still shows the issue, the validation fails. Fix the remaining URLs and start it again. A failed validation does not penalize anything; it is only a status.
• Validation is about the issue disappearing, not about indexing. A URL that leaves the “Soft 404” reason can land under “Crawled - currently not indexed” next. That counts as passed for the soft 404 validation.
• Do not validate reasons that are working as intended (noindex, redirects, alternates). There is nothing to fix.

Checking statuses in bulk with the URL Inspection API

The report only shows samples. If you need the status of a specific list of URLs, the Search Console URL Inspection API returns the same data as the URL Inspection tool, one URL per request, within a daily quota per property. It reports the coverage state, the user-declared and Google-selected canonicals, robots.txt state and the last crawl time.

POST https://searchconsole.googleapis.com/v1/urlInspection/index:inspect
Authorization: Bearer <OAuth access token>
Content-Type: application/json

{
  "inspectionUrl": "https://example.com/blog/post-slug",
  "siteUrl": "sc-domain:example.com"
}

The API cannot request indexing. It is read-only, so treat it as a monitoring tool for your most important URLs. See the Search Console API documentation for authentication and quota details.

Worked example: a sudden jump in not-indexed pages

Common misreadings of the report

• “More not-indexed than indexed pages means something is broken.” Not necessarily. Redirects, alternates, parameter URLs and old 404s all count as not indexed. Judge the submitted view, not the total.
• Treating the report as live. It reflects the last crawl and processing of each URL. Use Test live URL to see today’s state.
• Reading the indexed count as a ranking signal. Indexed means eligible to appear, not that a page gets traffic. Pair this report with the Performance report.
• Comparing Domain and URL-prefix properties directly. A Domain property covers every subdomain and protocol, so its totals will be larger.

The Bing equivalent

Bing Webmaster Tools has no single matching report, but URL Inspection shows whether a URL is indexed and why not, and Site Explorer lets you browse your site’s URLs as Bing sees them, with filters for issues. If Bing coverage matters to you, see the Bing indexing guide.