The lastmod value in an XML sitemap tells crawlers when a URL was last meaningfully modified. Used accurately, it can help search engines distinguish genuinely changed pages from unchanged ones. Used carelessly, it becomes noise: every page appears freshly updated even when nothing important changed.
The field is optional. A missing lastmod value is not a sitemap error. Publishing a truthful date is more useful than filling the field with an automatic timestamp that changes on every build.
What lastmod is supposed to represent
lastmod refers to the modification time of the page at the URL, not the time the sitemap file was generated or submitted. For an article, a meaningful modification might include correcting outdated facts, adding a substantial section, replacing obsolete instructions, or changing the primary content.
A deployment that only minifies HTML, rotates an advertisement, updates a global footer, or rebuilds an unchanged page does not necessarily justify a new date. This distinction is especially important on static sites where a build can rewrite many files at once.
Why truthful dates matter
Crawlers need to allocate requests across large numbers of URLs. A dependable lastmod signal can indicate that a previously known page changed. If a site marks every URL as modified today, the value no longer distinguishes real updates.
Google’s sitemap documentation says the field is optional and should reflect the last significant update to the page. Reliability matters more than making every entry look recent.
Dates that usually deserve an update
- A guide gains new instructions, examples, or verified facts.
- A product or service page changes its main offering.
- An event page changes date, venue, or availability.
- A legal or policy page receives a substantive revision.
- An article corrects an error that affects its meaning.
- A category page changes because its visible inventory changes materially.
The decision should reflect the user-facing resource. If a returning visitor would reasonably consider the page updated, changing lastmod is usually defensible.
Changes that often do not justify a new value
Minor typography adjustments, tracking-code changes, cookie banner updates, and navigation changes may modify HTML without altering the page’s main content. Automatically deriving lastmod from the file system can therefore be misleading.
Similarly, changing a displayed “updated” date without changing the article does not make the content fresher. The timestamp should describe the resource, not the deployment process.
Publication date and modification date are different
A newly published article has an original publication date. If it is later revised, it can also have a modification date. The sitemap’s lastmod should normally reflect the latest meaningful change, while the page can preserve the original publication date for readers and archive ordering.
How to implement lastmod on a static site
Store a deliberate modified date in each post’s metadata. The build script should use that value rather than the operating system’s file timestamp. If no revision has occurred, the publication date can serve as the initial lastmod value.
When an editor changes an article meaningfully, update the metadata. The generator can then use the same value in the XML sitemap and structured data. This creates a traceable publishing workflow instead of guessing from deployment time.
Handling category and archive pages
Category pages change when new articles are added, removed, or reordered. It is reasonable to update their lastmod value when the visible listing changes. Avoid updating every archive page merely because one article elsewhere on the site changed.
Sitemap index lastmod has a different meaning
In a sitemap index, lastmod describes the child sitemap file rather than an individual page. Update it when the set of URLs or relevant metadata in that child file changes.
This difference is covered in XML Sitemap vs Sitemap Index. Mixing page modification times with child-file modification times creates inaccurate metadata.
How to audit your current dates
Sort sitemap entries by lastmod. Look for future dates, invalid values, identical timestamps across the entire site, and values that change every day. Compare a sample with revision history or content records.
The checks in How to Check an XML Sitemap for Errors can be extended to flag suspicious date patterns. The related Sitemap Checker can also help inspect sitemap structure and date usage in the browser.
Do not use lastmod as a recrawl button
Changing a date is not a command and does not guarantee immediate crawling or indexing. Repeatedly setting today’s date on unchanged content can make the signal less useful rather than speed up processing.
When an important page changes, update the content, publish an accurate lastmod, keep internal links and canonicals consistent, and use search-engine inspection tools when a manual request is justified.
The simplest reliable policy
Include lastmod only when the publishing system can maintain it honestly. Tie the value to meaningful page revisions, keep publication and modification dates separate, and avoid using deployment timestamps as a shortcut.
A clean sitemap without lastmod is better than a file full of false freshness. Accuracy gives the field its value.