Do not update sitemap lastmod unless the page content actually changed

Do not update sitemap lastmod unless the page content actually changed. A sitemap date that changes every time a build runs gives readers and crawlers a noisy freshness signal. It also makes source trails harder to audit because the date no longer points to a meaningful revision.

Google Search Central describes sitemaps as a way to help Google discover URLs and notes that sitemap submission is a hint, not a guarantee. The sitemap protocol uses lastmod to express when the URL was last modified. For a publisher or product team, the useful practice is to connect that date to a real page-level change: updated facts, revised guidance, changed pricing, corrected examples, new sections, removed stale claims, or changed structured data that affects what the page says.

A practical lastmod checklist can ask: Did visible body content change? Did a key table, quote, price, policy, or example change? Did structured data change in a way that represents the page differently? Can the change be explained in a note? If the answer is only “the site was rebuilt,” “the template timestamp changed,” or “the footer was regenerated,” the sitemap date should usually stay where it was.

This is especially important for source curation. A future reader should be able to compare two dates and understand why the page looked newer. If every deploy refreshes every date, the trail loses that signal and a real correction becomes harder to spot.

Do not update sitemap lastmod unless the page content actually changed

// COMMENTS

ON THIS PAGE