Search Console Errors in Plain English: Which Ones Actually Matter (2026)

Most of what Google Search Console lists under "why pages aren't indexed" is not an error, and working through it top to bottom would make your site worse rather than better. The page indexing report describes what Google did with every URL it knows about on your domain. Some of those decisions report a genuine fault. Some report a judgement Google made about the quality of a page. And a large share are Google confirming that a deliberate instruction you gave it worked exactly as intended — then listing that success in a section headed "not indexed", next to the actual problems, in the same grey type.

Business owners open the report, see eleven categories and a four-figure URL count, and either panic or close the tab. Both responses are wrong. It's a genuinely useful report once you know which lines are wired to something real.

The three tiers, before the detail

Every status falls into one of three buckets, and the bucket matters more than the label.

Tier one is things that are broken: server errors, redirect errors, pages returning the wrong HTTP status code. Faults in how the site responds to a request. Fixable this week, usually cheap, and costing you traffic while they sit there.

Tier two is things where Google made a judgement: crawled but not indexed, discovered but not indexed, and the two duplicate-canonical statuses. Nothing is broken in the plumbing sense. Google looked at the page and decided it wasn't worth adding, or that a different URL was the better version of it. These take months, and the fix is almost never technical.

Tier three is things working correctly: pages you deliberately excluded, redirects doing their job, alternate URLs pointing at their canonical properly. Google lists these because it lists everything. Touching them breaks working behaviour.

Sorting the report into those buckets first saves more time than any individual fix below.

Tier one: the ones that are genuinely broken

Server error (5xx)

Google's own page indexing report documentation describes this as your server returning a 500-level error when the page was requested. No ambiguity, no judgement — Googlebot asked for the page and your host failed to give it one.

This sits at the top because it compounds. Google's crawl budget documentation is explicit that server errors and slowdowns reduce how much of your site Google is willing to crawl at all. A run of 5xx responses doesn't just cost you the pages that errored, it quietly throttles crawling across everything else. Hand these to whoever manages your hosting before anything else on this page.

Redirect error

Google names four causes: a redirect chain that was too long, a redirect loop, a redirect URL that eventually exceeded the maximum URL length, or a bad or empty URL somewhere in the chain. That specificity tells you where to look. Loops and long chains almost always come from redirect rules stacked on each other over successive site changes — a URL structure changed in 2021, changed again in 2024, and nobody collapsed the two rules into one.

The fix is to point every old URL directly at its final destination in a single hop rather than relaying it through the intermediate steps. If a rebuild preceded this status appearing, the recovery process for a redesign that lost rankings covers redirect mapping in more depth.

Soft 404

Google's definition: the page returns what it thinks is a soft 404 response, meaning it shows a user-friendly "not found" message but does not return a 404 HTTP response code. This covers two completely different problems and you need to know which one you have before touching anything.

The first is a page that genuinely no longer exists, where the platform serves a pretty "sorry, we couldn't find that" screen with a 200 OK status underneath. That's a configuration fault, and a five-minute change on any properly built site: return a 404, or a 301 to a real replacement.

The second is a page that does exist, that you want indexed, and that Google has concluded is effectively empty. Thin service pages, location pages with two sentences and a map embed, category pages where the listings load only after JavaScript runs. Google isn't wrong about these. That fix is content, not code.

A noindex tag or robots.txt rule on a page that should be indexed

Google reports these as "URL marked 'noindex'" and "URL blocked by robots.txt", and both are usually correct behaviour on the URLs you meant to block. They become emergencies only when they turn up on pages you expected to rank. The cause is almost always a staging leftover promoted to production, or a platform setting toggled once and forgotten. Check yourdomain.com/robots.txt directly rather than trusting the report's summary: the report shows you the consequence, the file shows you the instruction. If those pages were indexed before and have since dropped out, that's a narrower investigation than this one, and the causes of pages disappearing from the index, ranked by likelihood walks through it in order.

Tier two: the ones where Google made a judgement

Crawled — currently not indexed

Google's wording is deliberately non-committal: the page was crawled but not indexed, it may or may not be indexed in the future, and there's no need to resubmit the URL for crawling. Google does not say why, and that's the frustrating part.

The honest interpretation is that Google visited, assessed, and decided the index is better off without the page for now. That's a quality assessment, not a fault. A handful of these on a healthy site is normal — tag archives, thin pagination, an old announcement post. A large and growing share of your real commercial pages sitting here is a signal that Google doesn't rate the content highly enough to bother storing it, which is a much bigger conversation than this report.

There is no button that fixes it. The pages have to become worth indexing: more substance, a clearer single purpose per page, genuine internal links pointing at them from pages that already rank. If your site is new and everything is sitting here, that's usually patience rather than pathology, and the diagnostic for a site that isn't showing up on Google at all is the better starting point.

Discovered — currently not indexed

This one is widely misread. Google's stated explanation is that it wanted to crawl the URL but expected doing so would overload the site, so it rescheduled the crawl. Read literally, that sounds like a hosting problem, and on an overloaded server it sometimes is.

But Google's crawl budget documentation gives the fuller picture: crawl demand depends on a site's size, update frequency, page quality and relevance compared to other sites. On a forty-page business site with decent hosting, "we didn't want to overload your server" is rarely the literal reason. Google hasn't judged the URLs worth the trip. Google also names sites with large portions of URLs in this exact status as a case where crawl budget genuinely matters, which is a fairly direct hint that too many low-value URLs is the cause.

If this is stacking up, the two things that move it are reducing the near-worthless URLs the site generates, and pointing real internal links at the pages you care about so Google has a reason to prioritise them.

Duplicate without user-selected canonical

Google's definition: the page is a duplicate of another page, doesn't indicate a preferred canonical, and Google has chosen the other page as the canonical instead. This is Google filling in a blank you left. Sometimes it picks the URL you would have picked, sometimes it doesn't, and either way you've handed the decision away. The fix is to declare a canonical. Google's canonicalisation documentation is clear that when you don't specify a preference, Google identifies which version it thinks is objectively best to show users — so specifying one is the whole job.

Duplicate, Google chose different canonical than user

This is the more interesting version: you declared a canonical and Google overruled you. That's allowed. Google treats rel="canonical" as a strong signal that the specified URL should become canonical, not as a command it must obey, and weighs other signals alongside it — redirects (the strongest), sitemap inclusion (a weak one), HTTPS preference, hreflang clusters, and how consistently your own internal links point at the page.

So when Google picks a different URL, it's usually because your other signals contradict your tag. The site links internally to one version, the sitemap lists a second, the canonical names a third. Making all three agree resolves this far more reliably than arguing with the tag. Where the pages really are too alike to justify separate entries — suburb pages, near-identical service pages, a staging copy nobody blocked — the fix is editorial rather than technical, and we've set out which duplication faults genuinely cost Australian sites rankings in the duplicate content piece.

Tier three: the ones to leave alone

"Page with redirect" means a non-canonical URL redirects to another page and therefore won't be indexed. That's what a redirect is for. "Alternate page with proper canonical tag" — Google's own wording says the page correctly points to the canonical page, which is indexed. The word correctly is doing the work there. And "Not found (404)" on URLs you deliberately deleted is the site behaving properly.

All three appear in a healthy site's report with a non-trivial URL count, and none need action. The failure mode is a well-meaning contractor treating the report as a to-do list, adding redirects for genuinely dead pages, stripping canonicals off pagination, and creating tier-one problems that weren't there to begin with.

The order to actually work in

Fix the 5xx errors first, because they throttle everything else. Then redirect errors, then soft 404s on pages that genuinely no longer exist, then any noindex or robots block sitting on a page you expected to rank. That's the whole of the urgent work, and on most small business sites it's a day rather than a project.

Then declare canonicals where none exist, and make your internal links, sitemap and canonical tags agree. Then — and only then — start the long work of making the "crawled, currently not indexed" pages worth indexing. Ignore tier three entirely.

One limit worth naming: the report tells you what Google decided, not why the site made it decide that way. If the real problem is that the platform is slow, the pages are heavy, or the HTML gives Google very little to work with, you're seeing the symptom and none of the cause. Same if rankings fell without any indexing status changing, which is a different diagnostic entirely.

The fastest way to rule the platform side in or out is to run the free audit — Core Web Vitals and page weight, the certificate, DNS and email records, the HTML structure, and whether robots.txt and your sitemap are letting crawlers do their job, in under a minute. It won't tell you what Google chose to index, because only Search Console can. It will tell you whether the pages you're asking Google to index are worth crawling in the first place, which is usually the question underneath the question.