Fix library

How to fix an accidental noindex tag

The Brimm team · grounded in the docs

You fix an accidental noindex by removing the rule from the 2 places it can live, a <meta name="robots"> tag in the HTML or an X-Robots-Tag HTTP header, then asking Google to recrawl the page. Google's noindex documentation also names the trap that keeps the fix from working: “For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file.” Unblock the page first, then remove the tag, then request indexing.

The symptom: pages quietly vanish from Google

The page exists. It loads for you, it loads for your customers, and it has vanished from Google. A site: search does not show it. Search Console files it under “Excluded by noindex tag.” If the tag sits on your homepage, the whole site can drop out over a few weeks as Google recrawls and obeys, one URL at a time.

This is the most binary failure in SEO. There is no partial credit and no ranking factor to argue about. A noindex is a direct instruction to remove the page from search results, and Google follows it. The cruel part is that nothing looks broken. No error, no warning in the browser, no downtime alert. Traffic just bleeds out while the site appears perfectly healthy.

The cause: noindex ships by accident all the time

Nobody types a noindex into their money pages on purpose. It arrives through side doors:

A staging or development site was correctly noindexed, and those settings shipped to production with the launch. This is the classic. The checkbox that protected the build now kills the live site.
A CMS toggle. WordPress has a single checkbox, “Discourage search engines from indexing this site,” that writes a noindex onto every page. Other platforms bury a similar switch in privacy or visibility settings.
An SEO plugin default. Many plugins noindex categories, tags, archives, or whole post types out of the box. A settings import or an update can flip a template you cared about.
A server or CDN rule. The X-Robots-Tag header can be set in nginx, Apache, or an edge worker for a path pattern, and it never appears in the HTML at all. You can stare at view-source forever and see nothing wrong.

That last one matters. The header form is invisible in the page source, which is why site owners miss it. Google treats the header and the meta tag identically, per the same documentation, so you have to check both.

The fix: find it, remove it, request a recrawl

First, confirm where the rule lives. View the page source and search for “noindex” in the head. Then check the response headers, because the tag may not be in the HTML:

# Check the HTTP headers for the invisible version
curl -sI https://example.com/page | grep -i x-robots-tag

<!-- The HTML version, sitting in the <head> -->
<meta name="robots" content="noindex" />

<!-- What the head should carry once fixed (or simply no robots meta at all) -->
<meta name="robots" content="index, follow" />

Then work backward to the source. If it is in the HTML, the culprit is a CMS setting, a theme, or an SEO plugin, and the fix is flipping the setting, not hand-editing a template that will be overwritten. If it is in the header, check your server config and CDN rules for X-Robots-Tag. Remove the rule everywhere it appears. One surviving copy keeps the page out.

Finally, do not wait for Google to wander back. Open Search Console, paste the URL into URL Inspection, confirm it now reads “Indexing allowed? Yes,” and click Request Indexing. For a sitewide accident, resubmit your sitemap as well so the recrawl covers every affected URL, not just the ones you remember to paste.

The trap: noindex in robots.txt does nothing

Here is the folklore we kill on sight. Writing Noindex: rules in robots.txt does not work. Google ended support for that unofficial directive in 2019, and the current documentation is explicit that noindex belongs in a meta tag or an HTTP header, nowhere else. Worse, robots.txt can actively sabotage your fix. If robots.txt blocks the page, Google cannot crawl it, which means Google never sees that the noindex is gone. The page stays dead, and it can even stay indexed with a stale snapshot, because the crawler is locked out of the update. The order of operations is fixed: allow crawling first, remove the noindex second, request indexing third. If your robots.txt has other problems, our guide on robots.txt blocking AI crawlers covers the file in full.

Verify: prove the rule is gone

Check all three surfaces. View source and confirm no noindex in any robots meta tag. Run the curl command above and confirm no X-Robots-Tag: noindex header. Then confirm robots.txt is not blocking the URL, because a blocked page can never deliver the good news.

Then verify it the way the engines will. Re-run an audit on the live URL and confirm the page reads as indexable end to end. You can do this by hand, or paste your link into the full Brimm audit and we will read the page the way a crawler does, check the meta tag, the header, and the robots.txt gate in one pass, and print anything that still says noindex. Remember that Bing obeys the same rules through its own crawler, so if you are missing there too, read our guide on Bing indexation, and the rest of the fix library walks through the other failures we find most.