The Sitemap Basics Most People Get Wrong
XML sitemaps are one of those things every SEO knows about but few implement well. The concept is simple: give search engines a list of URLs you want crawled and indexed. The execution? That's where things get messy.
A properly structured sitemap looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/page-one</loc>
<lastmod>2026-03-15</lastmod>
<changefreq>monthly</changefreq>
<priority>0.8</priority>
</url>
</urlset>Simple enough. But let's talk about what each of those tags actually does — and doesn't do.
Priority: The Tag Google Ignores
Here's the thing: Google has officially stated they ignore the <priority> tag. They said it back in 2018, and nothing has changed. The reasoning makes sense when you think about it — every site owner would set their homepage to 1.0 and every page to 0.9, making the data meaningless.
Bing says they use it as a "hint," but in practice, I've never seen evidence that changing priority values affects crawl behavior on Bing either. My recommendation? You can include it for completeness, but don't spend any time optimizing priority values. That time is better spent elsewhere.
Lastmod: Useful When Accurate, Harmful When Not
The <lastmod> tag is different — Google does pay attention to this one, but only if you keep it accurate. And that's the catch.
If your CMS updates lastmod every time someone fixes a typo or changes a comma, Google will eventually learn that your lastmod values are unreliable and start ignoring them. Google's Gary Illyes has said exactly this: they track whether a site's lastmod correlates with actual content changes, and they adjust their trust accordingly.
Best practice: only update lastmod when the page content changes meaningfully. A few CSS tweaks or a sidebar widget update shouldn't trigger a lastmod change. Most CMS platforms get this wrong by default. WordPress, for instance, updates the modified date on any save — you'll need a plugin or custom function to only update it on substantial content changes.
Date Format Matters
Use W3C datetime format. All of these are valid:
2026-03-15— date only (most common)2026-03-15T10:30:00+00:00— with time and timezone2026-03-15T10:30:00Z— UTC time
Don't use formats like "March 15, 2026" or unix timestamps. I've seen both in the wild, and neither works.
Changefreq: Also Largely Ignored
Similar to priority, <changefreq> (always, hourly, daily, weekly, monthly, yearly, never) isn't something Google relies on. They determine crawl frequency based on their own observations of how often your content actually changes. Including it doesn't hurt, but it won't speed up crawling.
Sitemap Index Files: When and How to Split
This is where sitemap management gets interesting for larger sites. The protocol limits each sitemap file to 50,000 URLs and 50MB uncompressed. If you've got more URLs than that, you need a sitemap index.
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemap-posts.xml</loc>
<lastmod>2026-03-15</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-products.xml</loc>
<lastmod>2026-03-14</lastmod>
</sitemap>
</sitemapindex>But even if you're under 50,000 URLs, splitting sitemaps by content type is smart. Here's why: when Google sees that sitemap-products.xml has a recent lastmod, it knows to re-crawl just the product pages. If everything's in one file, that signal is diluted.
My Recommended Split Strategy
- Blog posts / articles in one sitemap
- Product or service pages in another
- Category and tag pages (if indexed) separate
- Static pages (about, contact, etc.) in their own file
- Image sitemaps separate if you have significant image SEO needs
For e-commerce sites with 100,000+ products, I'd split products further — by category or by date range. The goal is to keep each sitemap file focused and its lastmod meaningful.
Common Sitemap Mistakes
Including Non-Indexable URLs
Your sitemap should only contain URLs that return 200 and are indexable. Don't include URLs that are noindexed, canonicalized to a different URL, blocked by robots.txt, or return 3xx/4xx/5xx status codes. Google won't penalize you for this, but it sends mixed signals and wastes crawl budget on large sites.
Forgetting to Gzip
Compress your sitemaps. A sitemap that's 10MB uncompressed might be 500KB gzipped. Name the compressed file with a .xml.gz extension. Every major search engine supports gzipped sitemaps, and you'll reduce server bandwidth significantly on large sites.
Not Referencing in Robots.txt
Always add a sitemap directive to your robots.txt:
Sitemap: https://example.com/sitemap.xmlThis ensures crawlers discover your sitemap even if you haven't submitted it through Search Console or Bing Webmaster Tools.
Stale Sitemaps
If your sitemap hasn't been updated in months but you're publishing new content weekly, that's a problem. Set up automatic sitemap regeneration — most CMS platforms handle this, but verify it's actually working. I've seen WordPress sites where the sitemap plugin silently stopped updating after a theme change.
Sitemap Submission and Monitoring
Submit your sitemap through Google Search Console and Bing Webmaster Tools. After submission, check back in a few days. Search Console will show you how many URLs were submitted versus how many were indexed. A large gap between submitted and indexed URLs is a signal that something's off — either the URLs have quality issues, or they're being excluded for technical reasons.
One thing people miss: you can submit individual sitemap files directly, not just the index. This lets you see indexing stats per content type, which is genuinely useful for diagnosing section-specific issues.
Don't obsess over sitemaps — they're a hygiene factor, not a ranking factor. Get them right, automate the generation, check them quarterly, and move on to work that has a bigger impact on your traffic.