Excluded by 'noindex' Tag in Google Search Console: What It Means (And When It's Not What You Intended)

Excluded by noindex tag usually means your own noindex directive is working correctly. Here's how to confirm that, and how to catch the cases where it isn't.

September 22, 2026 · 5 min read

If a URL shows up under Excluded by 'noindex' tag in the Page Indexing report, the short answer is: Google found a noindex directive on that page and did exactly what it says — left it out of the index. Most of the time that's not a problem to fix. It's a status to confirm, not an error to chase.

The confusion usually starts because "Excluded" sounds like something went wrong. In this specific case it almost never does — unless the page carrying the noindex tag is one you actually wanted searchable.

What This Status Actually Confirms

Unlike a soft 404 or a crawl error, this status isn't Google's judgment call about your content. It's Google reporting back a directive you (or your CMS, theme, or plugin) explicitly set. The tag can live in two places, and Search Console doesn't always make it obvious which one applied:

A <meta name="robots" content="noindex"> tag in the page's <head>
An X-Robots-Tag: noindex HTTP response header, set at the server level

Both produce the same result in the report, but they come from very different parts of your stack — one is a template setting, the other is often a server or CDN configuration. Fixing the wrong one leaves the tag in place and the URL stuck in this bucket indefinitely.

The Two Ways a Page Ends Up Here

Intentional — Login pages, admin routes, internal search-results pages, thank-you pages, staging subdomains, thin tag archives, and duplicate parameter URLs are commonly noindexed on purpose. If the flagged URL is one of these, the status is confirmation that your setup works, not a problem.

Accidental — This is the version worth investigating. It shows up in a few recognizable patterns:

| Cause | How it happens | |---|---| | CMS "discourage search engines" setting left on after launch | Common on WordPress sites moved from staging to production | | SEO plugin default applied to a whole post type | A blanket rule (e.g., all "product" or "guide" templates) catches pages that shouldn't be excluded | | Theme or boilerplate template carrying a stray noindex meta tag | Copied from a staging template and never removed | | CDN or reverse proxy injecting X-Robots-Tag globally | Header applied at the infrastructure level, invisible in page source |

Only the second group needs action. The first is the tag doing its job.

How to Tell Which One You're Looking At

Open the specific URL Search Console flagged and view page source (not a cached copy) — search for noindex in the <head>.
If it's not in the HTML, check response headers directly (browser dev tools, Network tab, or curl -I the URL) for X-Robots-Tag.
Ask whether this page's purpose requires it to be excluded from search. A /thank-you page: probably yes. A published blog post or product page: almost certainly no.
If the tag is unexpected, trace where it's set — theme template, SEO plugin setting, CMS visibility toggle, or a proxy/CDN rule — before removing it. Removing the symptom without finding the source means it can reappear on the next deploy.

Fixing an Accidental noindex

Once you've confirmed a page should be indexed:

Remove the noindex directive from wherever it actually lives (template, plugin setting, or server header) — not just the rendered HTML, since a header-level tag won't show up there.
Re-fetch the page after the change and confirm the tag is gone, in the actual response, not just in a cached preview.
Use URL Inspection's "Request Indexing" once the fix is live. Don't repeat the request on an unchanged page — it won't speed anything up and just adds noise to your quota.
Give it a few days to clear the Excluded status before assuming the fix didn't take; recrawl timing isn't instant.

If the page is meant to stay out of the index, no action is needed — but it's worth a quick pass to confirm the right pages are the ones carrying the tag, since blanket plugin rules and copied templates are the most common way an unrelated page picks one up by accident.

Why This Status Deserves a Periodic Check, Even When It's "Working"

Because this is a status confirming your own configuration rather than Google flagging a fault, it's easy to assume it never needs revisiting. That assumption is what lets accidental cases survive for months — a plugin update changes a default, a template gets reused for a new page type, or a staging header makes it into production during a migration. None of that throws an error anywhere; it just quietly grows the Excluded count.

It's also worth distinguishing this from the other statuses in the same report that look similar but mean something different: a soft 404 is Google overriding your status code based on content, not a directive you set, and "Discovered" vs. "Crawled — currently not indexed" is about crawl budget and indexing priority, not exclusion. Mixing these up leads to the wrong fix — you can't "request indexing" your way out of a noindex tag that's still live, the same way you can't fix a soft 404 by editing a robots directive.

Traffic Monitor pulls the Page Indexing report on a schedule and flags status changes — including pages that newly land under Excluded by noindex tag — so an accidental exclusion shows up close to when it happened instead of getting discovered weeks later during an unrelated audit. That matters more for this status than most others in the report, precisely because it never presents as an error on its own. It's the same coverage data that also surfaces duplicate pages without a user-selected canonical, so a single pass through the report tends to catch more than one of these classification issues at once.

The rule of thumb: if you can point to the reason a page is noindexed and agree with it, close the tab. If you can't immediately say why a specific URL has the tag, that's the one worth tracing back to its source.

Soft 404 in Google Search Console: What It Actually Means (And How to Fix It)

Google marks a page as a soft 404 when it returns a normal 200 status but looks empty or broken. Here's why that happens and how to fix it for good.

How to Test Your robots.txt File (Before It Silently Blocks Google)

How to test a robots.txt file for rules that accidentally block Googlebot, using Search Console, curl, and a robots.txt tester tool — and how to fix what you find.

Track your blog rankings automatically

Connect Google Search Console and get daily alerts, keyword research, and AI diagnostics — free to start.

Start free →