If you have spent any time inside the Pages report in Google Search Console, you may have come across the status "Excluded by 'noindex' tag" sitting next to one of your URLs. The first time I saw this on one of my own posts, I genuinely thought I had broken something. It felt personal, almost like Google was rejecting my work outright.
It is not that dramatic. Once you understand what this status actually means, it becomes one of the easier issues to fix, mostly because the cause is sitting right there in your page's code, waiting to be found. In this post, I want to walk through exactly what this status means, why it shows up, and the steps that have worked for me when I have run into it.
What "Excluded by 'noindex' Tag" Actually Means
This status tells you that Google crawled your page successfully, read its HTML, and found a direct instruction telling it not to add the page to its index. That instruction is the noindex directive, and Google takes it seriously. According to Google's own documentation on blocking search indexing, when Googlebot crawls a page and finds a noindex rule, it will drop that page from search results entirely, even if other sites are linking to it.
This is different from a robots.txt block. With robots.txt, Google never even gets to read the page because it is told not to visit. With noindex, Google visits the page just fine, reads everything on it, and then chooses not to include it because you specifically told it not to. I went into the distinction between blocked crawling and blocked indexing in more detail in my post on fixing the blocked by robots.txt error, and the two issues are worth understanding side by side because the fixes are completely different.
The noindex directive usually shows up in one of two places. It can be a meta tag sitting inside the head section of your page's HTML, or it can be set through an HTTP response header. Google's documentation on robots meta tag specifications covers both methods in detail, and either one has the same effect on how your page is treated.
Why This Tag Ends Up On Pages You Did Not Mean To Block
Nobody sits down and deliberately blocks their own best content from Google. This almost always happens by accident, and once you have seen a few cases, you start to notice the same patterns repeating.
A Leftover Setting From a Staging or Test Version of Your Site
Many sites start out as a private test version before going live. It is common practice to noindex everything during that phase so search engines do not accidentally index half-finished pages. The problem comes when that setting is never switched off after the site goes public. I have seen this happen with entire blogs that launched with every page accidentally noindexed for weeks before anyone noticed.
A Theme, Template, or Plugin Change
Switching themes or installing a new plugin can sometimes introduce default settings you never asked for. Some themes ship with noindex tags applied to specific page types, like archive pages or paginated pages, and if you are not paying attention, that setting can carry over and apply more broadly than intended.
A Manual Setting You Forgot About
This is the one that caught me off guard the first time. On Blogger, individual post settings include a search description and custom robots tag option, tucked away under the post settings panel rather than anywhere obvious. I had adjusted that setting on an old post months earlier for a completely unrelated reason and forgotten about it entirely. When I finally noticed the post was excluded, it took a moment of confused scrolling through settings before I found the toggle sitting exactly where I had left it.
A Plugin or SEO Tool Defaulting to Noindex
On WordPress specifically, SEO plugins often include a setting that controls whether certain content types, like tag pages or author archives, get indexed. If these settings are misconfigured, or if a plugin update resets them, pages that were previously indexable can suddenly pick up a noindex tag without any direct action from you.
Pagination or Duplicate Content Settings
Some platforms automatically apply noindex to paginated versions of a page, like page two or three of a long comment thread or archive. This is usually intentional and not something to worry about, but it is worth knowing this exists so you do not panic if you spot it on a paginated URL rather than your actual posts.
Is This Always a Problem?
Not necessarily, and this is the part that took me a while to internalize. Whether this status is something to fix depends entirely on which page it is showing up on.
If the excluded URL is a blog post, a service page, or anything you have written content for and want people to find through search, then yes, this needs your attention. The page simply cannot appear in search results while that tag remains in place, no matter how strong the content is.
If the excluded URL is something like an internal search results page, a thank you page after a form submission, or a duplicate parameter-based URL, the noindex tag might be doing exactly what it should. In that case, the status in Search Console is more of a confirmation than a warning.
The real task is sorting your excluded URLs into these two buckets before you touch anything.
How to Check Whether a Page Has a Noindex Tag
Start With the URL Inspection Tool
Open Google Search Console and paste the affected URL into the URL Inspection tool. If the page is excluded because of a noindex directive, the tool will tell you directly, and it will usually specify whether the rule came from a meta tag or from an HTTP header. The Search Console Help documentation on the URL Inspection tool walks through every section of this report if you want to understand what each part is telling you.
View the Page Source Directly
Open the page in your browser, right click, and select view page source. Use your browser's search function to look for the word robots within the head section. If you see a meta tag with the word noindex inside it, that confirms the source of the problem. This method works even if you do not have Search Console access yet, which makes it a useful first check.
Check for an HTTP Header Version
Sometimes the noindex rule is not in the visible HTML at all. It can be set as an X-Robots-Tag in the page's HTTP response header instead, which means it will not show up when you view the page source the normal way. Browser developer tools, or a free header checking tool, can reveal this. This is a less common cause for blog platforms like Blogger or standard WordPress setups, but it does happen, particularly on sites with custom server configurations.
How to Fix "Excluded by 'noindex' Tag"
Once you have confirmed the tag is there and that you actually want the page indexed, the fix itself is usually quick. The harder part is finding exactly where the directive lives.
Step 1: Locate the Exact Source of the Tag
If you found it in the page source, check whether it is coming from your theme template, a plugin setting, or a manual override on that specific post. On Blogger, this typically means checking the individual post's search description settings. On WordPress, this usually means checking your SEO plugin's per-page indexing controls, since most modern SEO plugins give you a direct toggle for this on every post and page.
Step 2: Remove or Correct the Directive
Once you know where the setting lives, change it. On Blogger, this means switching the custom robots tag option back to the default indexable state. On WordPress, this usually means flipping the visibility setting in your SEO plugin back to allow search engines to index the page. Be precise here. Only change the setting for the specific page you are fixing, rather than making sweeping changes across your whole site, since some of those settings may be correctly applied elsewhere.
Step 3: Confirm the Page Is Not Also Blocked by Robots.txt
This step matters more than people expect. If a page is blocked by robots.txt at the same time it carries a noindex tag, Google may never actually see the noindex instruction, because it cannot crawl the page to read it in the first place. Google's introduction to robots.txt explains this overlap clearly, and it is worth checking your robots.txt file for the affected path while you are already in troubleshooting mode. If you find a conflict here, my post on fixing the blocked by robots.txt error covers how to identify and correct that separately.
Step 4: Test the Live Version of the Page
After making your change, go back to the URL Inspection tool and use the Test Live URL option. This checks the current, live version of your page rather than the older cached version Google has on file. If the noindex tag is gone, the live test should confirm that the page is now eligible for indexing.
Step 5: Request Indexing
Once the live test confirms the fix, use the Request Indexing option inside the URL Inspection tool. This tells Google to prioritize a fresh crawl of the page. It does not guarantee instant indexing, but it does move the page into the queue faster than waiting for a routine crawl to happen on its own.
Step 6: Be Patient With the Timeline
Removing a noindex tag does not mean your page appears in search results within minutes. Google still needs to recrawl the page, confirm the directive is gone, and then make its own decision about whether the content meets the bar for indexing. In my own experience, this has taken anywhere from a couple of days to a couple of weeks depending on how often Google was already crawling that part of my site. If you want to understand how crawl frequency affects this kind of timeline, I covered it in more depth in my post on why Google crawls your blog but does not index it.
What I Learned Going Through This Myself
The case that taught me the most was an older post on one of my blogs that had been sitting excluded for what I later realized was months. I had assumed it simply was not performing well in search, when in reality it was not eligible to appear at all. The noindex setting had been applied during an early round of testing on that post, and I had never gone back to confirm it was switched off before publishing it properly.
What stuck with me afterward was how easy it is to overlook a setting like this precisely because it is not loud. There is no broken page, no error message flashing at you when you visit the site. Everything looks completely normal to a human visitor. The only place this shows up clearly is inside Search Console, which is exactly why checking that report regularly matters so much, even when nothing seems obviously wrong.
I also learned to treat any settings page on a CMS with a bit more suspicion after a theme or plugin update. Things that worked correctly for months can quietly shift after an update touches a setting you were not even looking at.
Preventing This From Happening Again
A small habit goes a long way here. After publishing any new post, get into the routine of checking the page source or running it through the URL Inspection tool, just to confirm there is nothing unexpected sitting in the robots meta tag. It takes less than a minute and catches problems before they sit unnoticed for weeks.
It is also worth reviewing your CMS or plugin settings any time you make a structural change to your site, switch themes, or update a plugin that touches SEO settings. These changes do not always announce themselves clearly, and a quick spot check afterward is far less work than discovering a batch of excluded pages months later.
If you regularly work through other indexing statuses in Search Console, it also helps to understand how this one fits alongside the others. A page that is sitting as discovered but not yet indexed is in a completely different situation than one excluded by a noindex tag, even though both can feel equally confusing the first time you encounter them.
Finally
Seeing "Excluded by 'noindex' tag" in Search Console can feel discouraging at first glance, especially if it is sitting on a page you genuinely care about. But once you understand that this status simply means Google found an instruction you probably did not mean to leave in place, it stops feeling like a content problem and starts feeling like a settings problem, which is a much easier thing to fix.
Check the page source, confirm where the directive is coming from, remove it carefully, and then give Google a little time to catch up. Most of the time, that is genuinely all it takes. The frustrating part is rarely the fix itself. It is just finding where the setting was hiding in the first place.