Index Coverage Report Errors: What They Actually Mean

The page indexing report is the single most common reason people contact me. They open Search Console, see a thousand URLs marked as not indexed and a graph heading the wrong way, and assume the site is broken. Usually it isn't. A large share of the statuses in that report are not errors at all — they are Google telling you it did exactly what you asked.

Here is what each line means, which ones deserve your time, and the order I work through them.

Where the report lives and what it measures

In Search Console the section is Indexing → Pages (it used to be called Index coverage, and most people still call it that). The chart has two lines: indexed pages and not indexed pages. Below the chart is a table listing every reason Google gave for not indexing a URL, with a count beside each one.

Two things to understand before you read a single row:

• A big "not indexed" number is not a diagnosis. A shop with filters can legitimately have tens of thousands of uncrawled, unindexed URLs and be perfectly healthy.
• The data lags. The report does not update in real time. You are normally looking at the state of things several days ago. After a fix, nothing changes overnight.

Click any status and you get a sample of affected URLs that you can export. It is a sample, not the full list — Search Console caps how many examples it shows per status. On a large site you work with that sample and infer the pattern yourself.

Statuses that are genuine faults

These come first. They mean Googlebot hit something it shouldn't have.

Server error (5xx)

The server returned an error instead of a page. If the count is small and all the URLs appeared on one day, it was probably a short hosting outage and it will clear itself. If the count keeps climbing, either the hosting is unstable or the site falls over under crawler load. Check the server logs for the days the number spiked.

Redirect error

Googlebot couldn't finish a redirect — usually a loop (A → B → A) or a chain long enough that it gave up. This is the classic aftermath of a migration or a URL structure change. The fix is collapsing the chain to a single hop. I go through this in detail in the piece on redirect chains.

Not found (404)

The URL doesn't exist, but something still points at it — an internal link, an old external link, or your sitemap. A 404 on its own is not a penalty. It becomes a problem when pages that were supposed to exist return 404, or when your own menu and category pages link to them. How to tell those apart is in 404 errors and SEO.

Blocked due to unauthorized request (401) / Forbidden (403)

The page needs a login or a firewall is blocking it. For an admin area or customer account section that is correct behaviour — those URLs simply shouldn't be in your sitemap. If ordinary public pages show up here, something else is blocking them: bot protection, a WAF, or a misconfigured server rule.

Statuses that look like errors and usually aren't

Excluded by 'noindex' tag

The page carries a noindex and Google is respecting it. If you put that tag there deliberately, nothing to do. Check only that no page you want indexed ended up in the list — a noindex left over from a staging site is the most common reason a freshly launched site never appears in search.

Alternate page with proper canonical tag

The page points its canonical somewhere else and Google accepted that. This is exactly how it should work for product variants and paginated series. No action.

Page with redirect

The URL redirects and Google indexes the destination. Normal after an address change. The only issue is if those URLs sit in your sitemap — a sitemap should contain final, 200-returning addresses and nothing else.

Blocked by robots.txt

The crawler never reached the page because you told it not to. Intentional for carts, internal search results and filter URLs. Unintentional when a Disallow: / from development ships to production. I cover how to tell the two apart in robots.txt and sitemap errors.

The statuses I spend most of my time on

This is where most real indexing problems live.

Crawled — currently not indexed

Googlebot fetched the page, read it, and decided not to include it. That is not a technical fault, it's a judgement about the content. Typical causes:

• the text is near-identical to another page on the site (supplier-supplied product copy is the usual culprit),
• the page has a few sentences and nothing of its own,
• no internal link points to it, so the site itself treats it as marginal.

The fix is editorial, not technical: add original content, link the page from relevant categories, or merge it into something stronger. On shops this almost always traces back to duplicate product descriptions.

Discovered — currently not indexed

Google knows the URL exists but hasn't fetched it yet. On a new site that's normal and resolves with time. If you have tens of thousands of these and the number hasn't moved in months, Google is rationing crawl budget — either the server responds slowly, or the site generates far too many near-worthless addresses. The second case is nearly always faceted navigation and filters. The first is site speed.

Duplicate, Google chose different canonical than user

You set a canonical to one URL and Google preferred another. It means your signals contradict each other — internal links, the sitemap or redirects point somewhere other than the canonical tag. What to do about it is in the article on canonical tags and duplicate content.

Duplicate without user-selected canonical

Same situation, except you never set a canonical at all and Google picked for you. Sometimes it picks well, sometimes not. If several similar pages cover one topic, this is also a symptom of keyword cannibalization.

Soft 404

The page returns a 200 but reads like an empty or error page — a sold-out product, an empty category, a no-results search page. The fix depends on whether the content comes back: for a temporary gap, keep the page alive and offer alternatives; for a permanent removal, redirect to the parent category.

Indexed, though blocked by robots.txt

Google put the URL in the index without ever seeing it — it knows about it only from links. In results it shows up without a description. Disallow is not a removal tool. If you don't want the page in search, you have to allow the crawl and serve a noindex, otherwise Googlebot never reads the instruction.

The order I work through it

1. 5xx and redirect errors — these block access to the site itself.
2. Pages you want indexed that aren't — compare your sitemap against the indexed URL list. This is the only number that really decides anything.
3. Duplicates and canonical conflicts — they determine which version of a page shows up.
4. Crawled, currently not indexed — content work, and the slowest of the lot.
5. Everything else — deliberate exclusions can stay as they are.

After a fix, use the Validate Fix button in the status detail. Validation normally takes a few days to two weeks. You can submit individual URLs through the URL Inspection tool, but with hundreds of pages that is pointless — there, the sitemap and internal linking do the work.

What the report won't tell you

It won't tell you which indexed pages are dead weight. A page can be in the index and still hurt the site by splitting relevance across two addresses. It also won't tell you what to change on the page — you learn that something is duplicate, not which title and description caused it.

That gap is the part I handle. When I crawl a site I list the exact URLs sharing titles and descriptions, the missing canonicals and the links pointing at pages that no longer exist — and for the findings that matter I write the finished replacement text, not a note saying "improve the title". You approve it and deploy through the WordPress plugin, the API, or a CSV export. Then I compare the 28 days before and after deployment so you can see whether indexing and traffic actually moved. How to read those numbers is in the article on measuring SEO impact.

If you want a starting point, the free site audit shows how many findings the site has and what type they are.

#seo obsah