The index coverage report in Google Search Console — now labeled simply “Pages” under the Indexing section — is the closest thing you get to Google explaining its decisions about your site. It splits every URL Google knows about into indexed and not indexed, then groups the exclusions by reason. Read it correctly and you get a prioritized technical to-do list. Read it carelessly and you spend a week fixing things that were working as intended.
The most important reframe: a large “not indexed” number is not automatically a problem. Redirects, canonicalized duplicates, and deliberately noindexed pages all land there, and all of them should. What matters is whether pages you want ranking are sitting in that bucket.
Where the report lives and what it covers
Open Search Console, choose your property, then Indexing → Pages. You will see a chart splitting known URLs into indexed and not indexed over time, then a table of reasons below. There is a second view worth using immediately: the sitemap filter. Switching from “All known pages” to a specific submitted sitemap narrows the report to URLs you explicitly claimed should be indexed, which strips out most of the noise.
Two limits to know. The report samples — you get up to 1,000 example URLs per issue type, not the full list. And it lags; data typically runs a few days behind, so a fix deployed yesterday will not show yet. Do not panic-iterate on a change that has not had time to be recrawled.
The statuses that usually mean “working as intended”
Several exclusion reasons are normal site plumbing:
- Page with redirect. The URL 301s elsewhere. Expected after any migration.
- Alternate page with proper canonical tag. Google agreed with your canonical and indexed the master version. This is a success message wearing a warning’s clothes.
- Excluded by ‘noindex’ tag. You asked for this. Confirm the list is only pages you meant to exclude.
- Not found (404). Fine for genuinely dead URLs. A problem only when internal links still point at them.
- Blocked by robots.txt. Intentional for admin paths and internal search. Check nothing valuable is in there.
Work through each of these once, confirm the sample URLs match your intent, then stop looking at them. They will never reach zero and should not.
One that deserves a second look is Indexed, though blocked by robots.txt. It sits in the indexed bucket but signals a contradiction: Google found the URL through links, indexed it on that basis, but cannot fetch it to see any tag on the page. Adding a noindex will not help while the block is in place, because the crawler never gets to read it. Remove the robots.txt disallow, let the noindex be seen, then reconsider blocking later.
The statuses that need real work
These are the ones worth your time.
Discovered – currently not indexed. Google knows the URL exists but has not crawled it yet. At scale this is a crawl budget and quality signal: the site is generating URLs faster than Google considers them worth fetching. Improve internal linking to those pages, cut the volume of low-value URLs, and speed up the server.
Crawled – currently not indexed. Google fetched the page, looked at it, and declined. This is a quality verdict, not a technical fault. Thin pages, near-duplicate product descriptions, and auto-generated location pages live here. No amount of resubmitting fixes it — the page has to become worth indexing.
Duplicate, Google chose different canonical than user. You nominated one URL; Google picked another. Investigate which version it chose and why. Usually your internal links, sitemap, or redirects contradict your canonical tag, and Google trusted the majority signal.
Soft 404. The page returns 200 but looks empty or error-like. Out-of-stock products, empty search results, and thin category pages trigger this. Either add real content or return a proper 404 or 410.
Server error (5xx) and Redirect error. Both are hard technical faults. Fix immediately; they suppress crawl rate across the whole site.
“New index coverage issue detected” emails
That subject line lands in your inbox whenever a new exclusion category crosses a threshold, and it causes more unnecessary alarm than any other Search Console notification. Before you react, ask three questions.
First, does the issue type match something you deliberately changed? A bulk noindex rollout or a category cleanup will trigger an alert about work you just did. Second, how many URLs are affected as a share of the site? Forty URLs on a 20,000-page site is noise. Third, are the affected URLs pages you actually want indexed? Open five samples and check.
If all three answers say “expected,” dismiss it. If not, the report gives you a validation workflow: fix the underlying cause, click Validate Fix, and Google requeues the sample URLs for recrawl. Validation typically takes one to two weeks and can fail if you validate before the fix is live — so deploy first, verify with the URL Inspection tool, then validate.
URL Inspection: the per-page counterpart
The coverage report tells you what happened to groups of URLs. The URL Inspection tool tells you what happened to one, and it is where you confirm every fix. Paste a URL and you get the indexing status, the canonical Google selected versus the one you declared, the last crawl date, the crawling user agent, and any detected structured data.
Use “Test Live URL” to see the current state rather than the cached verdict, and open the rendered HTML view. That view is how you catch content that exists in the browser but not in what Google renders — a common cause of “Crawled – currently not indexed” on JavaScript-heavy sites, where the crawler receives an empty shell.
Auditing beyond what the report shows
The coverage report has a structural blind spot: it only tells you about URLs Google already knows. It cannot tell you about pages that exist on your site but are orphaned, unlinked, and undiscovered. For that you need your own crawl of the site, then a comparison against what Search Console reports.
That comparison is the single highest-value exercise in indexation work. Pages in your crawl but missing from Google’s known set are discovery failures. Pages in Google’s set but missing from your crawl are orphans generated by templates or old links. Both need different fixes, and neither is visible from one data source alone.
SEO Rocket’s technical audit runs full-site crawls — verified past 900 pages — and reports evidence per issue rather than a bare count: the exact URLs, page titles, H1 text, and tags behind every finding. It also connects Google Search Console and GA4 as ground truth alongside third-party estimates, and pairs PageSpeed lab metrics with real-user Core Web Vitals field data, which matters because slow response times throttle crawling long before they hurt rankings directly. It will not deploy redirects or edit your robots file for you — but it will hand you the exact list to give your developer.
A working monthly routine
Filter the report to your submitted sitemap. Note the indexed count and compare it to last month. Scan the not-indexed reasons for anything that grew by more than a few percent. Open five sample URLs from any category that moved. Fix causes, not symptoms — one template usually explains hundreds of URLs. Then validate and wait.
Set expectations honestly with whoever you report to. Indexation changes surface over weeks as Google recrawls, and the number will never be a clean 100%. A stable indexed count matching your genuinely valuable pages, with exclusions you can explain in one sentence each, is the actual goal.
