Excluded by ‘noindex’ tag is the status name most people still search for, and the reason they cannot find it in the current report is that Google renamed it. The Page indexing report now shows it as URL marked ‘noindex’. Same status, same meaning: Google tried to index the page, found a noindex directive, and obeyed it.
Of every not-indexed status in Search Console, this is the only one that is entirely your own site talking. A 404 is a missing page, a 5xx is a struggling server, but a noindex is an instruction, and Google’s help entry allows itself a rare joke about it: “If you do not want this page indexed, congratulations!” The unfunny half of the sentence is the other case. If you did want the page indexed, your site has been telling Google not to, and on the sites I audit, the person who set the instruction is usually not the person reading the report.
What the status means mechanically
A noindex only works because the page could be crawled. Google fetched the URL, got a 200, read the page or its headers, found the directive, and dropped the page from indexing. That has two consequences people trip over.
First, it means noindex and robots.txt are opposites in an important way. A page blocked by robots.txt cannot be fetched, so a noindex on it can never be read, which is how sites end up with the paradoxical indexed though blocked by robots.txt status. If you want a page out of the index, it must stay crawlable; I walked through that logic in noindex vs robots.txt.
Second, it means the directive is re-read on every crawl. Remove the noindex and the page does not come back by itself immediately; it comes back when Google recrawls and sees the change. That is why the fix always ends with a live test and a Request Indexing, not with editing a setting and waiting hopefully.
The four places the tag hides
When a client sends me this status on a page they wanted indexed, the noindex is real; the question is which layer wrote it. There are exactly four places to look, and I check them in this order because it matches how often each one is guilty in practice:
- The SEO plugin’s per-page setting. On WordPress, Yoast and Rank Math both carry a per-post “allow search engines to show this?” control, and both carry site-wide defaults per content type. A default set to noindex for a whole post type, categories, tags, or a custom type like portfolio items, is the single most common cause I meet. Nobody remembers setting it, because it was often set correctly years ago for a type that has since changed jobs. Note that both plugins also noindex internal search results with no setting involved at all, which is why
/?s=URLs turn up in this status on sites nobody has configured. - The site-wide WordPress checkbox. Settings, Reading, “Discourage search engines from indexing this site” writes a noindex onto every page. It gets switched on for redesigns and staging copies, then travels to production with the database. I wrote about what that checkbox actually does because its label has not matched its behaviour for years.
- The meta robots tag in the HTML head. The hand-written case: a theme option, a template, or a hardcoded
<meta name="robots" content="noindex">in a header file. View source and search for “noindex” finds it in seconds. - The X-Robots-Tag HTTP header. The invisible case: nothing in the HTML, because the directive rides in the response headers, set by the server config, the CDN, or a plugin. Browsers do not show it without opening dev tools, which is why it survives longest undetected. The header variant has its own behaviours and its own post: X-Robots-Tag noindex.
Confirming and clearing it
Google’s own confirmation steps for this status are good, and they map onto the layers above:
- In the report, click the inspection icon next to an affected URL. Under the indexing section, “Indexing allowed?” should say no, with noindex as the reason. This is what Google saw at last crawl.
- Find the directive in the current page: view source for the meta tag, response headers for X-Robots-Tag. If you find nothing in either place, the tag was already removed and you are looking at stale data.
- Remove the directive at whichever layer wrote it. Removing it at the wrong layer is the classic failed fix: deleting a meta tag while the header keeps sending noindex changes nothing, and Google reads them together, taking the most restrictive combination.
- Run Test live URL in URL Inspection. When the live test shows indexing allowed, click Request Indexing. If the live test still detects noindex, the directive is still being served, whatever the templates look like.
One audit habit worth stealing: read this status’s URL list before assuming anything is wrong. On most healthy sites the list should be full of pages that are correctly excluded, cart pages, internal search results, thank-you pages, feeds and paginated archives. The status is not an error list, it is an inventory of every page your site told Google to skip. The wins hide in the exceptions: the money page that a per-type default swallowed, the relaunch that shipped with the staging checkbox still on. The full taxonomy of which statuses deserve worry and which do not is in every Search Console indexing status, and this one sits firmly in the “read it, do not panic about it” column.
The renaming, for what it is worth, made the status more honest. “Excluded by ‘noindex’ tag” sounded like something Google did to you. “URL marked ‘noindex’” says where the mark came from: your side. Whether it belongs there is the only question the report cannot answer for you.
Sources
- Google Search Console Help, Page indexing report, the URL marked ‘noindex’ status and its confirmation steps, checked 1 September 2026
- Google Search Central, robots meta tag and X-Robots-Tag specifications, for the directive forms, header variant and the most-restrictive combination rule
- Google Search Central, block search indexing with noindex, for noindex requiring a crawlable page
- Google Search Console Help, URL Inspection tool, for the live test and Request Indexing flow