All articles
Technical SEO

Why 40% of Your Pages Are Noindexed (and Don't Know It)

Launch at Dawn Editorial

Launch at Dawn Editorial

Technical Editorial

Oct 11, 2026

7 MIN read

Why 40% of Your Pages Are Noindexed (and Don't Know It)

I was auditing a client's site and saw something that made me stop: nearly half their pages were noindexed. It wasn't a judgment call about thin content. It was a diagnostic chart filled with pages they'd spent real money creating — service pages, product pages, guides. All of them quietly removed from the index by a directive nobody remembered placing.

Noindex is the sneakiest lever in SEO. It takes nothing to apply, nothing to forget, and it does enormous damage silently. Most of the time, the page isn't supposed to be noindexed at all. And because a noindex is the single most common reason a perfectly good page can't rank, this audit belongs near the top of any technical SEO checklist.

What noindex actually does

A noindex is an instruction to search engines: don't put this page in the index, so it can't appear in organic results. It's a valid tool used correctly (thank-you pages, admin areas, thin printer-friendly views), and a slow-motion disaster used by accident. The directive arrives one of three ways:

  • A <meta name="robots" content="noindex"> tag in the page's head — the version embedded in content.
  • An X-Robots-Tag: noindex HTTP header — the version a server sends, which can be applied site-wide without touching a single template.
  • A Disallow in robots.txt — strictly speaking a crawl block rather than a noindex, but it produces the same observable outcome: the page can't be indexed.

Each travels a different path into your site, which means each has a different source to trace when you find it. That's worth remembering, because one of the reasons noindexed pages are so easy to miss is that they show up nowhere as an "error" — the pages just quietly don't perform.

How noindex gets there by accident

The causes are mechanical, which is what makes them worth hunting — here's the list our technical SEO engineering team checks first:

The accidental causes are predictable, which means they're findable:

  • A "hold new pages until we review them" setting — common in CMS staging and review workflows — that defaults new content to noindex and never gets flipped when the page goes live. Your best new content stays invisible indefinitely, and nobody on the content team knows the switch exists.
  • A staging rule that leaked to production. A robots directive meant for a test environment carried over to the live site via a shared template or header. This is the whole reason we tell clients to never let staging configurations ride along on the deploy — and why it's the classic migration killer.
  • A site-wide X-Robots-Tag header. One misconfigured HTTP header can noindex every page, including the one you consider your home page. We've seen an entire commerce site pulled from the index by a header that was supposed to block a staging subdomain.
  • A previous developer's shortcut. Someone noindexed a section to hide it from index bloat years ago, and the business has long since changed what that section contains. The directive quietly outlives its purpose.

None of these surface as an "error." That's the danger. Noindex looks like success until traffic tells you otherwise — and by then, the pages have been absent from search for months.

Why the symptoms point somewhere else

Here's the trap that makes the silent noindex especially insidious: the page isn't missing from your site, it isn't broken, and — this is the kicker — the CMS still lists it as live and healthy. So when a service page underperforms, the natural diagnosis is "bad content" or "weak links," not "this page was never allowed to exist in search." We've seen clients spend months rewriting copy for pages that a stray header had quietly killed. Before you rewrite anything, check whether the page is even allowed to compete. If it's noindexed, the copy was never the problem.

Signal crowding matters here too. When a site's indexation report shows dozens of pages excluded by noindex, the competent pages alongside them don't look healthier by comparison — Google just sees a site that's suppressing a large share of its own content, which is exactly the kind of signal that feeds thin-site assessments. Fixing accidental noindexes is often the cheapest "content improvement" a site can make.

How to audit yours in one pass

Run this once and you'll see the whole picture:

  • Check the indexation report. Search Console's page indexing section lists pages under "Excluded by noindex." That's your starting list of suspects — not a judgment, just the population.
  • Separate intent from accident. For each noindexed URL, ask two questions: was this meant to be private, and is it meant to rank? Private, thin, or duplicate pages are correctly noindexed. Everything else is a candidate to restore. If you're unsure whether the page deserves ranking, the test is simple: would a searcher want this page as the answer? If yes, it should be indexable.
  • Trace the source. Inspect the page: is the noindex in the meta tag, the header, the response, or a template default? The source tells you how to fix it without it recurring. A content-level fix (edit the page) is different from an infrastructure-level fix (edit the header), and mixing them up is how these things return.
  • Check your defaults. The highest-leverage fix is changing the default so new pages are indexable unless you explicitly opt them out — not the other way around. Inquiry happened once; the default is what recreates it for every future post you publish.
  • Verify with a raw fetch. Don't trust the rendered page alone — a noindex can hide in a header you can't see on screen. Fetch the page with a tool that shows response headers, and grep for noindex across your templates and server config as well — then confirm the request arrives the way you think by sampling the raw server logs.

The traffic math of an invisible page

To see why accidental noindexes deserve a slot in the revenue conversation, do the math on a single page. Say one service page was quietly noindexed eighteen months ago. At the time it was getting 150 organic visits a month and a 2% conversion rate.

  • 150 visits × 18 months = 2,700 lost visits, almost all of them people actively searching for the exact service you sell.
  • At 2% conversion and a $1,500 average order, that's $81,000 in lost revenue from one page alone.
  • Widen it across the four or five service pages caught in the same directive, and the total dwarfs what most small businesses earn from organic search in an entire year.

None of that surfaced as an error, a warning, or a report until someone actually inspected the indexation data. Noindex is dangerous precisely because it doesn't decay on its own: a broken schema silently loses a rich-result badge, but a noindex literally removes the page from the competition and keeps it out until you look. And because the fix is binary — restore the directive, re-request indexing, and the page rejoins the race it was excluded from — it's one of the few SEO repairs with a near-instant payoff. That's why the audit is a revenue reconciliation, not a housekeeping chore.

Decision rules that keep you honest

Restoring a noindex isn't automatically right. A public order-confirmation page noindexed on purpose is fine. A service page noindexed by a forgotten default is wasted effort. So restore the ones with real traffic potential — the pages people actually search for and would click — keep the ones that exist because they shouldn't rank, and fix the underlying default regardless.

For a deeper dive, see our guide on site architecture for topical authority.

For a deeper dive, see our guide on understanding crawl budget.

The restored pages also need the support structure to actually rank once Google lets them. A page that's had its directive removed goes back into the exact same competition it was hiding from: it needs internal links carrying it, clean canonicalization so the right URL stands up, and content distinct enough to justify its place. If restoring a dozen pages is your goal, this is also the moment to check whether you're being hampered by pages that were noindexed for being thin — the distinction between "accidentally removed" and "correctly suppressed" is the entire game here.

The one-time check, then the habit

Run this audit once and you'll likely be shocked at what you find — on a lot of sites, the fix alone produces a bump in indexed pages and a session of "oh, that's why that page never ranked" in the reporting call. Then stop the bleeding permanently: make noindex the exception, not the default, and review your indexation report on a schedule instead of in a panic. Pair that habit with the other index killers you control — canonicals that merge pages you wanted separate, and internal link structures that bury the pages you're trying to promote — and, with our indexing guide filling in the rest, the index stops being a mystery and starts being a ledger you run.

Want to see how much of your own site is quietly noindexed and which of it should be ranking? book a free website teardown and we'll pull the report and separate your accidental losses from the deliberate calls — and tell you which of them are costing you the most traffic.

Launch at Dawn Editorial

Written by Launch at Dawn Editorial

Practical lessons from Launch at Dawn's field work in technical SEO — no fluff, just what actually moves rankings.

Work with us
Blog FAQ

Frequently Asked Questions

Noindex is a directive telling search engines not to include a page in their index, so it can't rank for organic searches. It's fine for private or low-value pages, but it's destructive when it gets applied by accident to pages that should be driving traffic.