The one attribute that is actually used
Of the optional attributes in a sitemap, lastmod is the only one worth any effort. Google states plainly that it ignores priority and changefreq.
lastmod is different, and conditionally used: Google says it uses the value if it is consistently and verifiably accurate, for example by comparing it against the last modification of the page.
Note the word verifiably. A crawler can fetch your page and judge whether the content really changed when you claim it did. This is a checkable assertion, not a hint you can set freely.
The trap almost everyone falls into
A generator that writes the current timestamp to every URL on every build. It is the default in a lot of tooling because it is the easiest thing to implement.
The result is a file claiming every page on the site changed at the same instant, every time you deploy. That is demonstrably false, and a crawler comparing the claim against the pages can see it.
Having established that your lastmod values are unreliable, the field stops being useful. At that point it would have been better absent, because an absent value is neutral while a false one is a signal you cannot be trusted on.
We had this exact problem on venbit.ai. Our own sitemap validator flagged that every lastmod carried the build time, and we removed the field rather than keep faking it.
What counts as a real change
Google's guidance is that lastmod should reflect meaningful updates to the main content, structured data, or links, rather than trivial ones.
So a rewritten section counts. A new paragraph counts. Changing a price counts. Updating the copyright year in your footer does not, and neither does a template change that touched every page without altering what any of them say.
That distinction is why automatic build-time stamping fails: a deploy touches every page's HTML without changing what most of them mean.
- Counts: the main content was edited
- Counts: structured data or links on the page changed
- Does not count: footer, copyright year, template tweak
- Does not count: a rebuild that changed nothing semantic
The practical recommendation
If your CMS tracks a real modified date per page, use it. WordPress does, and most SEO plugins wire it through correctly.
If your site is generated and you have no reliable per-page date, omit lastmod. That is a perfectly valid sitemap and a more honest one.
Do not split the difference by stamping a date you cannot defend. The middle option is the only genuinely bad one.
Common questions
Does Google use lastmod?+
Yes, conditionally. Google says it uses the value if it is consistently and verifiably accurate, for instance by comparing it against when the page actually last changed.
My generator sets lastmod to today on every build. Is that bad?+
Yes. It claims every page changed at once, which a crawler can verify is false. Once the values are shown to be unreliable the field stops being useful, so omitting it would be better.
What counts as a modification?+
Meaningful changes to the main content, structured data or links. A footer edit, a copyright year update, or a template change that did not alter what pages say does not count.
Is it valid to omit lastmod entirely?+
Yes, completely valid and often the better choice. If you have no reliable per-page modification date, leaving it out is more honest than inventing one.
Sources