Excluded by ‘noindex’ Tag: When It’s a Problem

By Amit Patel

“Excluded by ‘noindex’ tag” means Google crawled the page, found a noindex directive, and correctly kept it out of the index — so the status is a report that your instruction worked, not an error. The entire question is whether you meant it. For staging pages, thank-you pages, and thin archives, this is the system doing its job. The problem cases are the pages you actually want ranking that carry a noindex nobody remembers adding.

What the Status Means

Google fetched the page, saw a noindex in a meta robots tag or the X-Robots-Tag HTTP header, and excluded it from the index as instructed — crawling happened, indexing was declined on purpose.

This is fundamentally different from being blocked by robots.txt: there, Google never crawls; here, it crawls and then obeys a noindex it found. That distinction matters because noindex is the correct tool for keeping a page out of search, while robots.txt is not. The status appears in the Page indexing report under not-indexed, but its presence there is neutral until you confirm intent.

When It Is Intentional and Correct

Login and account pages, checkout and thank-you pages, internal search results, staging URLs, tag archives, and duplicate print or filter views are all legitimately noindexed — seeing them here is expected.

These pages serve users but add nothing to search, and noindexing them keeps your indexed footprint focused on pages that should rank. If everything in this status is a page you deliberately excluded, there is nothing to do — do not “validate fix,” do not remove the tags. A clean, intentional list here is a sign of good index hygiene, the same principle behind resolving canonical duplicates.

When It Is an Accident

The dangerous version is a page you want indexed sitting in this list — usually because a staging noindex shipped to production, a CMS setting applies noindex site-wide, or a plugin added it to a whole template.

The classic disaster is a site launched with WordPress’s “Discourage search engines” box still ticked, which noindexes the entire site. SEO plugins can also apply noindex to categories, tags, or custom post types by default, silently excluding pages you assumed were fine. Any sudden jump in this status’s count — especially right after a launch, migration, or plugin change — should be investigated immediately, because it directly removes pages from search. Treat a spike here with the same urgency you would a traffic drop in the Performance report.

Finding and Removing a Stray noindex

Inspect the URL, locate the noindex source (meta tag, HTTP header, or CMS/plugin setting), remove it at the source, then validate the fix and request re-indexing for priority pages.

The URL Inspection tool confirms the noindex and often shows whether it came from the HTML or the HTTP header — an X-Robots-Tag header is easy to miss because it is invisible in the page source. Trace it to its origin: a theme template, an SEO plugin’s post-type defaults, a server rule, or a global CMS toggle. Fix it there so the correction applies everywhere, not URL by URL. Then use “Validate fix” and, for important pages, request indexing to speed recovery. Google’s documentation on blocking indexing with noindex explains both the meta tag and header forms.

Frequently Asked Questions

The Bottom Line

This status is only as good or bad as your intent behind it. Audit the list once: if every URL is a page you meant to exclude, you are done. If a page you want ranking is hiding in there, treat it as urgent, trace the noindex to its source, and remove it there. Keep noindex and robots.txt in their separate roles and your index stays exactly as large as you designed it — a discipline the rest of the Search Console cluster supports.