An XML sitemap functions as a hint telling Google “these URLs exist and are candidates worth considering for indexing,” while a noindex directive on a page is an explicit, page-level instruction saying “do not index this URL.” Listing a noindexed URL in your sitemap puts these two signals in direct contradiction for the same page. Google resolves this by treating the noindex directive as authoritative, since it’s a specific, deliberate exclusion instruction rather than a general inclusion hint, but the conflict isn’t free even though noindex wins. It wastes crawl attention on a page you’ve already told Google to disregard, produces a specifically flagged, confusing status in Search Console, and over time can erode how much Google trusts the accuracy of that sitemap’s contents as a whole.
Direct answer
When Google encounters a URL listed in your sitemap that also carries a noindex directive (via meta robots tag or X-Robots-Tag header), the noindex wins. Google will not index the page despite its sitemap presence. This isn’t ambiguous or a coin-flip outcome, sitemaps are documented as hints about which pages you’d like considered, not commands Google is obligated to follow, whereas noindex is a direct, explicit directive about a specific page’s indexing eligibility. A hint cannot override an explicit instruction. But “the conflict resolves safely” is not the same as “the conflict is harmless.” The mismatch still costs you in ways worth taking seriously: wasted crawl resource on pages you’ve already excluded, a specific confusing status surfaced in Search Console’s reporting, and a gradual erosion of confidence in that sitemap as an accurate reflection of the site’s actual indexable content.
Mechanism: hint versus directive, and why the distinction has teeth
Google’s own documentation on building and submitting sitemaps describes their function plainly: a sitemap tells Google about pages on your site that might not otherwise be discovered, and provides metadata (like last modification date) that can help Google understand the content, but it explicitly does not guarantee that listed URLs will be crawled or indexed. It’s a discovery and prioritization aid, not a contractual promise. Google retains full discretion over what actually gets indexed regardless of sitemap presence.
A noindex directive operates on an entirely different level of specificity and force. It’s not a general suggestion about the site’s structure, it’s a page-specific instruction that Google’s documentation describes as something Google will act on once it successfully crawls the page and reads the tag or header. Because noindex is explicit, deliberate, and directly attached to the URL in question (rather than being an inference from a broader sitemap listing), it functions as the higher-priority signal whenever the two are in tension.
The practical mechanism of the conflict is this: Google still has to crawl the noindexed URL to discover the noindex directive in the first place, since a sitemap entry is effectively a crawl request. If the URL is not blocked by robots.txt, Googlebot will fetch it, read the noindex tag, and exclude it from the index, having spent a crawl request to arrive at a conclusion you’d already told Google via the sitemap you presumably didn’t intend, since you wouldn’t have listed a page you wanted excluded if you were being deliberate about sitemap contents. This shows up directly in Search Console’s Sitemaps and Page Indexing reports under a specific, named status: “Submitted URL marked ‘noindex’.” This isn’t a vague inference on Google’s part, it’s a status Google explicitly generates to flag exactly this contradiction back to the site owner, which is itself evidence of how deliberately Google treats the mismatch as worth surfacing rather than silently ignoring.
Beyond the immediate crawl waste and reporting noise, there’s a subtler cost. A sitemap that reliably lists only URLs the site owner actually wants indexed is a more useful, higher-trust signal to Google’s systems than one that regularly includes URLs marked noindex, redirected, canonicalized elsewhere, or otherwise excluded. While there’s no published, quantified “trust score” metric for sitemaps (that specific framing would be a fabrication and shouldn’t be treated as something Google has ever stated), it’s a reasonable and consensus-supported inference within the SEO field that a sitemap riddled with contradictory or excluded URLs is a noisier, less reliable input for Google’s crawling and prioritization decisions than a clean one. Google’s own general guidance around sitemap quality (keeping them updated, accurate, and limited to canonical, indexable URLs) points in the same direction: accuracy is what makes the hint useful at all.
It’s worth being precise about what this conflict does not do. It does not cause a ranking penalty. There’s no documented mechanism by which having noindexed URLs in your sitemap directly suppresses the rankings of your other, properly indexed pages. The cost is crawl inefficiency and reporting confusion, not an algorithmic punishment. Framing it as a penalty overstates the mechanism and isn’t supported by anything Google has published.
Practical fix: exclude noindexed URLs from sitemap generation programmatically
The sustainable fix is to make sitemap generation logic aware of indexing status, rather than treating sitemap generation and noindex application as two unrelated processes that happen to both touch the same URLs.
If your sitemap is generated dynamically (via a CMS plugin, a custom script, or a framework’s build process), the generation logic should query the same source of truth that determines whether a page is noindexed, and exclude any URL carrying that directive automatically. This is almost always more reliable than manually maintaining an exclusion list, since manual processes drift out of sync as pages are added, updated, or reclassified over time.
For CMS-driven sites using common SEO plugins, most mainstream tools already tie sitemap inclusion to the page’s meta robots settings by default, meaning a page marked noindex through the plugin’s own interface is automatically excluded from the generated sitemap without extra configuration. Problems tend to arise more from custom-built sitemaps, headless CMS setups where sitemap generation is a separate pipeline from content management, or legacy static sitemap files that were generated once and never revisited as the site’s noindex usage evolved.
Periodically audit your live sitemap against your site’s actual noindex tags as a validation step, rather than assuming the generation logic is working correctly indefinitely. Crawl your own sitemap URLs and check each one’s meta robots status, flagging any mismatch. This is also a natural point to check the Search Console Page Indexing report for any live “Submitted URL marked ‘noindex'” entries, since their presence is a direct, Google-confirmed signal that your generation logic currently has a gap worth closing.
Treat sitemap accuracy as an ongoing maintenance responsibility tied to your indexing directives, not a one-time setup task. As your noindex usage changes over time (new thin pages get excluded, old excluded pages get consolidated and reopened for indexing), your sitemap needs to track those changes automatically to keep functioning as the clean, trustworthy discovery hint it’s meant to be.
A worked example of the conflict playing out
Suppose a mid-size e-commerce site noindexes around 400 thin, near-duplicate filter-combination URLs (like a product category filtered by three overlapping size and color parameters at once) to keep them out of the index, but the sitemap is a static file that was generated once during a site rebuild and never updated afterward, so all 400 of those URLs are still listed. Over the following weeks, Search Console’s Page Indexing report shows those 400 URLs accumulating under “Submitted URL marked ‘noindex’,” and server logs show Googlebot spending a measurable share of its crawl budget on that site re-fetching pages it excludes from the index every single time. None of the site’s properly indexed 12,000 product pages lose rankings because of this, since noindex still wins the conflict and nothing about the mismatch touches those other pages. But when the team finally audits the sitemap and wires its generation to the same noindex flags the CMS already tracks, the 400 stale entries disappear from the sitemap, the matching Search Console warnings clear over the next few crawl cycles, and crawl activity that used to be spent re-confirming pages Google was already ignoring becomes available for the site’s actual indexable content instead.
