In most cases, no. A standard XML sitemap should list canonical pages you want search engines to crawl and consider for indexing. A noindex directive says that a page should not appear in search results. Putting the same URL in a sitemap creates an unnecessary contradiction.
Search engines can usually resolve the conflict, but the sitemap becomes less useful as a technical signal and reporting source. The better approach is to remove intentionally noindexed URLs from the sitemap while keeping the noindex directive in place for as long as needed.
Why the signals conflict
A sitemap communicates that a URL is important enough to submit. Noindex communicates that the URL should not be stored in the searchable index. These controls operate at different stages, yet they point in opposite directions.
The sitemap does not override noindex. Google can crawl the page, read the directive, and exclude it. However, repeated submission may lead to extra crawling and persistent “submitted URL marked noindex” style reporting, depending on the search engine interface.
What to do with intentionally excluded pages
Remove account pages, internal search results, thin tag archives, campaign duplicates, and other intentionally noindexed URLs from the sitemap generator. Keep the pages accessible to crawlers if they need to read the directive.
Do not add a robots.txt block just to reduce the apparent conflict. As explained in why robots-blocked pages can still appear in search, blocking crawling may prevent the crawler from seeing noindex.
Temporary noindex during site preparation
Staging and pre-launch pages should usually be protected with authentication, not merely noindex. If a production page is temporarily noindexed during a controlled release, remove it from the sitemap until the page is ready.
When you remove noindex, verify the live HTML and headers, restore the canonical URL to the sitemap, add appropriate internal links, and update lastmod only if the page itself changed meaningfully. This produces a clean transition from excluded to indexable.
What if a page was accidentally noindexed?
First remove the unintended directive. Check both the HTML meta tag and X-Robots-Tag response header, because server configuration can apply noindex even when the source template looks correct.
Then confirm that robots.txt permits crawling. A crawler must retrieve the page again before it can observe the change. Keep the corrected canonical URL in the sitemap and request inspection if the page is important. Processing may still take time.
Pages removed from search but still useful to users
Some pages serve visitors without needing search visibility. Examples include thank-you pages, print views, filtered lists, and account utilities. These can remain available and internally linked where appropriate while staying outside the sitemap.
Noindex is not a judgement that a page is worthless. It is a distribution decision. A useful checkout confirmation page should work well for customers even though it should not appear as an independent search result.
Noindex and canonical tags
A noindex page may also contain a canonical tag, but using noindex as a canonicalisation method is not recommended. If two pages are duplicates and one should represent the set, use consistent canonical signals, redirects where appropriate, and internal links pointing to the preferred URL.
If the duplicate should remain accessible but never appear in search, noindex can be appropriate. Still, do not expect its canonical tag to transfer every signal in a predictable way. Decide whether the issue is duplication or exclusion and choose the clearest control.
Should noindex pages ever appear in a sitemap?
A short-lived exception can occur during deindexing. An already indexed page may remain temporarily in a sitemap while you add noindex and wait for recrawling. Keeping it discoverable can help the crawler revisit it, although strong internal links and inspection tools may already provide that path.
Once the search engine has processed the noindex state, remove the URL from the sitemap. Do not treat this transitional tactic as a permanent configuration.
How to find accidental conflicts
Crawl every sitemap URL and record its robots directives. Flag any entry containing noindex or none. Also inspect response headers, redirects, and canonical targets. The process in how to check a sitemap for errors covers the broader audit.
Group conflicts by template. If hundreds of category pages are affected, fix the category sitemap generator or template rather than deleting rows manually. Automated causes need automated corrections.
Keep your sitemap definition strict
A clear sitemap rule can be expressed in one sentence: include URLs that return 200, allow indexing, declare themselves canonical, and represent content you want in search. This mirrors the inclusion test in what belongs in an XML sitemap.
When the sitemap follows that rule, reports become easier to interpret. A submitted URL excluded by noindex is then a genuine anomaly rather than expected noise.
The practical answer
Remove intentionally noindexed pages from your sitemap. Keep noindex visible to crawlers, protect confidential resources with authentication, and re-add a URL only after it becomes a live canonical page intended for search.
Consistency matters more than the number of URLs submitted. A smaller sitemap that accurately represents indexable content is more useful than a complete database export full of conflicting states.