Google Search Console

"Excluded by 'noindex' Tag": What It Means and How to Fix It

This status means Google found an explicit noindex directive on the page and obeyed it. The fix is finding which of two places it came from, since one of them is invisible in the page source.

SearchOptimo Team7 min read

"Excluded by 'noindex' tag" means Google's crawler found an explicit instruction on the page telling it not to index the page, and it did what it was told. The page will not rank while that instruction is active. Nothing else is wrong with the page technically: it was reachable, it was fetched, and Google simply respected a directive you (or something in your stack) put there. The only real question is whether you meant it.

What the status literally means

This status sits in the "Excluded" section of the Page Indexing report, not the "Error" section, because from Google's perspective nothing failed. The crawl succeeded. Google read the page, found a noindex directive, and complied by leaving the page out of the index. It is a compliance record, not a diagnostic of something broken.

That distinction matters for how you triage it. A 404 or a server error means Google couldn't get the page. This status means Google got the page just fine and was told to exclude it anyway. If the page matters to you, the fix is entirely about removing an instruction, not repairing a crawl problem.

This is one of several statuses in that report that look alarming and often are not. For the full sort of which ones need action and which are Google confirming your setup worked, see every Google Search Console indexing status and whether to act.

The two places a noindex can come from

A noindex directive reaches Google through one of two mechanisms, and they behave very differently when you go looking for the cause.

The HTML meta robots tag. This is the one most people know about:

<meta name="robots" content="noindex">

It sits in the <head> of the rendered page, so it's visible in "View Source" or in the URL Inspection tool's rendered HTML. Most people find this one quickly because they know to look for it.

The X-Robots-Tag HTTP header. This is the one people miss, because it never appears in the page's HTML at all:

X-Robots-Tag: noindex

It's sent as part of the server's response headers, alongside things like Content-Type and Cache-Control, before the browser ever renders the page. A page can have a completely clean <head>, no meta robots tag anywhere in sight, and still be excluded because the header is doing the work upstream. This is the reason a developer can stare at a page's source for ten minutes, conclude "there's no noindex here," and be wrong.

The usual accidental causes

When this status shows up on a page you actually wanted indexed, the cause is almost always one of these, roughly in order of how often they turn out to be the culprit:

  • A staging or development setting that shipped to production. Many frameworks and hosting setups apply a blanket noindex on non-production environments so search engines don't index a staging copy. If that environment variable or config flag doesn't flip correctly on deploy, the noindex ships with it.
  • A CMS or SEO-plugin toggle. WordPress's own "Discourage search engines from indexing this site" setting, or a per-post/per-page noindex toggle in an SEO plugin, gets checked by mistake or inherited from a template default.
  • A theme or template default. Some page templates (a specific post type, a category archive, a landing page builder) are configured to noindex by default, and a page built from that template inherits it without anyone deciding so for that specific page.
  • A header set at the CDN or server level. A CDN rule, a reverse proxy config, or an .htaccess/server block can inject X-Robots-Tag: noindex for a whole path pattern, a whole subdomain, or under specific conditions like a query parameter, independent of anything in the HTML.
  • A sitewide rule excluding a page type. A rule meant to noindex one category (say, internal search results or a staging subfolder) is scoped too broadly and catches pages that should have been left alone.

How to find which one applies to you

Start with the URL Inspection tool in Search Console. Paste the affected URL and look at the "Indexing" section: it will tell you the page is excluded by a noindex tag and, under "Page availability," it typically distinguishes whether the directive was read from the HTML or the HTTP response. Use "Test Live URL" to confirm what Google sees right now, not what was true the last time it crawled.

If the tool's detail isn't conclusive, check both places directly and separately. Don't stop after checking just the HTML, since a clean <head> tells you nothing about the header.

How to check the X-Robots-Tag header

Because this is the cause people miss, check it explicitly rather than assuming it's absent. The header lives in the server's response, not the page content, so you need a tool that shows response headers rather than rendered HTML.

  • In a browser, open DevTools, go to the Network tab, reload the page, click the document request (the top-level HTML request, not a script or image), and look at the Response Headers list for an entry named X-Robots-Tag.
  • From the command line, a request that prints response headers (for example curl -I against the URL) will list every header the server sent, including X-Robots-Tag if one is present.

If you find it there and the HTML <head> is clean, the fix is on the server, CDN, or proxy config, not in your CMS or template.

How to fix it and get the page re-crawled

Once you've found the source, remove it there specifically: delete the meta tag from the template or plugin setting, or remove the header rule from the server/CDN config. Don't fix both preemptively if only one is present; changing configuration you don't need to touch just adds risk.

After removing it, confirm with "Test Live URL" in URL Inspection that the noindex is actually gone, then use "Request indexing" from that same tool. Google still recrawls and re-evaluates on its own schedule, so this speeds up the queue rather than guaranteeing an immediate reindex. If the page doesn't move after a couple of weeks, it may be sitting in crawled, currently not indexed or discovered, currently not indexed instead, which are quality and crawl-budget problems rather than directive problems. If you're not sure noindex was your only issue, the broader Google is not indexing my site guide walks through the other six reasons in priority order.

When noindex is correct and should stay

Not every instance of this status is a mistake. Some page types are genuinely better excluded, and removing the tag would just create index bloat with no upside:

  • Thin tag or filter archive pages that exist only to slice existing content by attribute, with no independent content of their own.
  • Internal search results pages, since indexing a site's own search output creates near-infinite low-value URLs.
  • Duplicate paginated states, where page 2, 3, and beyond of an archive add no unique value over page 1.
  • Private or utility pages: account settings, checkout confirmations, thank-you pages, internal tools, staging previews meant to stay unlisted.

If a page has no query anyone should land on it for, leave the noindex in place. The fix described above is for pages you want ranking, not a reason to strip noindex from every page that carries one.

Catching the next one

The accidental cases above share one trait: they're invisible until someone checks, and a header-level noindex is invisible even in the page source. A single deploy that flips an environment flag, or a CDN rule scoped a little too wide, can noindex a whole section of a site without anyone noticing until traffic drops. SearchOptimo re-checks index status on a schedule and alerts when a page drops out, which is how an accidental sitewide noindex gets caught in days rather than months. Start a free trial to watch your pages instead of finding out the hard way.

Frequently asked questions

What does "excluded by 'noindex' tag" mean in Google Search Console?
It means Googlebot crawled the page, found an explicit instruction telling it not to index the page, and obeyed that instruction. The page will not appear in search results while the directive is in place. The only question worth asking is whether you put that instruction there on purpose.
Is "excluded by noindex tag" a bug or is it working as intended?
It depends entirely on the page. For a private, thin, or duplicate page, this status is the system working correctly. For a page you want to rank, it means something in your CMS, theme, server, or CDN is emitting a noindex you did not intend, and it needs to be removed.
Why is my page excluded by a noindex tag when I never added one?
The most common causes are a staging or development configuration that shipped to production, an SEO plugin toggle set to noindex a page type by default, a theme or template default, a header added at the server or CDN level, or a sitewide rule that excludes a category of pages you didn't realize included this one. None of these require you to have written a meta tag yourself.
How do I check if noindex is coming from a header instead of the HTML?
Fetch the page's raw response headers rather than reading the rendered page. A browser's "View Source" only shows the HTML body and will not show an X-Robots-Tag header, so a page can look completely clean in the source while a noindex header from the server or CDN excludes it anyway. Checking headers directly is the only reliable way to rule this cause out.
How do I fix "excluded by noindex tag" and get the page reindexed?
Remove the noindex, whether it's in the HTML meta tag or the X-Robots-Tag header, confirm it's gone by testing the live URL in the URL Inspection tool, then use "Request indexing" from that same tool. Google still has to recrawl and re-evaluate the page on its own schedule, so removing the tag doesn't index the page instantly.
Should I ever leave a noindex tag in place?
Yes. Thin tag or filter archive pages, internal search results pages, duplicate paginated states, and private or utility pages (account settings, thank-you pages, staging previews) are usually better left out of the index. If the page has no independent search intent behind it, a deliberate noindex is the correct call, not a mistake to fix.

Monitor your index status automatically

SearchOptimo re-checks your URLs on a schedule and alerts you when something drops. Start free, no credit card.

Start free

Keep reading