XML sitemaps get treated as an SEO must-have by default, applied uniformly regardless of site size or structure. They're genuinely useful in the right circumstances and genuinely unnecessary in others — worth being specific about which is true for a given site rather than assuming every site needs one.

What a sitemap actually does

A sitemap is a discovery aid, not a directive. It tells a search engine which URLs exist and, optionally, when they last changed — helping the crawler find and prioritize pages it might not otherwise discover quickly through normal link-following. What it does not do is guarantee indexing. A URL listed in a sitemap can still be excluded from the index if a search engine judges it thin, duplicate, or otherwise low-value. Treating a sitemap as an indexing guarantee leads to the wrong conclusion when pages don't get indexed — the sitemap did its job (the URL was discovered); indexing is a separate, quality-based decision downstream of discovery.

When a sitemap isn't necessary

A small site — roughly under 500 pages, as a rough guide rather than a hard cutoff — with solid internal linking and a reasonably shallow site structure is usually discovered efficiently by crawlers without a sitemap at all. If every page is reachable within a few clicks from the homepage through normal navigation and internal links, a sitemap adds little. This surprises people who've internalized "sitemaps are always good practice," but Google's own guidance has been consistent that sitemaps matter more as a site grows larger, has content that's hard to discover through normal linking (deep archives, content behind search/filter interfaces), or is new enough that it hasn't accumulated much external linking yet to aid discovery.

When a sitemap earns its keep

Sitemaps become genuinely valuable for:

  • Larger sites, where crawl efficiency benefits from an explicit, complete URL list rather than relying entirely on link discovery
  • New sites, which haven't yet built up external links that would otherwise help search engines find and prioritize their pages
  • Sites with content that's hard to reach through normal navigation — deep paginated archives, content only surfaced through an internal search or filter interface
  • Sites that publish frequently, where a sitemap's lastmod data can help a crawler prioritize re-crawling recently changed pages over static ones

The most common mistake: stale lastmod dates

A <lastmod> timestamp that doesn't accurately reflect when a page's content genuinely changed is the single most common sitemap mistake — either left static from initial creation and never updated, or worse, auto-updated on every deploy regardless of whether the actual content changed. Once a search engine's crawler notices that lastmod dates don't correlate with real content changes, it has reason to discount that signal across the whole sitemap, not just the specific inaccurate entries — undermining the one piece of prioritization data a sitemap can uniquely provide beyond a plain URL list.

The fix is mechanical but requires actual discipline: only update lastmod when the page's meaningful content changes, not on every deploy or template update that leaves the actual content untouched.

Only include canonical, indexable URLs

A sitemap should list only the canonical version of each URL, and only URLs you actually want indexed. Including noindexed pages, redirected URLs, or non-canonical duplicate variants sends a contradictory signal — the sitemap is effectively saying "index this" while another directive on the page itself says the opposite. This is a surprisingly common issue on larger sites where the sitemap is generated by a process that doesn't stay in sync with noindex tags or canonical decisions made elsewhere in the codebase, and it's worth an occasional audit specifically checking for this mismatch.

Single sitemap vs. sitemap index

A single sitemap file supports up to 50,000 URLs, which is more than enough for the significant majority of sites. A sitemap index — a file referencing multiple child sitemaps — is only necessary past that threshold, or when it's genuinely useful to separate distinct content types (articles vs. product pages vs. category pages, for instance) into their own sitemaps for organizational or reporting clarity. Splitting into multiple sitemaps below the URL threshold, purely because it seems more sophisticated, adds complexity without adding any real benefit.