XML sitemaps: what they do and don't do for indexing

The XML sitemap is SEO's most over-credited file. Sites add one and expect indexing to follow; when it doesn't, they conclude sitemaps are broken. Both the hope and the disappointment come from the same misunderstanding of what the file is for.

What does a sitemap actually do?

Three things, all real but modest:

1. Discovery. It hands search engines a list of URLs you consider canonical, so they don't have to find every page by following links. This matters most for new sites, deep archives, and pages with few internal links.
2. Change signaling. An honest lastmod tells crawlers which pages changed since their last visit, which helps large sites get updates recrawled faster.
3. Diagnostics. Submitting a sitemap in Search Console unlocks per-sitemap indexing stats — the cleanest way to see what fraction of your important pages Google has actually indexed.

What it does not do: force indexing, improve rankings, or excuse thin content. Google treats it as a hint and still decides page by page.

What are the sitemap limits and rules?

• 50,000 URLs or 50MB (uncompressed) per file. Beyond that, split into multiple sitemaps listed in a sitemap index file.
• Canonical URLs only. No redirects, no 404s, no noindex pages, no parameter duplicates. Every non-canonical URL in a sitemap is a small contradiction you're feeding Google — and "sitemapped but noindexed" shows up as an error in Search Console.
• Absolute URLs on the right host. https://www.example.com/page, not /page — and matching your canonical host (www vs apex).
• Declare it in robots.txt (Sitemap: line) and submit it in Search Console.

Run any sitemap through our sitemap checker to verify structure, counts and size in one pass.

Why is lastmod special?

Because Google only uses it if you don't lie. Their documentation is explicit: lastmod is used when it's "consistently and verifiably accurate." The most common failure is automated: a build pipeline that stamps every URL with the deploy date. After a few deploys, every page has "changed" five times with identical content — and Google discounts the field sitewide, including for the pages that really did change.

The fix: derive lastmod from content dates (the post's updated date, the product's modified date), never from build time. If you can't get an honest date, omit the field — absent beats false.

My pages are in the sitemap but not indexed. Now what?

The sitemap did its job — discovery — and Google declined anyway. The reason lives elsewhere:

• "Crawled – currently not indexed": usually a quality/duplication judgment. The page needs to be more substantial or more distinct.
• "Discovered – currently not indexed": crawl priority. Add internal links from strong pages; the sitemap alone isn't a strong enough invitation.
• Technical contradictions: a stray noindex, a canonical pointing elsewhere, a robots block. A single-page check surfaces all three in seconds; our guide to why pages don't get indexed walks the full decision tree.