XML Sitemap Best Practices: lastmod, Index & CMS URLs

XML sitemap best practices come down to four rules: list only canonical, indexable URLs, set lastmod only when a page meaningfully changes, split large or mixed sites with a sitemap index, and generate sitemaps dynamically. Google ignores priority and changefreq, so accurate lastmod values matter more than extra tags.

Most guides stop at file size limits. The decisions that affect crawling are subtler: where your lastmod values come from, how you split the files, and which CMS-generated URLs should never be listed fundamentals we cover as part of our technical SEO work. This article covers those.

What Search Engines Read in a Sitemap

A sitemap is a list of URLs with optional metadata. Search engines treat it as a hint, not an instruction. Google states that a sitemap does not guarantee every listed URL will be crawled or indexed.

Only two of the four common tags do anything:

Leaving priority and changefreq in place does no harm, but tuning them is wasted effort. The one optional tag worth attention is lastmod.

How to Set lastmod So Search Engines Trust It

Google has said it uses lastmod when the values are consistently and verifiably accurate, and that it may ignore values it considers unreliable. Bing has said it uses the tag to decide how often to crawl a site and which pages to index.

The format is a W3C Datetime value, either a date or a full timestamp:

<lastmod>2026-09-30</lastmod>

<lastmod>2026-09-30T14:05:00+00:00</lastmod>

The hard part is not the format. It is making sure the date changes when the page changes, and only then.

What Counts as a Significant Update

Google describes a significant update as a change to the main content, structured data or links on a page. It does not include an updated copyright year.

Hub pages such as category archives are a judgment call. When a new item appears in the listing, the page's links have changed, so a new lastmod is defensible. What matters is applying the same rule every time.

Where False lastmod Dates Come From in a CMS

A sitemap plugin or script that produces wrong dates can undermine the field for the whole site. A dynamic sitemap can make this worse, because it stamps wrong dates on every URL automatically.

If your setup cannot produce accurate dates, leave lastmod out. Omitting the tag is better than supplying dates that teach Google to ignore it.

Index lastmod vs URL lastmod

Two different dates share the same tag name.

In a sitemap index, lastmod describes when the child sitemap file changed. In a child sitemap, lastmod describes when each page changed.

<!-- sitemap_index.xml -->

<sitemap>

  <loc>https://www.example.com/sitemap-posts.xml</loc>

  <lastmod>2026-09-30</lastmod>

</sitemap>

<!-- sitemap-posts.xml -->

<url>

  <loc>https://www.example.com/blog/sitemap-guide/</loc>

  <lastmod>2026-09-28</lastmod>

</url>

Yoast's sitemap specification sets the index value to the most recent lastmod found inside the child sitemap. Nuxt Sitemap adds a related point: when URLs move between files because entries were added or removed, the index lastmod must be updated for every affected file.

How to Audit lastmod Accuracy

1. Export the sitemap with its dates. A crawler such as Screaming Frog can read sitemap URLs and their lastmod values.

2. Check the distribution. If every URL carries the same date, or dates match the last time the sitemap was built, the logic is broken and the rest of the audit is unnecessary.

3. Sample across content types. Include pages you know have not been edited for months.

4. Compare each sampled date with reality. Check the CMS modified field and what actually changed on the page.

5. Check again after a rebuild or a day. Dates that move for unedited pages point to a generation problem.

6. Fix the source or remove the tag. Patching individual dates does not help if the logic is wrong.

If this kind of check keeps surfacing template-wide issues rather than one-off mistakes, that's usually a sign it's worth a full SEO audit rather than another round of manual patching.

Sitemap Index Files and Segmentation

When You Need a Sitemap Index

A single sitemap can hold up to 50,000 URLs and 50MB uncompressed. Past either limit, split the URLs across several sitemaps and list them in a sitemap index file.

The index follows a few rules from Google's documentation:

• Referenced sitemaps must be on the same site as the index. An index cannot reference sitemaps on a different subdomain.

• Referenced sitemaps must sit in the same directory as the index or lower in the site hierarchy.

• One index can list up to 50,000 sitemaps.

• Search Console accepts up to 500 sitemap index files per property.

• Submit the index URL. Google follows the references.

The limits are a minimum reason to use an index. The better reason is segmentation, which lets you see how different parts of the site are indexed.

How to Segment

Do not split without a reason. Google has warned against putting only a handful of URLs in each file, because it makes the full set slower to download. Yoast's default is 1,000 URLs per file, which is convenient for WordPress sites but well under Google's limit. Sites can raise it.

Use Segments to Diagnose Indexing

Segmentation pays off in Search Console. Submit the index, then compare each child sitemap's submitted URLs against indexed URLs. The Pages report can be filtered to a specific submitted sitemap to see the reasons pages are not indexed, segment by segment.

For example, if product URLs show a much larger gap than blog posts, the cause is probably in the product template: thin pages, duplicate variants or canonical conflicts. A single combined sitemap would average that signal away a pattern we see often when auditing ecommerce SEO clients with large catalogs.

Dynamic Sitemaps

A static sitemap is a hand-maintained file and goes stale as soon as content changes. A dynamic sitemap is generated from your content database or build, so new and removed pages appear without manual work. A static file is only reasonable for a small site that rarely changes.

Dynamic generation does not guarantee accuracy. It only guarantees speed. What matters is where each approach gets its lastmod.

Nuxt's documentation makes a useful distinction. If pages only change when you commit and deploy, generate the sitemap at build time. If a CMS updates content without a redeploy, or users create content, generate at runtime.

Scale adds cost. A GitHub issue filed against Yoast SEO describes a large site where building the sitemap index ran a sorting query for each post type to find the lastmod of each sitemap page. The proposed mitigation was a cheaper, less precise value for the index. Very large sites should cache sitemap output and avoid computing index dates from scratch on every request this kind of scale-specific tuning is exactly what our enterprise SEO engagements focus on.

Which CMS URLs Belong in a Sitemap

A URL belongs in a sitemap if it is canonical, returns a 200 status, is indexable, and is a page you want to appear in search. The sitemap should agree with your noindex, canonical and robots.txt signals. Conflicts between them waste crawl effort.

Sources disagree on paginated archives. Some guides exclude them outright. The safest rule is the same one used for every other URL: include a paginated page only if it is indexable and you want it in search results.

To find pages missing from your sitemap, Search Console's "Indexed, not submitted in sitemap" status lists indexed URLs you did not submit.

Submitting and Monitoring Your Sitemap

• Reference the sitemap in robots.txt with an absolute URL, such as Sitemap: https://www.example.com/sitemap_index.xml. Any crawler can discover it from there.

• Submit the index in Google Search Console under Indexing, then Sitemaps.

• Submit it in Bing Webmaster Tools as well.

• Check the report. Look at status, discovered URLs, and the gap between submitted and indexed pages.

• Recheck after migrations and CMS changes, when sitemap logic most often breaks.

Google retired ping-based sitemap submission in late 2023, so lastmod, robots.txt and Search Console are the working channels. Google's older guidance also recommended pairing sitemaps with RSS or Atom feeds: sitemaps list all pages, while feeds surface recent updates.

Sitemap Audit Checklist

• [ ] Every listed URL is canonical, indexable and returns 200

• [ ] No noindex, redirecting, 404 or robots.txt-blocked URLs

• [ ] lastmod comes from real content changes, not build or generation time

• [ ] Sampled dates match actual page edits

• [ ] Index lastmod matches the newest date in each child file

• [ ] Files are split by content type, locale or year for a stated reason

• [ ] No file exceeds 50,000 URLs or 50MB uncompressed

• [ ] The index is referenced in robots.txt and submitted in Search Console and Bing Webmaster Tools

• [ ] Submitted versus indexed counts have been reviewed per segment

Conclusion

Three changes have the largest effect. Fix the source of your lastmod values so they reflect real content changes. Remove URLs that are not canonical and indexable, especially CMS-generated ones. Segment the index by content type so Search Console shows where indexing problems sit.