sitemap.xml lastmod — why stamping every URL with today hurts you

Most XML sitemaps lie. Not on purpose. The generator stamps <lastmod> with the build time. Every URL gets the same date. The site owner thinks freshness is sorted. It is not. Google reads that signal, decides it is noise, then stops using lastmod for the whole host. The fix is unglamorous: write an honest date or write nothing.

How Google actually uses lastmod

Google's official sitemap reference (developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap) says lastmod must reflect "the date and time of the last significant update to the page" and that Google "uses the value if it's consistently and verifiably accurate, for example by comparing to the last modification of the page." The verification clause is the part most generators ignore. If the date you publish does not line up with what Googlebot finds in the rendered HTML on its next fetch, trust erodes.

Gary Illyes, an analyst on the Google Search team, made the consequence blunt in a June 2024 LinkedIn exchange with Mark Williams-Cook: lastmod trust is "binary: we either trust it or we don't." There is no gradient, no per-URL forgiveness, no slow rebuild after a bad month. One verdict, sitewide. The leaked Content Warehouse API surface from May 2024 corroborated the binary flag at the host level. If Google flips it off, the rest of your accurate dates stop earning crawl priority too.

<priority> and <changefreq> were already declared dead by Google years ago. lastmod is the only freshness hint left in the sitemap protocol that any major crawler still reads. Burning it because the WordPress generator was lazy is an expensive own-goal.

What "significant change" means

Google updated the sitemap docs on June 21, 2024 to spell this out. A significant change is an edit to "the main content, the structured data, or links on the page." A copyright year bumping in the footer is not significant. Neither is a sidebar widget rotating, a tracking script swap, a CSS refresh, or a comment count ticking up. Yoast and RankMath have both shipped issues where related-posts modules or comment timestamps re-stamped lastmod on otherwise unchanged URLs — that is the exact pattern Google calls out.

The test John Mueller has used in office-hours threads: would a returning reader notice the change? If yes, stamp it. If you would not bother emailing a subscriber about the edit, leave the date alone.

Correct vs incorrect lastmod

Here is what a generator-with-no-judgment produces. Every URL claims it changed at the moment the sitemap was rebuilt:

<!-- BAD: stamped-now sitemap -->
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-04-30T08:00:00+00:00</lastmod>
  </url>
  <url>
    <loc>https://example.com/about</loc>
    <lastmod>2026-04-30T08:00:00+00:00</lastmod>
  </url>
  <url>
    <loc>https://example.com/blog/post-from-2021</loc>
    <lastmod>2026-04-30T08:00:00+00:00</lastmod>
  </url>
</urlset>

The honest version uses each page's real last-edit timestamp. Pages that have not been touched in years say so:

<!-- GOOD: per-URL, real edit timestamps -->
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-03-12T14:22:08+00:00</lastmod>
  </url>
  <url>
    <loc>https://example.com/about</loc>
    <lastmod>2025-09-04</lastmod>
  </url>
  <url>
    <loc>https://example.com/blog/post-from-2021</loc>
    <lastmod>2021-06-18</lastmod>
  </url>
</urlset>

Both formats are valid W3C Datetime per the sitemaps.org 0.9 schema. YYYY-MM-DD is fine when you do not have a time. YYYY-MM-DDThh:mm:ss+00:00 is the full ISO 8601 form Bing's documentation recommends.

Bing reads it the same way

Fabrice Canel, Principal Product Manager at Microsoft Bing, announced in February 2023 that Bing was rebuilding its crawl scheduler to lean harder on lastmod. A Bing study he cited found 18% of sitemaps with a lastmod attribute set every URL to the same date — the sitemap-generation timestamp rather than the per-page edit time. Bing's July 2025 follow-up post for AI-powered indexing repeated the warning: "Avoid setting lastmod to the time your sitemap was generated unless the content on that URL was actually updated."

So the same misbehavior burns trust on both engines. Bing also ignores changefreq and priority, leaving lastmod as the lone hint there too.

How crawlers cross-check you

Lastmod is not the only freshness probe. When Googlebot or Bingbot fetches a URL listed in your sitemap, the request often carries an If-Modified-Since header containing the timestamp from the last successful crawl. If your origin returns 304 Not Modified, the crawler trusts the body has not changed and moves on. If you returned 200 with identical bytes after claiming a fresh lastmod, the crawler now has direct evidence the sitemap lied. Repeat that across thousands of URLs and the binary trust flag flips off.

This is why a stamped-now sitemap on a static blog is worse than no lastmod at all. Better to omit the element on URLs you cannot track than to publish a date the crawler will disprove on its next fetch.

CMS gotchas worth checking

The platform defaults vary, and the failure modes are specific:

• WordPress core added native lastmod support in WordPress 6.5 (April 2024), pulling from post_modified_gmt. That field updates whenever the post is saved — including a no-op edit from the editor — so a translator opening and closing a post re-stamps it.

• Yoast SEO uses the post's modified date per URL and rolls each child sitemap's most recent date into the index. A misconfigured comment plugin that touches post_modified will leak through.

• Rank Math caches sitemap output aggressively. Real edits will not surface in the lastmod until the sitemap cache is invalidated, and custom sitemap providers use the array key mod (not lastmod) at the URL level, which is a frequent source of dates silently disappearing.

• Shopify generates sitemaps automatically and updates lastmod when product fields change, but inventory-level updates also touch the date, which inflates "freshness" on otherwise unchanged product pages.

• Webflow stamps lastmod whenever the site is republished. Republishing for a global font swap re-stamps every page on the site. The fix is to publish only after content edits, not styling tweaks.

• Static site generators (Astro, Next.js, Hugo) usually pull from the source file's mtime. That breaks the moment a CI step rewrites every file during build. The safe pattern is reading the git log: git log -1 --format=%cI -- path/to/file.md.

Verify before shipping

isitready.dev fetches your sitemap, samples a slice of URLs, then flags two failure patterns that wreck lastmod trust: every URL sharing one timestamp, plus lastmod values that disagree with the page's own dateModified schema or the response body served at the URL. Run it at isitready.dev before the next deploy that touches the sitemap pipeline.