<lastmod>

The <lastmod> element marks when a URL's content last changed. Google's own John Mueller and Gary Illyes have stated repeatedly that <lastmod> is the one sitemap field Google actually pays attention to — and they've also stated that they ignore it from sites whose <lastmod> values are demonstrably wrong (citation: Google Search Central blog, 2023).

Format

The W3C Datetime format. Both forms below are valid:

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

Use the timestamped form when you actually have time precision; otherwise the date-only form is fine and conveys honest precision.

What counts as "modified"

<lastmod> must reflect a change to the content the URL serves. Examples:

The rule of thumb: if a reader would notice the change, update <lastmod>. If only your CMS or build system would notice, don't.

Why most sites get it wrong

Static-site generators often set <lastmod> to the build timestamp — every URL gets bumped on every deploy. Search engines learn fast that this is meaningless and ignore the field for that domain. Gary Illyes called this out at Search Central Live 2023: most sites have garbage lastmod values, so we mostly ignore them.

The fix is to source <lastmod> from the underlying content store (the article's updated_at column, the CMS modification date, the git commit touching that page's Markdown), not the build timestamp.

Common mistakes

• Build timestamp on every URL. See above. Use content-modification timestamps.
• Bumping lastmod to trick recrawls. Doesn't work and trains the search engine to distrust the field for your whole domain.
• Missing the timezone offset. 2026-05-18T14:30:00 is ambiguous. Use Z or +00:00.
• Future timestamps. Some misconfigurations emit a tomorrow date. Google drops these.

What SitemapHost does

SitemapHost takes <lastmod> from each URL entry you push via the API. If you push a URL with lastmod: '2026-05-18T14:30:00Z', that's what gets served. If you omit it, no <lastmod> is emitted — better than a bad one.