Sitemap lastmod: Accurate Page and Index Timestamps

The lastmod element tells a crawler when the page content last changed in a meaningful way. Search engines may use a consistently accurate value when deciding what to recrawl. It is not an instruction and it does not make a page look fresh simply because the date is recent.

Update lastmod when the primary content, structured facts, availability, pricing, documentation, or other information visible to search users changes materially. The exact rule depends on the page type, but it should always map to a user-visible reason to revisit the URL.

Do not update every URL after a deployment, cache purge, analytics event, view count, background job, or unrelated record change. Those events create uniform timestamps that say nothing about individual page freshness.

For CMS pages, use a timestamp advanced by significant published changes. A review that changes nothing is not a modification; a review timestamp must not override a later substantive edit. For ecommerce, derive a timestamp from meaningful visible facts. For data-driven profiles, use when materially different data was published, not every successful collection time: identical fetched data does not modify a page.

Persist the source timestamp and serialize a W3C date or datetime. UTC is convenient, but explicit timezone offsets are valid. Use YYYY-MM-DD when that is the precision you know; do not invent a time of day. Omit lastmod if no reliable source exists for that page.

Publication records when a page first became public. Page lastmod records its latest significant change. Index lastmod records when the referenced sitemap file changed, not when an arbitrary page inside it changed. An HTTP Last-Modified header is a separate signal; the protocol does not require crawlers to interpret it identically to XML lastmod.

Google names primary text, structured data, and links as examples of significant updates. Apply that to the page's substance: changing relevant facts or links can matter, while a sidebar punctuation edit, copyright year, or view-count increment normally should not advance every page date.

Define significant fields for each template and persist contentModifiedAt when a published change affects them. An article might track its body, cited facts, and relevant structured data; a product might track price, availability, and specifications. Keep this separate from record updatedAt fields advanced by synchronization, review queues, or analytics writes.

For an aggregate homepage or category, record when displayed inventory or primary content materially changes. Do not take the maximum updatedAt across all related rows regardless of whether they appear on the page. If you cannot determine an honest value for those aggregates, omit it there while retaining reliable dates for other URLs.

Save a sitemap snapshot and source dates before an ordinary deployment. Regenerate without content edits and compare: unchanged pages should not advance. Publish a meaningful edit to one page, then verify that its date advances while unrelated entries remain stable. Check the child's index-level file date separately.

Checker reports coverage, oldest and newest valid dates, and future-date counts; these cannot prove correspondence with real edits. Compare a sample from each template with publishing records. A calendar-valid future date can be reported without invalidating the document structurally. Check timezone and scheduled-publication handling before assuming deliberate freshness manipulation.

Sample URLs from every sitemap type and compare the XML value with the page's visible update date and source record. Look for impossible future dates, every URL changing together, dates older than the content, and values that change on every request.

If you cannot produce a stable, verifiable value, omit lastmod while you fix the source. Absence creates less noise than a timestamp that routinely misrepresents the page.