Excluded by Noindex Tag: What It Means

"Excluded by 'noindex' tag" is the clearest status in the Page indexing report. It does not describe a judgement Google made or a queue it has not got to. It says Google found an instruction on the page and did what it was told. The question is only whether you meant to give that instruction. This post covers where the directive can hide, the cases where the status is correct, the ones where it is costing you rankings, and how to find every affected page in one pass. We checked our own site's URL Inspection data while writing it, on 6 October 2026.

What "Excluded by 'noindex' tag" means

Google's definition, from its Page indexing report documentation, is short:

"When Google tried to index the page it encountered a 'noindex' directive and therefore did not index it."

Three things follow. Google could reach the page, since it had to fetch it to read the directive. Google could read the page's HTML or headers, since that is where the directive lives. And Google chose nothing: it obeyed. If the page should be out of search, this is the status you want.

Where the directive can hide

Most people check the <head> for a <meta name="robots" content="noindex"> tag, see nothing, and conclude the report is wrong. There are four places a noindex can live, and the report does not say which one it found.

1. The robots meta tag. <meta name="robots" content="noindex"> in the page's HTML. The value none is a synonym that means noindex, nofollow.
2. A bot-specific meta tag. <meta name="googlebot" content="noindex"> applies only to Google and is easy to miss when you search the source for robots.
3. The X-Robots-Tag HTTP header. X-Robots-Tag: noindex is sent by the server, not the page, so it never appears in the HTML. It is the usual explanation for a page that "has no noindex" but carries this status. Look at the response headers, not the source.
4. A rendered tag. A tag that JavaScript injects after load will be seen by Google's renderer. A tag that JavaScript removes may not be removed in time. If the raw HTML and the rendered page disagree, Google can go either way.

A directive in any one of these places is enough. If the page is served through a CDN or a reverse proxy, check the headers at the edge as well as at the origin, because a header can be added at either layer.

When the status is correct

A healthy site should have pages in this bucket. Our own site does: https://crawlcove.com/login inspects as "Excluded by 'noindex' tag", last crawled 30 September 2026, page fetch successful, robots.txt allowed, indexing blocked by meta tag. That is a login form. Nobody should find it in search, and Google agreeing with that is the system working.

Other pages that belong here:

• Login, registration and password-reset pages
• Account dashboards and anything behind authentication that still returns 200
• Internal search result pages
• Thank-you and order-confirmation pages
• Tag archives, author archives and date archives on a blog that does not want them ranking
• Filtered or sorted views of a listing page
• Staging and preview environments

If every URL under this status is on that list, there is nothing to do. The count can be large on an e-commerce site, and that is fine.

When it is a real problem

The status needs action when a page you want in search is on the list. On a working site that almost always traces back to a setting rather than a deliberate tag:

• A CMS visibility option. WordPress has a single checkbox under Settings that adds noindex to every page. SEO plugins add per-post and per-type settings on top of it. One of them was ticked, or one of them was set at the post-type level and inherited by every page of that type.
• A staging flag that shipped. Staging sites are often noindexed by a header set in the web server or hosting panel. When the site is cloned to production, the header comes with it.
• A theme or template default. Some templates add noindex to pagination, archives or custom post types by design, which is right for some sites and wrong for others.
• A rule written too broadly. An X-Robots-Tag header meant for PDFs or a /private/ path, applied with a regular expression that also matches real pages.
• A tag on the canonical target. If page A declares page B as canonical and page B is noindexed, both pages drop out. Google's own guidance is not to combine a canonical with a noindex target, because the two signals conflict.

The test is simple: for each URL under this status, ask whether you would want it to rank for anything. If yes, the directive is wrong and the next section applies.

How to fix it

1. Find the directive. Request the URL and look at both the HTML <head> and the response headers. Check for robots, googlebot and X-Robots-Tag. If you have a CDN, check the response from the edge.
2. Fix the source, not the symptom. A CMS setting fixed at the page level will be reset the next time a template or plugin saves. Change it where it was set.
3. Confirm robots.txt allows the URL. Google has to recrawl the page to see the directive is gone. If the URL is also disallowed in robots.txt, it cannot, and the page stays out. The blocked by robots.txt status explains that interaction.
4. Request indexing. In URL Inspection, run a live test to confirm the directive has gone, then request indexing. One request is enough.
5. Wait for the recrawl. The status will not change until Google fetches the page again. Check the last crawl date on the inspection result before you decide the fix did not work. How long Google takes to recrawl a page sets expectations.

Once the page is back, keep an eye on it for a few weeks. If it drops to crawled currently not indexed, the directive was not the only thing holding it back.

Noindex versus the other "keep out" tools

Three tools get confused with each other here, and they are not interchangeable:

• Noindex keeps a page out of the index while letting Google crawl it and follow its links. Use it for pages that must exist but must not rank.
• Robots.txt stops Google crawling a URL. It does not stop indexing, and it hides any noindex on the page. Use it for crawl budget, not for keeping URLs out of search.
• A canonical tag tells Google which of several similar pages to index. It is a hint, not a directive, and Google can ignore it. Use it for duplicates that should resolve to one URL. The alternate page with proper canonical tag status is what a working canonical looks like in the report.

If a page is behind authentication, returning 401 or 403 is a fourth option, and the report has its own statuses for those.

Finding every noindexed page with a crawl

Search Console shows the list, but it is Google's list: the URLs Google has fetched, as of the last time it fetched each one. A page you noindexed by accident last week will not appear until Google comes back, and a page you fixed last week will still appear until the same thing happens. The report cannot tell you what your site serves today.

A crawl can. Crawl Cove requests every page on your site and its robots-noindex check lists each page carrying a noindex directive, whether it came from the robots meta tag, a googlebot meta tag or the X-Robots-Tag response header, so a header-only directive is reported alongside a tag in the HTML. It is graded High, not because noindex is wrong, but so each exclusion gets confirmed as intentional. The canonical-to-noindex check catches the conflicting case, where a page's canonical points at a URL that is itself noindexed, and sitemap-non-indexable-url flags any noindexed page still listed in your XML sitemap, which is a mixed signal worth clearing up.

For the pages you want back in search, the Live Index Status panel calls Google's URL Inspection API for the URL you choose and shows the coverage state, the indexing state and the last crawl date, so you can tell a stale verdict from a current one without leaving the crawl. Run a full SEO audit to see every noindexed page on the site in one list, then decide which ones are meant to be there.

Wrap-up

"Excluded by 'noindex' tag" is Google following your instructions. On most sites the list is exactly the pages that should be on it, and the right response is to leave it alone. When a page you care about appears, look in all four places the directive can hide, fix it at the source, make sure robots.txt is not stopping Google seeing the change, and give the recrawl time. A crawl shows you what the site serves today; the report shows you what Google saw last time. You need both.