Submitted URL marked 'noindex'

You put a URL in your sitemap, which says index this. Google fetched it and found a noindex, which says do not. It obeyed the page.

That is the whole status. Unlike most Search Console reports, this one is not Google making a judgement about your page — it read your instructions, found two that contradict each other, and is telling you so.

Which means there are only two situations, and they have opposite fixes.

Did you mean to block it?	The problem	The fix
No	The noindex should not be there	Remove the noindex
Yes	The sitemap should not list it	Remove it from the sitemap

Work out which one you are in before changing anything. Roughly half the time this report is raised as a bug, the noindex is correct and the sitemap is wrong — and deleting the noindex would publish something that was meant to stay private.

Find the noindex first

It is in one of two places, and the second one is the reason people spend an afternoon on this.

A meta tag in the HTML. View source and search for noindex:

<meta name="robots" content="noindex">

An HTTP response header. This does the same job and is invisible in View Source, because it never appears in the HTML at all:

X-Robots-Tag: noindex

Check the headers explicitly — in your browser’s Network tab, or with curl -I https://example.com/your-page. If the tag is not in the source and the status persists, this is where it is.

The header is usually set by something other than your CMS: a server config, a CDN rule, a hosting platform’s “this is a preview environment” feature. That is also why it survives edits to the page itself.

The four causes worth checking first

A staging setting that shipped. The single most common one. A noindex added deliberately to keep a pre-launch site out of the index, then carried into production with the rest of the config.

Your CMS is set to discourage indexing. WordPress has a checkbox under Settings → Reading, Discourage search engines from indexing this site, which adds noindex site-wide. It is meant for development and is frequently left on after launch.

An SEO plugin rule applied more widely than intended. Most plugins let you noindex a whole post type, taxonomy or template. A rule meant for tag archives that matches your product pages produces exactly this report, on exactly the pages you care about.

A template applied to the wrong page type. The same mechanism as the canonical bugs in why is my page not indexed — a directive hard-coded into a layout that more page types inherit than anyone expected.

The confusion that costs the most time

noindex and a robots.txt Disallow are not the same thing and they do not combine the way people assume.

Disallow stops Google fetching the page. noindex tells Google not to keep it. So if a URL is disallowed in robots.txt, Google never fetches it, never sees the noindex, and cannot act on it. Blocking a page you want removed is the one move that reliably prevents its removal.

That also means this specific status is proof of something useful: to report it, Google had to fetch the page and read the tag. Crawling is working. If the same URL were blocked in robots.txt you would be looking at a different status entirely.

If the noindex was intentional

Then nothing is broken, and the report is Google pointing at an inconsistency worth cleaning up.

Take the URL out of your sitemap. A sitemap is a list of pages you are asking to have indexed, so listing a page you have told Google to ignore is a contradiction you are publishing on purpose. It costs you nothing directly, but it makes the file less trustworthy — and a sitemap full of URLs Google is not allowed to index is one it will weigh less when you do want its help.

Usually the sitemap is generated, which means the exclusion belongs in whatever generates it rather than in the file.

After you remove it

Nothing happens immediately, and this is where people conclude the fix failed.

Google has to recrawl the page before it can notice the tag is gone. Until that recrawl, Search Console keeps reporting the old state, because the report describes what Google last saw rather than what is on your server now. Use Test live URL in URL Inspection to confirm the tag has actually gone — the default result describes the stored version and will keep showing the problem.

Request indexing once, then leave it alone. How long the recrawl takes depends on the same things everything else does, which how long Google takes to index a page goes through.

And removing the noindex only makes the page eligible. Google still decides whether to keep it, and a page can clear this status and land in Crawled – currently not indexed instead. That is a different problem with different causes — but at least it is Google’s judgement rather than your own instruction working against you.

Checking more than one page

This status usually arrives in groups, because the causes above are settings rather than typos: one checkbox, one template, one header rule, applied across a section.

So the useful question after a fix is not “did this page come back” but “how many of them did”. Check the whole affected list at once and compare it against the same list a few weeks later — our free index checker takes ten URLs with no account, which is enough to see whether a fix took before you commit to auditing all of them.