Why Your Pages Aren't Indexed: Every Google Search Console Status Explained (2026)

The first time someone opens Google Search Console and scrolls to “Why pages aren't indexed,” the reaction is almost always the same: a small wave of panic. A wall of official-sounding statuses — Page with redirect, Crawled — currently not indexed, Alternate page with proper canonical tag — each with a page count next to it, each looking like something you broke.

I've stared at this exact screen on my own sites and on dozens of others, and here's what I want you to know before we go further: most of these are not emergencies, and several are Google working exactly as it should. The skill isn't “fixing” every line — it's knowing which three lines matter and which nine you can safely leave alone. That's the whole game, and this guide is the map I wish someone had handed me.

Here's the report we're going to decode, line by line:

By the end, you'll be able to look at any row and instantly answer four questions: what does it mean, why did my page land here, how is Google thinking about it, and what — if anything — should I do? I'll give you the official Google definitions and the plain-English version for every status. Let's start with the two ideas that make the whole report click.

What is the Google Search Console Page indexing report?

The Page indexing report (you'll still hear people call it the “Index Coverage” report — same thing, renamed) is Google's account of every URL it knows about on your site and whether or not it's in the index. If a page isn't in the index, it literally cannot appear in Google Search — so this report is the difference between “my page can rank” and “my page is invisible.”

It splits every known URL into two buckets: Indexed (eligible to show up in search) and Not indexed (not eligible, for one of the reasons in that table). A quick bit of history that clears up a lot of confusion: in late 2022 Google merged the old “Excluded” and “Error” buckets into the single “Not indexed” status, and merged “Valid” into “Indexed.” So if you read an older SEO article talking about “Excluded” pages, it's describing the same reasons you see under “Not indexed” today.

Does “not indexed” mean my page is broken?

No — and this is the single most important mindset shift. “Not indexed” is not a synonym for “error.” Google's own documentation is blunt about it: not every page that Google crawls will be indexed, and a large chunk of “not indexed” URLs are pages Google deliberately chose to leave out — duplicates, redirects, alternates, pages you told it to skip. That's exclusion by design, not failure.

In the report above, look at the counts: 12 redirects and 9 alternate-canonical pages make up the bulk of the “problem.” Both of those are usually Google correctly following instructions your own site gave it. The genuinely worth-your-time rows — a redirect error, a couple of 404s, 8 crawled-but-not-indexed — are a much smaller slice. So the goal isn't to drive this list to zero. A healthy site always has “not indexed” pages. The goal is to separate signal from noise, which brings us to the two tools that do exactly that.

What does the “Source” column mean (Website vs Google systems)?

See that Source column in the report? It's the most useful and most ignored column in the whole thing. It tells you who is responsible for the reason a page isn't indexed — and therefore who can fix it.

This one distinction saves you hours. When the Source is Website, there's a concrete lever on your end — a redirect to untangle, a 404 to restore, a stray noindex to remove. When the Source is Google systems, Google has made a call about quality, crawl priority, or which duplicate to keep. You can send it better signals, but there's no button that forces it. So the first thing I do on any report is mentally sort the rows by Source: the “Website” rows are my to-do list, and the “Google systems” rows are my investigate-and-improve list.

Which not-indexed reasons should you actually fix?

Before we go status by status, here's the whole report sorted the way I actually work through it — into fix now, investigate, and usually fine. If you only take one image from this guide, make it this one:

Notice the pattern: the fix-now column is all technical breakage (broken redirects, server errors, real 404s) — concrete and quick. The investigate column is the quality and crawl stuff that's slow to move and has no quick button. And the usually-fine column is Google doing its job. Now let's walk through every status, grouped by that Source column, so you know exactly what each one is telling you.

The “Website” reasons: the ones you control

These are the statuses where the cause lives on your site. For each one I'll give you the same four things: what it means, why it happens, how Google looks at it, and what to do.

Page with redirect: what it means and when to worry

What it means: this URL sends visitors (and Googlebot) somewhere else with a redirect, so Google indexes the destination page instead of this one. The redirecting URL itself is, correctly, not indexed.

Why it happens: completely normal site plumbing. You moved http:// to https://. You added a trailing slash. You retired an old blog post and pointed it at the new one. You consolidated example.com and www.example.com. Every one of those creates a “Page with redirect” entry — and that's good.

How Google looks at it: as a housekeeping note, not a problem. It followed your redirect and indexed the right page.

What to do: almost always nothing. Only dig in if (a) a page you want indexed is showing up here — meaning it's accidentally redirecting — or (b) you spot long redirect chains (A → B → C → D), which waste crawl budget and slow everything down. Collapse chains to a single hop. Otherwise, leave it.

Alternate page with proper canonical tag: is it a problem?

What it means: this page has a rel="canonical" tag pointing to a different page as the “master” version, and Google indexed that master instead. This is canonicalization working exactly as intended.

Why it happens: you have legitimate duplicate or near-duplicate URLs and you've correctly told Google which one to treat as primary. Classic examples: a product page reachable at /shoes?color=red and /shoes?color=blue that both canonicalize to /shoes; a printer-friendly version; an AMP page pointing to its desktop original; or paginated pages pointing to page one.

How Google looks at it: as a job well done. It found your canonical tag, respected it, and indexed the version you asked for.

What to do: in the vast majority of cases, nothing — this is one of the most benign statuses in the whole report. The only reasons to look closer: if a page you actually want ranking is sitting here (its canonical is pointing at the wrong URL), if the count is wildly disproportionate to your real page count, or if canonicals are pointing at URLs that don't exist. Spot-check a few with URL Inspection; if the canonicals are correct, move on.

Redirect error: how to find and fix it

What it means: Google tried to follow a redirect and failed. This is a real problem — the redirect is broken.

Why it happens: a redirect chain that's too long, a redirect loop (A → B → A), an empty or malformed redirect URL, or the redirect target timing out.

How Google looks at it: as a genuine error under the “Website” source — it wanted to reach a page and couldn't.

What to do: fix it. Run the URL through a redirect checker (or Screaming Frog), trace the hops, and rebuild it as a single 301 to a live 200-OK page. No loops, no chains, no dead targets. This is a “fix now” row every time.

Not found (404): when it matters and when it doesn't

What it means: the URL returns a 404 (or 410) — the page doesn't exist — so Google dropped it from the index.

Why it happens: you deleted a page, a product went out of stock and its URL was removed, an internal or external link has a typo, or an old URL got linked somewhere and Google went looking for it.

How Google looks at it: neutrally. A 404 is a perfectly valid answer. Google does not penalize you for having 404s — they're a normal part of the web.

What to do: it depends entirely on whether the page should exist. If it should (you deleted it by mistake, or it has value and inbound links) — restore it, or 301-redirect it to the most relevant live page. If it genuinely should be gone, a 404/410 is the correct response — just hunt down any internal links still pointing at it so you stop feeding Google (and users) a dead URL. Don't reflexively redirect every 404 to your homepage; that creates soft 404s (next section).

Soft 404: why Google thinks your page is empty

What it means: the page returns a success code (200 “OK”) but looks empty or like a “not found” page to Google. The signal (200) and the reality (nothing here) don't match, so Google flags it.

Why it happens: a “No results found” search page that returns 200, an out-of-stock product page with the content stripped out, a thin or blank page, or — the classic — redirecting every deleted URL to your homepage, which Google reads as “this isn't the page they asked for.”

How Google looks at it: as a mismatch it needs to correct. It won't index a page that behaves like an error even if the header says 200.

What to do: decide what the page really is. If it's genuinely gone, return a true 404 or 410. If it should exist, give it real, substantive content so it no longer looks empty. Fix the underlying honesty problem — make the status code and the content agree.

Excluded by ‘noindex’ tag: usually intentional

What it means: the page has a noindex meta tag (or X-Robots-Tag header), which explicitly tells Google not to index it — and Google obeyed.

Why it happens: most of the time, on purpose. Thank-you pages, admin and login screens, internal search results, staging pages, tag archives — all commonly (and correctly) set to noindex.

How Google looks at it: as a direct instruction it's following to the letter.

What to do: confirm it's intentional. This is only a problem when an important page — a money page, a key blog post — got a noindex by accident (a botched CMS setting or a template change is the usual culprit; I've watched a single theme update silently noindex an entire blog). If the page belongs in Google, remove the tag. If it doesn't, you're done.

Blocked by robots.txt: crawl blocked, not always deindexed

What it means: your robots.txt file is telling Google not to crawl the URL. Note the nuance: blocking crawling is not the same as guaranteeing the page stays out of the index — Google can still index a URL it can't crawl if enough other pages link to it (it just can't see the content).

Why it happens: you deliberately disallowed a section (a /cart/, /admin/, or faceted-navigation path), or — the dangerous version — a disallow rule is accidentally blocking pages you want crawled.

How Google looks at it: as a crawl instruction it respects.

What to do: check intent with the robots.txt Tester. Intentional block of low-value URLs? Fine, leave it. Accidentally blocking important pages? Fix the rule. And remember: if you want a page truly kept out of the index, use noindex (which requires the page to be crawlable), not a robots.txt block.

Server error (5xx): fix your hosting first

What it means: your server returned a 5xx error when Googlebot tried to fetch the page — it couldn't load, so it couldn't be indexed.

Why it happens: the server was overloaded, timed out, went down during the crawl, or a bug threw a 500. Sometimes it's Googlebot's crawl rate briefly overwhelming a small host.

How Google looks at it: as a real failure — and if 5xx errors persist, it will slow its crawling of your whole site to avoid making things worse.

What to do: treat it as a “fix now.” Check with your host for uptime and resource issues, look at response times and timeouts, and confirm the URLs load reliably now. Then use URL Inspection to have Google re-check. Persistent 5xxs are one of the few indexing issues that can drag down far more than the affected pages.

The “Google systems” reasons: Google's judgment calls

Now the harder half. These statuses aren't about a broken tag — they're Google deciding, based on quality, crawl priority, or duplication, not to index a page. There's no switch to flip; you work by improving signals. Two of them — Discovered and Crawled — currently not indexed — get confused constantly, so let's fix that with a picture of the journey a URL takes:

Discovered — currently not indexed: why Google hasn't crawled your page

What it means: Google knows your URL exists (it found it in your sitemap or via a link) but hasn't actually fetched it yet. The giveaway in URL Inspection: the last-crawl date is empty. This is a crawl-priority problem, not an indexing-value one.

Why it happens: Google's Martin Splitt laid out three reasons in Google's own “SEO Made Easy” series — the video's at the top of this post. First, quality signals: if Google has seen a pattern of thin or low-value pages on your site, it can deprioritize crawling more URLs that look similar — sometimes without crawling them at all. Second, server capacity: if your server looks slow, Google throttles back to avoid overwhelming it, so it crawls your pages over a longer stretch. Third, sometimes it just needs more time — the URL is queued and Google hasn't gotten to it.

How Google looks at it: as a prioritization decision. As Google's John Mueller has put it, when a lot of your pages sit here, the answer usually isn't in those specific URLs — it's in the overall quality and structure of the site. (Worth knowing: Google's Gary Illyes has said roughly 90% of sites never need to think about crawl budget, so for most sites this is a quality and internal-linking signal, not a “crawl budget” one.)

What to do: strengthen the signals that make Google want to crawl these pages. Add internal links from strong, already-indexed pages (orphan pages with no internal links are a top cause). Improve site-wide content quality so your URL patterns don't look low-value. Keep your sitemap clean — only 200-OK, canonical URLs. Fix crawl traps like infinite faceted-navigation URLs. And make sure your server is fast. This moves slowly — think weeks, sometimes months — so be patient and don't just spam “Request indexing.”

Crawled — currently not indexed: what it means and how to fix it

What it means: Google did fetch and read the page — there's a real crawl date — and then chose not to index it (at least for now). It saw the page and decided it wasn't worth including. This is a value judgment, and it's the one that stings.

Why it happens: overwhelmingly, content quality — and usually not just the page in question. Thin content, content that duplicates what's already out there, mass-produced or lightly-edited AI pages, or a page that simply doesn't add anything a hundred other pages don't. Weak internal linking and a site that, on the whole, doesn't signal quality make it worse.

How Google looks at it: selectively. Crawling a page never guarantees indexing — John Mueller has been explicit that Google doesn't index everything, and that when pages pile up here it's typically a site-wide quality signal rather than something wrong with each individual URL. Martin Splitt has similarly noted Google may drop pages when it notices a pattern of low-quality or thin content. In other words: Google is telling you it doesn't think this content earns a spot.

What to do: raise the quality bar. Make these pages genuinely more useful, deeper, and more distinct than what's already ranking — or consolidate several thin pages into one strong one. Add internal links from relevant, authoritative pages on your site. Then, and only then, use URL Inspection to request a re-crawl. What not to do: don't hammer “Request indexing” repeatedly (it won't override a quality decision), and don't delete the pages in a panic. Fixes here take weeks to months to show up — this is the slowest row in the report.

Duplicate, Google chose different canonical than user

What it means: you declared one URL as canonical, but Google overrode you and indexed a different URL as the master version instead.

Why it happens: this is allowed because — in Google's own words — a rel=canonical tag is a hint, not a directive. Google clusters pages it considers duplicates and picks the one it judges most complete and useful, weighing signals like HTTPS vs HTTP, redirects, which URL is in your sitemap, internal links, and your canonical hint. When its pick differs from yours, you get this status. Common triggers: mixed signals across your site, near-identical pages, or your canonical pointing somewhere your other signals contradict.

How Google looks at it: as tidying its index — either removing a duplicate or, in its words, correcting what it thinks is a mistake on the site.

What to do: first, check whether it even matters. Open URL Inspection and compare the “User-declared canonical” (yours) with the “Google-selected canonical” (its pick). If Google's choice is a perfectly good page, this is benign — leave it. If Google picked the wrong page, strengthen your signals so they all agree: make the pages genuinely distinct, add a 301 redirect if they're truly the same thing, and align your internal links and sitemap behind your preferred URL. Give it time — canonical re-evaluation can take up to a couple of weeks.

Duplicate without user-selected canonical

What it means: Google found duplicate versions of a page, you didn't specify a canonical at all, so Google picked one itself and left the others not indexed.

Why it happens: no canonical tags on pages that have duplicates — URL parameters (?sort=, tracking tags), trailing-slash or upper/lowercase variants, session IDs, or the same content reachable at multiple paths, all with no signal from you about which is primary.

How Google looks at it: as filling in a blank you left — it made the canonical decision because you didn't. It's not always benign, because you've handed control of which URL ranks to Google.

What to do: take back control. Add an explicit rel=canonical tag to these pages pointing at the version you want indexed, so you decide instead of Google. Where the duplicates are pure noise (parameter URLs), consider handling them at the source. This is a “go add canonicals” task, not a leave-it-alone one.

How do you diagnose a single page with the URL Inspection tool?

The report tells you how many pages hit each status; the URL Inspection tool tells you why one specific page did. Paste any URL into the search bar at the top of Search Console and it runs a live diagnosis. The three things I check every time:

• Crawl allowed? / Page fetch: did Google's crawl succeed, or is robots.txt or a server error in the way?
• Indexing allowed?: is there a noindex tag secretly blocking it?
• User-declared vs Google-selected canonical: the definitive answer to any duplicate/canonical mystery — it shows the canonical you set and the one Google chose, side by side.

One catch worth knowing: for the two “currently not indexed” statuses, the live test can't magically reveal a quality decision — those aren't testable the way a broken tag is. But for everything “Website”-sourced, URL Inspection is the fastest way from “something's wrong” to “here's the exact reason.”

What do the Validation states (Not started, Started, Passed) mean?

Once you've actually fixed a “Website”-sourced issue, you tell Google to re-check by clicking “Validate Fix.” That's what the Validation column tracks:

The thing people get wrong: validation is for issues you've fixed. There's no point running it on a benign row like “Alternate page with proper canonical tag” — there's nothing broken for Google to re-confirm. Fix the real rows, validate those, and ignore the button on the rest.

The mistakes I see people make with the Page indexing report

After enough of these, the same handful of errors show up again and again. Avoid these and you're ahead of most:

How I catch these issues early with CrawlRaven

Here's the uncomfortable truth about the Page indexing report: it's a lagging indicator. By the time a status shows up with a page count next to it, Google has already crawled, judged, and excluded those URLs — and clawing them back into the index takes weeks. The whole game is catching the causes before they land in this report. That's exactly why we built CrawlRaven, and it's what I run on my own sites on a schedule. A few concrete examples of what it flags early:

• Redirect chains and loops — before they become a “Redirect error,” the 200-point crawl surfaces multi-hop chains and loops so you can collapse them to a clean single 301.
• Accidental noindex on money pages — the moment a template change or CMS setting slaps a noindex on a page that should rank, it's in your issues list, not silently dropped from Google weeks later.
• Canonical mismatches — pages whose canonical points at the wrong URL, or duplicates with no canonical at all, so you fix them before Google picks a canonical for you.
• Orphan pages and weak internal links — the number-one driver of “Discovered — currently not indexed.” CrawlRaven maps your internal link structure and flags pages Google will struggle to prioritize.
• Soft 404s, broken links, and 5xx errors — the technical breakage from the “fix now” column, caught on every crawl.
• Thin and duplicate content — by connecting Google Search Console data, you can spot the thin, cannibalizing, or decaying pages most likely to end up “Crawled — currently not indexed,” then fix or consolidate them first.

The report tells you what Google already decided. A continuous audit tells you what it's about to decide — while you can still change the answer. That's the difference between reacting to this report every quarter and rarely having a bad row on it at all.

Related reading on CrawlRaven

• How to Do Technical SEO With AI: My Step-by-Step Workflow
• How to Perform a Technical SEO Audit (step by step)
• Run a free 200-point technical SEO audit