Google treats an XML sitemap strictly as a hint, a way of learning about URLs and getting metadata like last-modified timestamps that may help with discovery and prioritization, and never as a directive that forces or guarantees indexing. Google’s own sitemaps documentation is explicit that submitting a sitemap does not guarantee all, or any, of the listed URLs will be crawled or indexed. In practice, this distinction breaks down (meaning site owners run into real friction because their assumptions don’t match Google’s actual behavior) in three concrete ways: treating sitemap submission as equivalent to an indexing request and expecting guaranteed inclusion, sitemap-listed URLs conflicting with a page’s own rel=canonical tag and sending mixed signals about which URL is actually canonical, and stale or inaccurate lastmod timestamps gradually eroding how much Google’s systems trust the freshness signal the sitemap is supposed to provide.
Direct answer
A sitemap is a discovery and prioritization aid, not an indexing command. It tells Google “here are URLs I consider important or that might not be easily found otherwise,” along with optional metadata about when they were last modified. It carries no forcing power whatsoever over Google’s actual indexing decision, which depends on a much broader set of factors including content quality, duplication, crawlability, and Google’s own assessment of whether the page is worth serving in search results. The gap between what site owners often expect (submit sitemap, get indexed) and what Google actually does (evaluate the page independently of the sitemap’s mere existence) is the root of most confusion and frustration around sitemaps.
Mechanism: three concrete ways the distinction breaks down in practice
One: treating sitemap submission as a request to index, with an expectation of guaranteed inclusion. This is the most common and most consequential misunderstanding. Site owners frequently submit a sitemap, see it processed successfully in Search Console (a green checkmark, a count of “discovered” URLs), and interpret that success as meaning those URLs are now indexed or will shortly become indexed as a matter of course. That’s not what a successful sitemap processing status means. It means Google successfully parsed the sitemap file and became aware of the URLs listed in it. Awareness is not indexation. Search Console’s own Page Indexing report routinely shows large numbers of sitemap-submitted URLs sitting under statuses like “Discovered, currently not indexed” or “Crawled, currently not indexed,” which are Google’s own documented ways of saying: I know this URL exists (in part because your sitemap told me), I may have even crawled it, and I have independently decided not to include it in the index right now. The sitemap did its job (discovery) and then indexing was evaluated and declined on separate grounds entirely, often related to content quality, duplication, or the page simply not clearing whatever bar Google’s systems apply. No amount of resubmitting the sitemap changes that underlying evaluation.
Two: sitemap-listed URLs conflicting with the page’s own rel=canonical tag. A sitemap is supposed to list a site’s preferred, canonical URLs, that’s the guidance Google itself gives for constructing an accurate sitemap. But it’s common, especially on larger or poorly-maintained sites, for a sitemap generation process to list a URL that the page itself, via its rel=canonical tag, designates as non-canonical, pointing instead to a different URL as the true canonical version. This creates a direct contradiction: the sitemap is effectively saying “index this URL,” while the page’s own canonical tag is saying “no, defer to this other URL instead.” Google’s canonicalization systems weigh multiple signals when selecting a canonical URL, and while rel=canonical is one of the strongest signals available, a sitemap listing pointing elsewhere is still a competing signal that adds noise to that decision. This kind of mismatch commonly arises from sitemap generation logic that’s out of sync with canonicalization logic, for instance, a sitemap built from a raw URL list or database query that doesn’t account for parameter variants, pagination, or recent canonical tag changes, while the canonical tags themselves were updated separately by a different part of the CMS or a different plugin. The fix requires the two systems to share a single source of truth about what the “real” URL for a piece of content is, rather than being generated independently.
Three: stale or inaccurate lastmod timestamps eroding trust in the freshness signal. The lastmod field in a sitemap entry is meant to tell Google when a URL’s content was last meaningfully changed, which can help Google prioritize recrawling of genuinely updated content. Google’s documentation notes that this timestamp is only useful if it’s accurate. In practice, many sitemap generation systems set lastmod to the current date and time on every generation run, regardless of whether the underlying content actually changed, or set it based on unrelated system events (a template update, a metadata field edit, a republish action with no content change) rather than substantive content edits. When Google’s crawlers repeatedly find that a URL’s lastmod claimed a recent update but the actual content is unchanged from the last crawl, that specific signal becomes less useful as a prioritization input over time. This is a gradual, systemic effect rather than a single-instance penalty: it’s not that one inaccurate lastmod entry causes an immediate problem, it’s that a pattern of inaccurate timestamps across a sitemap makes the entire freshness signal less actionable for Google going forward, since it can no longer reliably distinguish “this timestamp means something” from “this timestamp is noise.” There’s no published quantified metric for this degradation, and it would be a fabrication to claim one, but the qualitative mechanism, unreliable signals becoming less useful inputs, is well-grounded in how any signal-based prioritization system behaves and is consistent with Google’s own guidance to keep lastmod accurate.
Practical guidance: keep sitemaps accurate and canonical-consistent, since that’s the actual lever you control
Given that sitemap submission has no forcing power over indexing, the productive use of your effort is making sure the sitemap is a maximally accurate, trustworthy input rather than trying to compensate for weak content or unresolved technical issues by resubmitting or restructuring the sitemap itself.
Ensure every URL listed in the sitemap is genuinely canonical, matching the page’s own rel=canonical tag exactly. Generate the sitemap from the same underlying data source that determines canonical status, rather than maintaining these as separate, independently-updated systems that can drift out of sync.
Exclude non-indexable URLs from the sitemap entirely, meaning any URL that’s noindexed, blocked by robots.txt, redirected, or returning a non-200 status. A sitemap full of URLs that can’t or shouldn’t be indexed dilutes its usefulness as a clean discovery signal and generates exactly the kind of contradictory-status confusion covered in the noindex-in-sitemap scenario.
Only populate lastmod when you can generate it from an actual content-change event, not from a template rebuild, a general republish action, or the current timestamp by default. If your CMS or static site generator can’t reliably distinguish substantive content changes from unrelated system touches, it’s more honest, and ultimately more useful to Google, to omit lastmod entirely than to populate it with a value that doesn’t correspond to real changes.
Finally, treat “Discovered, currently not indexed” or “Crawled, currently not indexed” statuses in Search Console as information about content and site quality, not sitemap configuration. If pages are being found via the sitemap but declined for indexing at scale, the fix lies in improving the pages themselves (uniqueness, depth, value relative to what’s already indexed for similar queries) or in addressing broader site-wide quality signals, not in adjusting sitemap settings, since the sitemap already did the only job it was ever capable of doing: making sure Google knew the URL existed.
