A sitemap modification date should reflect a meaningful change to the resource. Rebuilding a site does not necessarily modify every article. Keep publication, substantive revision, and deployment dates separate in the content system.
Google's sitemap guidance, checked September 9, 2026, says it uses lastmod when the value is consistently accurate. Significant changes can include main content, structured data, or links; a copyright-year update is not the same thing. Google also says it ignores sitemap priority and changefreq values.
The practical job is to keep the generated sitemap aligned with editorial records. A date field that always becomes “today” tells the team very little about what actually changed.
Keep a small change record per resource
Record the URL, publication date, substantive modification date, revision reason, and responsible editor. Add an inclusion state so drafts and retired resources are handled deliberately.
| Illustrative change | Date decision | Record to preserve |
|---|---|---|
| New guide published | Set the actual publication date | Approved content revision |
| Outdated setup steps replaced | Update substantive modification date | What changed and supporting source |
| Shared footer copyright updated | Do not automatically refresh every article date | Site-level maintenance note |
| Draft saved internally | Do not list it as published content | Draft state |
If only day-level precision is known, retain that precision. Do not invent a publication hour to make the record look more exact. Feed formats and structured data may have different date requirements, so handle each output deliberately.
Work through a three-page release
Suppose a fictional release changes three resources. A product guide gains a new supported integration example. A comparison article corrects a material limitation. An unrelated essay is rebuilt with the same content because the site bundle changed.
The first two resources receive a substantive revision record. The essay keeps its prior modification date. The deployment has its own timestamp, but that timestamp does not replace the editorial history of every file included in the deployment.
When the integration example changes, the editor should record the source and the actual supported behavior. A modification date without an explanation can still be technically accurate, but it is less useful for future maintenance.
Generate the sitemap from approved records
Use the canonical destinations intended for discovery and exclude drafts or resources that should not be listed. Check the generated output against the content inventory rather than hand-maintaining an unrelated URL list.
A resource removed from the sitemap still needs its own retirement or redirect decision. Sitemap omission is not a complete instruction to remove a page from search. Keep route behavior, linking, and content state coordinated.
For a larger publication, divide sitemaps when the applicable format limits require it. Do not create a complex sitemap hierarchy merely to make a modest archive look larger. The structure should support operation and diagnosis.
Verify a change by comparing before and after
For the fictional release, compare the old and new sitemap entries. Confirm that the two revised resources changed as intended and the unchanged essay did not. Check that the final URLs match the approved canonical destinations.
Also inspect the visible revision note where a change materially affects the reader. The sitemap serves discovery systems; a human reader may need to understand that instructions or assumptions changed. Those are complementary records.
Use the archive maintenance plan to assign future reviews. A useful sitemap change log lets the team answer which content changed, why it changed, and whether the published discovery signals match the actual work.