Use Sitemap lastmod Dates Without Faking Freshness

Separate two kinds of timestamps

An article's modification date and the timestamp of your latest deployment answer different questions. The first describes the content; the second describes the software release. Google advises using accurate lastmod values for meaningful page changes. A common implementation mistake is assigning today's date to every URL whenever a site builds. That makes a corrected paragraph and an unrelated stylesheet update look identical. Start by naming your fields clearly: publishedAt, contentUpdatedAt, and deployedAt. Different names make it harder for the wrong timestamp to leak into the sitemap.

Define an editorial change policy

Write down what your team considers a substantive revision. For a technical tutorial, replacing obsolete instructions or correcting a broken procedure qualifies under a sensible editorial policy. Adjusting a footer's spacing generally does not. A major change to the main page content can justify a new modification date, even if the URL remains stable. Avoid relying on a raw database updatedAt field when autosaves, internal labels, or assignment changes also touch the record. The relevant event is the publication of a meaningful change, not every movement inside the CMS.

A hypothetical update history

Imagine a guide published on March 4, with a typography release on March 6 and a corrected API example published on March 9. Under the proposed policy, the guide keeps March 4 after the typography release and advances to March 9 when the correction becomes public. If an editor drafts another revision on March 12 but does not publish it, the public modification date stays unchanged. This history can live beside the content record. It provides a useful explanation when a writer asks why an article's date did or did not move.

Design dates into the workflow

Have the publishing action set contentUpdatedAt only when an approved content revision is released. Preserve the original publication date. If your content lives in files, an explicit metadata field is often easier to audit than a filesystem modification time, which can change during checkout or packaging. Use a consistent date format supported by the sitemap protocol. Test revisions across time zones and ensure future scheduled content does not produce a modification date ahead of its actual publication. The same editorial event can also update the visible revision notice.

Audit a small sample before automation

Compare several sitemap dates with revision records, including an untouched page, a recently corrected guide, and a draft awaiting approval. If the system cannot distinguish these cases reliably, leaving the optional lastmod value out is more honest than filling it with a build timestamp. Keep the implementation modest: a clear editorial field is often sufficient. Dates help communicate changes, but they are not an independent reason for a reader to revisit a page. The underlying update should improve accuracy, usefulness, or completeness enough that a returning reader can explain what changed.

Include a short revision note with substantial updates. That note gives readers a useful explanation and gives future editors evidence for the date without requiring them to reconstruct every historical change.