Excluded by Noindex Tag: Meaning and How to Fix It (2026)

"Excluded by 'noindex' tag" means Google crawled the URL, found a noindex rule on it, and left the page out of the index exactly as instructed. It is a status, not an error and not a penalty. Google is reporting your own configuration back to you. If the page was never meant to rank, nothing needs fixing. If it was, the rule is coming from somewhere you have not looked yet, and there are only two places it can live: the HTML of the page, or the HTTP response headers.

The reason this status causes so much damage relative to how simple it is comes down to how it spreads. Almost nobody adds a noindex to one page by hand and then forgets. It arrives through a template, a plugin default, a CMS toggle or an edge rule, so it lands on a whole section at once: every product variant, every paginated archive, every URL under one route. Traffic falls in a shape that looks like an algorithm update, and teams spend weeks rewriting content when the actual cause was one setting.

What does excluded by noindex tag mean?

In the Search Console Page indexing report, "Excluded by 'noindex' tag" is the reason Google gives for URLs it fetched successfully and then deliberately kept out of search results. The crawl worked. The page rendered. Google read a noindex rule and complied.

Google supports that rule in two forms, and both are equally binding:

• A robots meta tag in the HTML: <meta name="robots" content="noindex">
• An HTTP response header: X-Robots-Tag: noindex

The second one is where most investigations stall. A header noindex never appears in view-source. You can open the page, read every line of markup, find nothing, and the page will still be excluded because a CDN rule, a server config or a framework middleware is attaching the header to the response. If you have checked the HTML and come up empty, you have checked half the surface.

It is worth separating this status from the ones it gets confused with. "Blocked by robots.txt" means Google never fetched the page at all. "Crawled, currently not indexed" means Google fetched it and chose not to keep it, with no instruction from you. "Excluded by 'noindex' tag" is the only one of the three where Google is doing precisely what your site asked. That distinction decides the fix: the first two are diagnostic problems, this one is a configuration problem.

Is excluded by noindex tag bad?

It depends entirely on whether you meant it. A healthy site of any size has a solid block of URLs in this bucket, and that is correct. Internal search result pages, thank-you and confirmation pages, gated content, filtered and sorted variants, thin tag archives, staging environments, admin areas and user account screens all belong out of the index. Seeing a few thousand of them reported here is a sign the setup is working.

What matters is the composition. Open the report, sort the affected URLs, and ask one question of each pattern: was this deliberate? If the answer is yes for every group, close the tab. If a route you actively want ranking is sitting in the list, you have found a real problem, and it is almost certainly wider than the one URL that made you look.

Nothing about this status carries a penalty. Google is not marking your site down. It is not a quality signal. There is no accumulated damage from having noindexed pages, which is why the panic this report tends to cause is usually misplaced.

Why is my page excluded by noindex tag? The eight real causes

Cause	Where the rule lives	How to confirm it	Fix
WordPress "Discourage search engines" box left on	HTML meta tag, site-wide	Settings then Reading in wp-admin	Uncheck it. This is the single most common cause after a launch
SEO plugin per-post or per-archive setting	HTML meta tag	Yoast, Rank Math or SEOPress settings for that post type	Change the index setting for the affected post type or taxonomy
Staging config promoted to production	Either, usually a header	Compare response headers between environments	Make the rule environment-aware rather than shipped
CDN or edge rule adding X-Robots-Tag	HTTP header	curl -I the URL. Nothing shows in view-source	Remove or narrow the rule at the edge
Theme or page builder injecting its own tag	HTML meta tag	Rendered source, not the settings screens	Disable the theme option, or override in the template
Shopify or platform template conditional	HTML meta tag	Check theme.liquid and the layout for robots logic	Fix the conditional. Common on collection and vendor pages
Server config applied too broadly	HTTP header	Nginx or Apache config, or framework middleware	Scope the rule to the paths it was meant for
A deliberate noindex nobody documented	Either	Git history for the template or config	Decide whether it still applies, then document it

Notice how many of those are invisible from inside the CMS. The rendered response is the only source of truth, which is why "I checked the plugin settings and they look fine" is not a diagnosis.

How to find where the noindex is coming from

Work from the response backwards, not from the settings forwards. Three steps, in this order.

1. Read the actual HTML. Fetch the URL and search the rendered source for name="robots" and name="googlebot". Use the rendered source rather than view-source if the site relies on JavaScript, because a script can inject or remove the tag after the initial HTML loads. Google recommends the tag sits in the head, though it will honor one found in the body too, so search the whole document.

2. Read the response headers. Run curl -I https://example.com/your-page and look for an X-Robots-Tag line. This is the step people skip and the one that finds the causes nobody can explain. The header can also target a single crawler, in a form like X-Robots-Tag: googlebot: noindex, which produces the delightful situation where a page is indexed in Bing and missing from Google.

3. Confirm what Google saw. Run the URL through the URL Inspection tool in Search Console and use Test Live URL. That fetches the page as Google-InspectionTool and reports the indexing rules Google actually received, which settles any argument about whether a fix has deployed. Our URL inspection tool page covers the API limits if you want to automate this across a larger set.

For anything past a handful of URLs, checking one page at a time is the wrong shape of work. Because accidental noindex is template-wide, a sample of ten URLs will very likely miss it entirely or find it everywhere, and neither result tells you the boundary of the problem. Run the whole sitemap through a noindex checker that reads both the meta tag and the response header for every URL and pairs each result with live index status. The pairing is the part that matters: a page carrying noindex that is still indexed and a page with no noindex that is missing are two completely different problems with opposite fixes.

Fixing excluded by noindex tag in WordPress

WordPress accounts for a disproportionate share of these cases because it offers at least four places to set the same rule. Check them in this order.

Settings then Reading. The "Discourage search engines from indexing this site" checkbox applies a site-wide noindex. It gets ticked during development and untucked never. If your whole site is excluded, this is the first thing to look at and it takes ten seconds.

Your SEO plugin. Yoast, Rank Math and SEOPress each control indexing per post type, per taxonomy and per individual post. The defaults are opinionated: several of them noindex tag archives, author archives, media attachment pages and paginated results out of the box. Those defaults are usually sensible, but if you built a content strategy around category pages, the plugin may be quietly excluding them.

Individual post settings. Every SEO plugin adds an advanced panel on the post editor with its own index toggle that overrides the post-type default. One editor flipping it on a template post that later got duplicated is a classic origin story.

The theme or page builder. Some themes and builders inject their own robots meta tag, occasionally in addition to the plugin's, which produces two conflicting tags on the page. Google resolves conflicts by applying the more restrictive rule, so a page with both an index and a noindex ends up noindexed. Always verify against rendered source rather than trusting that one plugin is in charge.

If you are working through a broader WordPress visibility problem rather than this one status, our guide to indexing a WordPress site covers the rest of the checklist.

How long until the page comes back after you remove the noindex?

Removing the rule does nothing until Googlebot fetches the page again and sees the change. That can be hours for a URL Google visits often, or months for one it rarely does. Google is explicit that depending on a page's importance it may take a long time for Googlebot to revisit.

You can shorten the wait, though not eliminate it:

• Request indexing through the URL Inspection tool for the highest-value pages. It is rate limited to roughly a dozen URLs per day per property, so spend it on pages that matter.
• Make sure the URLs are in your XML sitemap with an honest lastmod reflecting today's change.
• Link the affected pages from pages Google already crawls often. Internal links do more for re-crawl speed than resubmission does.
• Confirm the pages are not also blocked in robots.txt, which would stop Google reading anything on them at all.

That last one deserves emphasis because it is the trap people walk into while fixing this. If a URL is disallowed in robots.txt and also carries a noindex, the disallow wins the race: Googlebot stops fetching, never reads the noindex, and any pages already in the index stay there indefinitely. The correct sequence when you want pages gone is to remove the disallow first, leave the noindex in place, wait for the drop, then re-add the disallow if you also want to stop the crawling. Doing both on the same day is why teams end up filing removal requests for pages they thought they had handled a quarter earlier.

Stopping it from happening again

This is a regression, not an incident. The same setting comes back with the next theme update, the next CDN rule, the next environment promotion, and by then nobody remembers the last time. Standard monitoring will not catch it either: a noindexed page still returns a healthy 200, renders normally and loads fast, so an uptime monitor reports everything green while the section quietly leaves the index.

Three habits close the gap. Make the noindex rule environment-aware in code, so staging carries it and production cannot, rather than relying on somebody remembering to flip a switch at launch. Add a post-deploy check that fetches a few canonical URLs from each major route and fails the build if a robots rule appears where it should not. And run a scheduled coverage check across the full sitemap that pairs directives with real index status, so a template change shows up in days rather than at the next quarterly review. You can check whether a page is indexed on demand, but the value is in the schedule, not the spot check.

Which pages should stay excluded

Before you go removing noindex rules, keep the ones doing useful work. These belong out of the index on almost every site:

• Internal search result pages, which Google has discouraged indexing for years
• Thank-you, confirmation and post-checkout pages
• Login, account, cart and admin screens
• Filtered, sorted and faceted variants of a category that add no unique content
• Thin tag or author archives with a handful of posts
• Gated or paywalled content you do not want previewed
• Staging, development and preview environments

One caveat on the faceted case. If you have thousands or millions of filter combinations, noindex is the wrong tool, because Googlebot still has to fetch each URL to read the rule. That costs crawl capacity you wanted spent on product pages. Block those patterns in robots.txt instead and reserve noindex for pages that genuinely need to stay fetchable. The broader trade-off is covered in our notes on crawl budget optimization.

Frequently asked questions

What does excluded by noindex tag mean?

It means Google crawled the URL, found a noindex rule in either the HTML robots meta tag or the X-Robots-Tag response header, and kept the page out of the index as instructed. It is a report of your own configuration rather than an error. No penalty is attached, and if the page was never meant to rank, no action is needed.

How do I fix excluded by noindex tag?

Find and remove the rule, then get the page re-crawled. Search the rendered HTML for name="robots", run curl -I on the URL to check for an X-Robots-Tag header, and check your CMS and SEO plugin settings. Once the rule is gone, request indexing in Search Console, confirm the URL is in your sitemap, and link it from pages Google crawls often.

Does excluded by noindex tag hurt my rankings?

Not directly. The status carries no penalty and does not affect how the rest of your site is evaluated. The only harm is the traffic the excluded pages themselves cannot earn, which is total for those URLs. It becomes a serious problem only when the exclusion is accidental and covers pages you intended to rank.

Why is my page excluded by noindex tag when I cannot find the tag?

The rule is almost certainly in the HTTP response headers rather than the HTML. An X-Robots-Tag: noindex header is invisible in view-source and is commonly added by a CDN rule, a server config or framework middleware. Run curl -I on the URL to see it. The other possibility is JavaScript injecting the tag after the initial HTML, which only shows in the rendered source.

How long does it take to fix excluded by noindex tag?

The edit takes minutes. Recovery depends on when Googlebot next crawls the page, which ranges from hours for frequently visited URLs to months for rarely crawled ones. Requesting indexing in the URL Inspection tool is the fastest path for a small number of important pages, and internal links from often-crawled pages do more for the rest than repeated resubmission.

Is excluded by noindex tag the same as blocked by robots.txt?

No, and they behave in opposite ways. Blocked by robots.txt means Google never fetched the page, and such a URL can still appear in results listed without a snippet. Excluded by noindex tag means Google fetched the page, read your instruction, and removed it from results entirely. A page that is both blocked and noindexed keeps the worst of each: Google cannot read the noindex, so an already-indexed URL stays indexed.

The short version

Treat this status as an inventory question rather than an alarm. Sort the affected URLs by pattern, confirm each group was deliberate, and act only on the ones that were not. When you find an unintended one, check the response headers as carefully as the HTML, expect the cause to be template-wide rather than page-specific, and fix the environment logic so it cannot ship again. Then check the whole sitemap rather than the page that made you look, because the URL you noticed is rarely the only one affected.