How to Fix “Excluded by Noindex Tag” in Google Search Console

A page excluded by a noindex tag isn’t a Google problem. Your own site told Google not to index the page, and Google did as instructed. Google’s help for the Page indexing report describes the reason under “URL marked ‘noindex'”: when Google tried to index the page, it encountered a noindex directive and therefore didn’t index it. So the fix doesn’t start with “ask Google to index this.” It is finding where the noindex comes from and removing it, if the page should be indexed at all.

What the status means

The sequence was: Google fetched the page, read a noindex instruction and respected it. Nothing went wrong on Google’s side. That reframes the task: you aren’t arguing with a judgment of your content, you are auditing your own configuration for a directive doing what directives do. Content quality doesn’t enter into it. A perfect page is excluded if it carries a noindex.

Before changing anything, decide whether the page should be indexed. A thank-you page, an internal search result or a login screen may be excluded on purpose, and then the status is the right one.

Where a noindex comes from

Google’s guide to blocking indexing with noindex says there are two ways to implement it: as a <meta> tag and as an HTTP response header. In practice, three kinds of source produce those two outputs.

The meta robots tag sits in the page’s <head> as <meta name="robots" content="noindex">. It shows up in the page source, so it is the easiest to find.

The X-Robots-Tag header is returned by the server with the page rather than written into the HTML. It has the same effect as the meta tag, but it doesn’t appear in the page source at all. You can read the HTML line by line, find no noindex, and still have a page excluded by a header.

Platform and plugin rules are the third source. The same Google guide notes that your CMS might have a search engine settings page or another mechanism for these tags. CMS settings, SEO plugins and e-commerce apps can apply noindex automatically when a page meets a condition, such as a product with no stock, a collection with no items, a draft, or a thin tag or author archive. A page can flip to noindex without anyone editing its template.

That last source can be the hardest to catch, because nobody chose it for that page specifically. For example, imagine a global “noindex empty collections” setting switched on at launch: months later a real collection sells out, meets the condition and drops out of the index. Searching the template turns up nothing, because the template never changed. One way to find it is to list every setting, plugin and app that can emit a noindex, then match each one’s conditions against the page’s current state. A product that just sold out points to a stock-based rule; a brand-new collection points to an empty-collection rule.

Diagnosing the exact source

URL Inspection is the fast path. Inspect the affected URL and run the live test. Google’s URL Inspection tool documentation says that if “Indexing allowed?” is “No”, your site is returning a noindex tag or header that prevents indexing. The Page indexing help gives the next step: search the page source or the response headers for the word “noindex”.

Check both. The URL Inspection documentation says View crawled page shows the HTTP request and response and the returned HTML, so you can see whether the directive Google read sat in a meta tag or in an X-Robots-Tag header. If it is in the header, stop editing HTML; the directive lives in the server, CDN or plugin configuration. If it is in the HTML, find the template or setting that outputs the tag.

Why this isn’t a robots.txt problem

A noindex only works if Google crawls the page and sees it. This status proves that happened: Google crawled, read the directive and obeyed. You don’t have a crawl-access problem; you have a directive that is present and working.

The URL Inspection documentation also covers the opposite case. If a page is blocked by robots.txt, “Indexing allowed?” will always show “Yes”, because Google can’t see any noindex directive on a page it can’t fetch. So if a page you meant to keep out keeps appearing in search, and inspection says indexing is allowed, check “Crawl allowed?” before you assume the noindex is missing.

Fix, verify, then let recrawl work

Remove the directive at its source: delete the meta tag or fix the template that outputs it, strip the X-Robots-Tag from the server or CDN configuration, or turn off the platform rule that applied it. If a CDN caches your responses, purge the affected URLs after the change, or it can keep serving the old header.

Then verify before you expect anything. Run the live test again and confirm “Indexing allowed?” now says “Yes”, and re-check the HTML and the response headers. Skipping this step is how a header-based noindex gets “fixed” by editing HTML that never contained it, followed by weeks of waiting for an indexing that can’t happen. The Page indexing help says that once the noindex is no longer present, you can request indexing.

After that, indexing depends on recrawling. Request indexing for your key pages, and let normal crawling pick up the rest. Google’s guide to asking Google to recrawl says “Crawling can take anywhere from a few days to a few weeks,” and that requesting a recrawl of the same URL several times won’t speed it up.

Frequently asked questions

Why is my page noindexed when there’s no noindex in the HTML?

Check the HTTP response headers for an X-Robots-Tag, which never appears in the page source, and check your platform and plugin settings for a rule tied to the page’s state. In URL Inspection, View crawled page shows the returned HTML and the HTTP response, so you can see where the directive was.

How long after removing noindex will the page be indexed?

It depends on when Google recrawls the page. Confirm the noindex is gone first, request indexing for your highest-priority URLs, and expect what Google’s recrawl guide describes: “Crawling can take anywhere from a few days to a few weeks.”

Should every page excluded by noindex be fixed?

No. Pages you excluded on purpose, such as thank-you pages or internal search results, are in the right state. Fix only the pages you want in search.