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

Open Google Search Console, scroll to “Why pages aren't indexed,” and it is easy to panic. You see a list of official-looking statuses: Page with redirect, Crawled – currently not indexed, Alternate page with proper canonical tag, each with a number next to it. It all looks like something you broke.

I have looked at this screen on my own sites and on dozens of others. Here is the main thing to know: most of these are not emergencies, and several are Google working the way it should. The skill is not fixing every line. It is knowing which few lines matter and which ones you can leave alone.

Here is the report we are going to break down, line by line:

For every status, I answer the same four questions: What does it mean? Why did my page land here? How does Google see it? And what should I do? If you just want the fast version, the table below has the answer for all 12 statuses. The rest of the guide explains each one in plain English.

What is the Google Search Console Page indexing report?

The Page indexing report is Google's list of every URL it knows about on your site, and whether each one is in the index. If a page is not in the index, it cannot show up in Google Search at all.

• Indexed. The page is in Google's index and can show up in search.
• Not indexed. The page cannot, for one of the reasons listed in the report.
• Formerly “Index Coverage.” Same report, new name.
• Formerly “Excluded” and “Error.” In late 2022 Google merged those two groups into the single “Not indexed” status, so an older post about “Excluded” pages describes the reasons you see under “Not indexed” today.

So this report is the line between “my page can rank” and “my page is invisible.”

Does “not indexed” mean my page is broken?

No. This is the most important idea in the whole guide. “Not indexed” does not mean “error.” Google's own help docs say it plainly: not every page Google crawls will be indexed.

• Left out on purpose. Duplicates, redirects, alternate versions, and pages you told Google to skip. That is Google doing its job, not failing.
• Most of the count is benign. In the report above, the 12 redirects and 9 alternate-canonical pages are the bulk of the “problem,” and both are Google following your own site's instructions.
• The rows that need you are the small share. A redirect error, a couple of 404s, 8 crawled-but-not-indexed.

So do not try to get this list to zero. A healthy site always has “not indexed” pages. The job is to tell the real problems from the noise, and two simple ideas do that.

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

The Source column is the most useful and most ignored part of the report. It tells you who is responsible for a page not being indexed, and so, who can fix it.

This one thing saves hours, so I always read the Source column first:

• Website. The cause is on your side: a redirect to fix, a 404 to bring back, or a stray noindex to remove. These rows are my to-do list.
• Google systems. Google made the call about quality, crawl priority, or which duplicate to keep. You can send better signals, but no button forces it. These rows are my investigate-and-improve list.

I call this the Source-First Triage, and the next section turns it into a simple sort.

Which not-indexed reasons should you actually fix?

Here is the whole report sorted the way I work through it. I call it the Source-First Triage: read the Source column, then drop each row into one of three buckets, fix now, look into it, or usually fine. If you save one image from this guide, save this one.

See the pattern. The fix-now column is technical breakage: broken redirects, server errors, real 404s. Quick and clear. The look-into-it column is quality and crawl stuff that moves slowly and has no quick button. The usually-fine column is Google doing its job. Not sure where a single page falls? Walk it through this quick decision tree:

Now let's go through every status, grouped by that Source column.

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 Google) to a different page, so Google keeps the destination page and not this one. The redirecting URL is, correctly, left out.
• Why it happens: normal site changes. You moved from http:// to https://. You added a trailing slash. You retired an old post and pointed it to the new one. You merged example.com and www.example.com. Each one creates a “Page with redirect” entry, and that is fine.
• How Google sees it: as normal, not a problem. It followed your redirect and kept the right page.
• What to do: almost always nothing. Only step in if (a) a page you want indexed shows up here, which means it is redirecting by mistake, or (b) you find long redirect chains (A to B to C to D), which slow crawling down. Shorten 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 that points to a different page as the “master” version, and Google indexed that master instead. This is canonicalization working the way it should.
• Why it happens: you have duplicate or near-duplicate URLs, and you correctly told Google which one is primary. Common examples: a product page at /shoes?color=red and /shoes?color=blue that both point to /shoes; a print version; an AMP page pointing to its normal version; or page 2, 3, and 4 pointing to page one.
• How Google sees it: as a job done right. It found your canonical tag, obeyed it, and kept the version you asked for.
• What to do: in most cases, nothing. This is one of the safest statuses in the report. Only look closer if a page you actually want ranking is stuck here (its canonical points at the wrong URL), if the count is far bigger than your real page count, or if canonicals point at URLs that do not exist. Spot-check a few with URL Inspection. If the canonicals are right, 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 sees 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 sees 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 on whether the page should exist. If it should (you deleted it by mistake, or it has value and inbound links), bring it back, or 301-redirect it to the closest live page. If it should really be gone, a 404/410 is the right answer, just find any internal links still pointing at it, so you stop sending Google and users to a dead URL. Do not redirect every 404 to your homepage out of habit; that creates soft 404s (the 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 sees 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 sees 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 tells Google not to crawl the URL. One catch: blocking crawling is not the same as keeping a page out of the index. Google can still index a URL it cannot crawl if enough other pages link to it. It just cannot 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 sees 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 sees 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 are not about a broken tag. They are Google deciding not to index a page, based on quality, crawl priority, or duplicates. There is no switch to flip. You work by sending better signals.

Before you try to fix any of these, ask one question: do I even want this page in Google? A lot of not-indexed pages are ones you should not care about:

• Terms and conditions, and privacy policy pages.
• Thin landing pages built for ads.
• In-app or account pages that got picked up by accident.

If a page does not need to rank, leave it and move on. Save your energy for the pages that bring in traffic and revenue.

Two of these statuses, Discovered and Crawled – currently not indexed, get mixed up all the time. This picture shows the difference:

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 a link) but has not fetched it yet. The tell in URL Inspection: the last-crawl date is empty. This is a crawl-priority problem, not a page-value one.
• Why it happens: Google's Martin Splitt gave three reasons in Google's “SEO Made Easy” series (the video is at the top of this post). First, quality: if Google has seen a lot of thin pages on your site, it may hold off on crawling more URLs that look the same. Second, server speed: if your server looks slow, Google slows down so it does not overload you, and crawls your pages over a longer time. Third, it may just need more time. The URL is in line and Google has not reached it.
• How Google sees it: as a priority call. John Mueller has said that when many of your pages sit here, the fix is usually not in those exact URLs. It is in the overall quality and structure of the site. Also worth knowing: Gary Illyes has said about 90% of sites never need to worry about crawl budget. So for most sites, this is a quality and internal-linking signal, not a “crawl budget” one.
• What to do: send stronger signals so Google wants to crawl these pages. Add internal links from strong pages that are already indexed (orphan pages with no internal links are a top cause). Improve site-wide quality so your pages do not look low-value. Keep your sitemap clean, only live, canonical URLs: if this count jumped after a release, diff the current sitemap against the previous one in our sitemap comparison tool and you will usually find a regenerated file that added a few thousand URLs nobody asked for. Fix crawl traps like endless filter URLs. And make sure your server is fast. This moves slowly, over weeks or months, so be patient and do not 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 is a real crawl date) and then chose not to index it, at least for now. It saw the page and decided it was not worth adding. This is a value call, and it is the one that hurts the most.
• Why it happens: almost always content quality, and usually not just this one page. Thin content, content that copies what is already out there, mass-produced or barely-edited AI pages, or a page that adds nothing new. Weak internal links and a site that does not look high-quality overall make it worse.
• How Google sees it: as a choice. Crawling a page never guarantees it gets indexed. John Mueller has said clearly that Google does not index everything, and that when pages pile up here it is usually a site-wide quality signal, not a problem with each URL. Martin Splitt has said much the same: Google may drop pages when it sees a pattern of thin or low-quality content. In short, Google is telling you this content has not earned a spot.
• What to do: raise the quality bar. Make these pages more useful, deeper, and more different from what already ranks, or combine several thin pages into one strong page. Add internal links from good, related pages on your site.

Then check one technical thing: can Google see your content without running JavaScript? Google can render JavaScript, but rendering is queued and not perfect.

• Read the raw HTML. View the page source, not the inspected DOM, and confirm the actual content is there. If your main text and links only appear after JavaScript runs, that is a real risk here.
• Render it on the server. If the content is missing from the source, server-side render it (SSR) or pre-render it so it is there on the first load. This removes all doubt.
• Only then request a re-crawl. Once the page is genuinely better and visible without JavaScript, use URL Inspection.
• What not to do. Do not click “Request indexing” over and over, because it will not beat a quality decision, and do not delete the pages in a panic.

Fixes here take weeks to months. 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: Google allows this because, in its own words, a rel=canonical tag is a hint, not an order. Google groups pages it sees as duplicates and picks the one it thinks is most complete and useful. It weighs 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 causes: mixed signals across your site, near-identical pages, or a canonical that points one way while your other signals point another.
• How Google sees 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 sees 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.”

URL Inspection only works on a property you own, and it checks one URL at a time. When you need the same verdict on a competitor's page, a staging URL, or a page before it ships, run it through our free page indexability checker. It reports the status code, noindex tags and X-Robots-Tag headers, robots.txt rules, the canonical, sitemap membership, and the rendered content in one pass, which covers every “Website”-sourced cause in the table above.

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

The Validation states track Google re-checking an issue after you fix it. Once you have fixed a “Website”-sourced problem, you click “Validate Fix,” and this column shows how that re-check is going:

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:

My honest take: what's really going on with indexing in 2026

Everything above is the official, verified answer. Now here is my opinion, based on what I and other founders are seeing. Take it as a point of view, not gospel.

Indexing in 2026 is stricter than it used to be, and it does not stop once a page is in. Google keeps re-judging value, and it will drop a page it once kept:

The biggest shift is that Google is harsher on low-value pages than it was two years ago. Templated programmatic pages get hit first, but plain content pages with no links and no brand behind them are not safe either.

• Where I agree with the popular take. The real fix is partly brand and authority: people searching for your name, mentions and links from other sites, and trust signals beyond your own domain. Those genuinely help borderline pages get indexed and stay indexed.
• Where I push back. The strong version of that claim, that brand is the only thing that matters and content sites are dead, goes too far. Plenty of pages sit in “not indexed” for boring, fixable reasons: a stray redirect, thin content, a missing canonical, or a page that only renders with JavaScript. Brand does not fix those; the basics in this guide do.

The honest answer is that both matter: get the technical and content basics right first, then build real brand and authority on top.

How I catch these issues early with CrawlRaven

Here is the hard part about the Page indexing report: it is a lagging signal. By the time a status shows up with a page count next to it, Google has already crawled, judged, and dropped those URLs, and getting them back in takes weeks.

The real goal is catching the causes before they land in this report. That is why we built CrawlRaven, and it is what I run on my own sites on a schedule. A few 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