XML Sitemap Best Practices That Actually Matter
Half of the standard sitemap advice is folklore. These are the practices search engines actually respond to, and the fields they ignore.
A good XML sitemap lists every canonical, indexable page that returns HTTP 200, carries an honest lastmod date, stays under 50,000 URLs and 50 MB per file, and is referenced from robots.txt. Everything else, including changefreq and priority, is either optional or actively ignored by modern search engines.
List only pages you want indexed
A sitemap is a statement of what you consider canonical. Every URL in it should be the canonical version of a real page that returns 200 and is open to crawling. Leave out redirects, 404s, parameter variants, paginated duplicates, noindexed pages and thin utility pages. When a sitemap disagrees with your canonical tags or robots.txt, crawlers trust the site signals and learn to discount the sitemap.
Make lastmod honest or leave it out
Of the three optional fields, <lastmod> is the only one Google confirms using, and only when it is trustworthy. Two rules follow. First, use W3C format: 2026-07-16 is enough; the time component is optional. Second, update it only when page content meaningfully changes. A CMS that stamps every URL with the last deploy time destroys the field's value sitewide.
Stop tuning changefreq and priority
Google ignores both fields and has said so publicly for years; Bing behaves much the same. They do no harm when well-formed, and validators only flag malformed values, but every hour spent tuning priority from 0.8 to 0.9 is wasted. Crawl frequency is driven by lastmod accuracy, internal linking and demand for the page.
Know the myths from the mechanics
| Common belief | Reality |
|---|---|
| Priority 1.0 makes a page rank higher | Priority is ignored; it never affected rankings |
| changefreq=always brings crawlers daily | Crawl rate follows demand and lastmod, not changefreq |
| A sitemap guarantees indexing | It only aids discovery; quality decides indexing |
| Every site needs a sitemap | Small, well-linked sites are crawled fine without one |
| One sitemap must hold the whole site | Split freely; the index file exists for this |
| Submitting repeatedly speeds up crawling | Resubmission does nothing unless the file changed |
Split before you hit the limits
Hard caps: 50,000 URLs and 50 MB uncompressed per file. In practice, split earlier along content lines: posts, products, categories, each in its own sitemap, referenced by one sitemap index. Segmented sitemaps also make Search Console coverage reports far more readable, since indexing problems show up per segment instead of in one 40,000-URL haystack.
Serve it right
Three server-side rules. Return HTTP 200 with an XML content type. Compress with gzip if the file is large; crawlers accept .xml.gz. Keep the URL stable: a sitemap that moves needs a 301 and a fresh submission.
Announce it in robots.txt and submit it
Add one line to robots.txt so every crawler finds the sitemap without an account:
Sitemap: https://example.com/sitemap.xmlThen submit once in Google Search Console and Bing Webmaster Tools. Submission gets you the error reporting; robots.txt covers everyone else. Resubmit only when the sitemap URL itself changes, not on every content update: crawlers re-fetch sitemaps on their own schedule, guided by your lastmod.
Regenerate automatically
A sitemap maintained by hand is a sitemap that is wrong. Wire generation into your build or CMS so every publish, update and deletion is reflected. Static sites regenerate at build time; dynamic sites either render the sitemap on request with caching or on a schedule. Whichever route you take, validate the output after any generator change; template edits are how namespaces and date formats quietly break.