The sitemap <lastmod> field tells search engines when each page last changed, so they can recrawl what moved and leave the rest alone. That only works while the dates are true. When every URL carries the same date, or the time the sitemap file was generated, the field says nothing about any page, and search engines learn to stop reading it.
What this finding means
Crawl Cove's sitemap-lastmod-unreliable check reads the <lastmod> dates in your XML sitemap during the crawl and fires in one of two cases:
- Every dated URL carries the same date. One timestamp across the whole file is almost always the moment it was built.
- Every date falls within 36 hours of when the audit read the sitemap. The dates differ slightly, but all of them are from the last day or so. That is the signature of a sitemap generated on request, or by a nightly job, that stamps each URL with the build time instead of the page's own modified date.
The check needs at least 10 dated URLs before it says anything, because a small site where a handful of pages share a date is unremarkable. A real finding reads like this:
All 412 dated URLs in the sitemap are dated between 2026-11-04 02:00 UTC and 2026-11-04 02:03 UTC, within 36 hours of when this audit read the sitemap (2026-11-04 09:15 UTC). The dates look like when the sitemap was generated, not when each page changed.
or, for the single-date case:
All 412 dated URLs in the sitemap carry the same <lastmod>, 2026-10-01.
It is a site-level finding, reported once against the start URL, not once per page.
Why it matters
Google uses <lastmod> to schedule recrawls of URLs it already knows, but only when the value is "consistently and verifiably accurate", checked against what it finds when it fetches the page. Bing has said the same: it leans on lastmod to decide what to recrawl, and wrong dates waste that. A sitemap that claims every page changed today, every day, is quickly treated as noise. The cost is slow, not dramatic: when you do edit a page, the sitemap can no longer say so, and the change waits for the next routine recrawl.
How common is it? When we swept 1,562 small business websites in October 2026, 760 had a sitemap with 10 or more dated URLs, and 65 of those (8.6%) failed this check: one date on every URL, or every date within 36 hours of the read.
How to fix it
- Find where the date comes from. Open the sitemap and compare a few
<lastmod>values with pages you know have not changed in months. If they all read today, the generator is writing the build time. - Switch the source to each page's modified date. Most SEO plugins and platforms write this field for you, so the fix is usually a setting rather than code: look for an option that uses each post or page's last modified date. In a custom build, read the content's own
updated_at(or equivalent), never the current time and never the deploy time. - Leave lastmod out where you cannot date it honestly. Google says it is fine to date only the URLs you are confident about. Home pages, category pages and other listings that aggregate other content are the usual candidates to leave undated.
- Only move a date for a real change. New main content, changed structured data or changed links count. A footer copyright year, a redeploy or a cache purge do not.
- Check the file again. The free XML sitemap validator flags a sitemap where every
<lastmod>is the same, without a full crawl. Then re-crawl in Crawl Cove to confirm the finding has cleared.
False positives and edge cases
- A genuine sitewide change. After a migration or a template change that really touched every page, identical recent dates are true. The finding is Low and advisory; ignore it, and it clears once ordinary edits spread the dates out.
- Small sitemaps are left alone. Under 10 dated URLs the check stays silent, because one shared date on a five-page site proves nothing.
- Undated URLs do not count against you. Only URLs that carry a
<lastmod>are compared, so a sitemap that dates some pages and omits the date on others is judged on the dated ones.
Related reading
The other sitemap findings check the URLs rather than the dates: non-indexable URLs in the sitemap covers entries that redirect, error or carry noindex, and pages missing from your XML sitemap covers the reverse. For how recrawl scheduling fits the bigger picture, see crawl budget explained.
Google documentation: Build and submit a sitemap
Frequently asked questions
- Should I remove lastmod from my sitemap?
- Only if you cannot make it accurate. Google's own guidance is that it uses lastmod when the value is consistently and verifiably accurate, and that you can date all of your URLs or just the ones you are sure about. A sitemap with no lastmod loses nothing; a sitemap whose dates are all wrong teaches search engines to ignore the field.
- What counts as a change worth a new lastmod?
- A significant update to the page: its main content, its structured data or its links. Google names a copyright year in the footer as the kind of change that does not count. A redeploy, a cache refresh or a new sitemap export changes nothing on the page, so it should not move the date either.
- Do changefreq and priority do the same job?
- No. Google ignores both. lastmod is the only date or hint in the sitemap protocol that Google says it uses, which is why it is worth getting right.
- Is it a problem if a few pages share a date?
- No. Pages published or edited on the same day will share a date, and that is accurate. Crawl Cove only flags the sitemap when every dated URL shares one date, or every date falls within 36 hours of the moment the audit read the file, and only once there are at least 10 dated URLs.
- My whole site really did change yesterday. Is this a false positive?
- Yes. After a sitewide template change or a migration, every page may genuinely have changed at once. The finding is advisory for exactly that reason: if the dates are true, ignore it, and it clears itself once later edits give pages different dates.