Search Console page indexing errors, explained
A reference for the report's actual status strings — and why driving the not-indexed count to zero is the wrong goal.
The Page indexing report is the most useful thing in Search Console and the most commonly misread. Its central trap is that a large “not indexed” number looks like a large problem, when for most sites the majority of it is Google correctly declining to index pages that were never meant to be indexed.
Finding the report
Search Console → Indexing → Pages. It was called “Coverage” until 2022 and “Index Coverage” before that, which is why older guides send you to a menu item that no longer exists.
The top splits every known URL into indexed and not indexed. Below that, the not-indexed pages are grouped by reason. Work through the reasons, not the total.
The statuses that are genuinely errors
Server error (5xx). Your server failed while Googlebot was asking. A handful is noise; a sustained pattern means Googlebot is hitting something users may be hitting too, or that crawl load is overwhelming the server. Check whether the URLs share a template.
Redirect error. A loop, a chain too long to follow, or a redirect to a bad URL. Test the URL yourself and count the hops.
Submitted URL blocked by robots.txt. A direct contradiction: your sitemap says index this, your robots.txt says do not fetch it. One of the two is wrong.
Submitted URL marked ‘noindex’. The same contradiction with a different mechanism. Usually a page that changed purpose, or a CMS setting flipped and forgotten.
Not found (404) among submitted URLs. A 404 that nothing links to is fine and needs no action. A 404 in your sitemap means your sitemap is stale. A 404 that used to rank means a migration dropped a redirect, and that one costs real traffic.
Blocked due to unauthorized request (401) or access forbidden (403). Googlebot is being refused. Frequently a security plugin, a firewall rule or bot protection that does not recognize it. Verify with the URL Inspection tool’s live test, which fetches as Google actually does.
Soft 404. The page returns 200 but looks empty or says nothing was found. Common on out-of-stock products, empty search results and category pages with no items. Either return a real 404, or give the page real content.
The statuses that are usually correct
These make up most of the not-indexed count on a healthy site.
Page with redirect. The URL redirects, so the destination is indexed instead. Exactly right.
Alternate page with proper canonical tag. A duplicate pointing at its canonical. Also exactly right — this is deduplication working.
Excluded by ‘noindex’ tag. You asked for this. Only investigate if a page listed here should have been indexed.
Blocked by robots.txt. Fine for admin paths and internal search. Worth a second look if it lists pages you want ranking — and worth knowing that robots.txt blocks crawling, not indexing, so a blocked page with inbound links can still appear in results with no description, the separate status indexed, though blocked by robots.txt.
Duplicate without user-selected canonical and Duplicate, Google chose different canonical than user. These are worth attention. The first means Google found duplicates and you gave no guidance. The second means you gave guidance and Google overrode it — usually because internal links, sitemap entries or redirects all point somewhere other than your declared canonical. Google follows the weight of evidence, not the tag alone.
The ambiguous ones
Discovered — currently not indexed means Google knows the URL exists but has not crawled it yet. At small scale it is a queue and will resolve. At large scale it usually means crawl capacity is the constraint — crawl budget and faceted navigation covers why, and it is almost always a symptom of too many low-value URLs rather than too few good ones.
Crawled — currently not indexed is the one that generates the most anxiety, because Google fetched the page, read it, and chose not to index it. That is a quality judgment rather than a technical fault, and it has enough causes to deserve its own page: crawled, currently not indexed.
How to work through it without wasting a day
Start with the “submitted” variants. Anything labeled “Submitted URL…” came from your sitemap, so your own site is asserting the page should be indexed while something else prevents it. That contradiction is always worth resolving and is usually a quick fix.
Sort by trend, not by count. A status that jumped last Tuesday points at a change you made last Tuesday. A status that has held steady for a year is background.
Use URL Inspection on one example per group. Pages in a group almost always share a template, so one live test usually explains the whole group. The live test is the authoritative view — the summary can be days old.
Validate the fix in the report. Each issue has a Validate fix button that queues a recrawl and reports back. Use it rather than resubmitting URLs one at a time.
Expect to wait. The report lags by days, and validation runs over a couple of weeks. Nothing here confirms the same afternoon.
The mistake to avoid
Do not try to drive the not-indexed count to zero. A site with faceted navigation, pagination, filters and tracking parameters generates thousands of URLs that should never be indexed, and every one of them will appear in that report forever. Removing them from the report means removing them from Google’s knowledge, which is neither possible nor desirable.
The number that matters is different: of the pages you actually want indexed, how many are? Compare your sitemap count against the indexed count. That ratio is the one to move.
Before you go back to the report
Several of these errors are things you can confirm from outside Search Console in seconds. Our indexability checker tells you whether a specific URL is blocked by robots.txt, carries noindex, or canonicalizes elsewhere — useful when you want to verify a fix before waiting days for Google to recrawl. The sitemap checker catches the stale- sitemap case that produces most “Submitted URL not found” errors, and the full site check flags the whole set across your pages at once.
Frequently asked questions
- What does 'not indexed' mean in Search Console?
- It means the URL is known to Google but not in the search index, which is frequently correct rather than broken. Redirects, pages you marked noindex, and duplicates pointing at a canonical all appear under 'Not indexed' and are all working as intended. Judge each reason group separately instead of treating the total as a defect count.
- Where is the Coverage report in Search Console?
- It was renamed. Look under Indexing → Pages, which is the report previously called Coverage and, before that, Index Coverage. Guides that still say Coverage predate the 2022 rename, which is worth noting because it also dates the rest of their advice.
- How do I fix 'Submitted URL blocked by robots.txt'?
- That status is a direct contradiction: your sitemap tells Google to index the page while your robots.txt tells it not to fetch the page. Decide which is right. If the page should rank, remove or narrow the robots.txt rule blocking it; if it should not, remove it from the sitemap. Leaving both in place means Google keeps re-encountering the conflict.
- What is a soft 404?
- A page that returns a 200 success status while its content says nothing was found — an out-of-stock product, an empty search result, a category page with no items. Google treats it as a 404 because the content is what matters, not the header. Fix it by returning a genuine 404 status, or by giving the page real content such as alternatives or related items.
- Why did Google choose a different canonical than the one I set?
- Because a canonical tag is a strong hint rather than a directive, and Google weighs it against everything else pointing at the pages. If your internal links, sitemap entries and redirects all favor a different URL than your canonical tag names, the tag loses. Make all the signals agree — the tag alone is not enough.
- Should I try to get the not-indexed count down to zero?
- No. Any site with pagination, filters, faceted navigation or tracking parameters generates large numbers of URLs that should never be indexed, and every one will appear in that report permanently. The useful metric is different: of the pages you actually want indexed, what proportion are? Compare your sitemap count against the indexed count and work on that ratio.
- How long does it take for a fix to show in the Page indexing report?
- Days at minimum, and validation runs over roughly two weeks. The report summary lags behind reality, so use the URL Inspection tool's live test to confirm a fix immediately, then click 'Validate fix' on the issue group to queue a recrawl rather than resubmitting URLs individually.