Sitemap lastmod, measured: 13 of 24 sites say nothing with it

FIELD TEST · 2026-08-17 · 30 sites · single snapshot

Sample and method: the same 30 sites we read for robots.txt and llms.txt on 2026-08-15. One sitemap per site, fetched anonymously over HTTPS on 2026-08-17. Every count below comes from that one file, not from the whole site.

Google uses sitemap lastmod only when the value is, in its own words, consistently and verifiably accurate. We asked 30 sites for a sitemap and got a parseable one from 24. Ten of those carry no lastmod on a single URL. Three stamp every URL in the file with the same calendar day. That leaves 13 of 24 handing search engines a field with nothing in it to act on.

What the 24 readable sitemaps look like

Sorted by what an engine can actually do with the file. The middle row is the interesting one: those files are full of dates, and the dates are all the same.

Six more sites are missing from that 24. Five refused the sitemap outright and one served something that was not a sitemap at all. Those are in their own section below, because a closed door is a different problem from an empty field.

How we measured it

The rule set was written down before the first request went out, and it did not change afterwards. That matters here: it would be easy to look at the results first and then pick a threshold that makes a nicer headline.

1. Fetch /robots.txt and take the first Sitemap: line. If there is none, try /sitemap.xml.
2. If the file is a sitemap index, follow its first child and read that.
3. Count URL entries, count entries carrying a lastmod, and count how many distinct calendar days those values cover.
4. Classify: zero lastmod entries is "none"; one distinct day across ten or more URLs is "one stamp"; two or more distinct days is "spread".

One request per file, a normal desktop browser user agent, no cookies, no login. Three requests per site at most.

Ten sitemaps carry no lastmod at all

These files list URLs and stop there. Some of them are very large, which is what makes the omission expensive: the bigger the file, the more an engine has to guess about which URL is worth re-fetching.

Stripe is worth a second look. Its entries are dense with hreflang alternates for a dozen locales, so the file was clearly generated with care. The one field that tells an engine when to come back was left out anyway.

Three sites stamp the whole file with one day

This is the pattern that looks healthy in a validator and says nothing to a search engine. Every URL has a date. Every date is identical, because the value is the build time, not the time the page changed.

Cloudflare's file goes further and ships <changefreq>daily</changefreq> and <priority>1.0</priority> on the homepage entry. Google's documentation states plainly that it ignores both of those tags. So on that one URL, three of the four hint fields are either ignored by policy or identical across the file.

Where a real spread shows up, and where our method broke

Eleven sites gave dates that vary. The documentation sites are the strongest cases: MDN's sampled file carries 14,576 lastmod values across 751 distinct days, which is what a per-page timestamp looks like when it is wired to the page and not to the deploy.

Three of the eleven are artefacts of our own rule about following the first child of a sitemap index, and we are counting them as found rather than quietly dropping them.

• arstechnica.com — the first child file held exactly one URL, so "spread" there means nothing.
• medium.com — the index lists 27,755 children and the first one is a 2019 archive, so every date we read is from 2019.
• bbc.com — same shape, 50,000 URLs dated 2008 to 2009.

That is a real finding about sitemap indexes, not only about our script. Anything that walks an index in file order lands in the archive first.

Five sitemaps were closed to us

An anonymous request could not read these at all. This is not the same as a missing lastmod, and we are not treating it as a failure on the site's part — engines authenticate differently than a plain curl does.

Stack Overflow returned 418 on robots.txt itself, which is a bot challenge rather than a policy statement. Canva is the sixth site outside the 24: /sitemap.xml answered 200 with a document that is not a sitemap.

What sitemap lastmod is worth to you

Treat it as a claim you have to earn, not a field you have to fill. Google's build-a-sitemap page says the value should reflect the last significant update to the page, and that a change to the copyright date is not significant. A build timestamp is the same class of non-event.

• Wire lastmod to the page's own content history, so an edit moves it and a redeploy does not.
• Check your own file the way we checked these: count how many distinct days it covers.
• Do not stamp the whole file with today's date because the generator offers it.
• Do not spend time on changefreq or priority. Google says in writing that it ignores both.

If your generator gives you only the build time, leaving lastmod out is the more honest option, and it costs you nothing that you had. Then tell engines about changes directly. Our IndexNow setup walk-through covers that path, and request indexing in Search Console covers the Google side. If you want the whole crawl-and-citation picture rather than one field, that is what QueryWin is being built to check.

What this snapshot cannot tell you

We do not know whether any single same-day stamp is wrong. A site that rebuilds every page daily has, in some technical sense, changed every file. From outside, with one request and no page history, we cannot separate a real edit from a deploy artefact — and that is exactly the judgement Google says it makes before trusting the field.

Two more limits. This is one file per site, so a site could carry good dates in a sitemap we never opened. And it is a single snapshot on one day, so nothing here says how these values move over time. We did not measure recrawl behaviour at all.

Common questions

Does Google use sitemap lastmod?

Yes, conditionally. The Search Central documentation says Google uses the value if it is consistently and verifiably accurate, for example by comparing it to the last modification of the page. Accurate is doing the work in that sentence.

Is it better to omit lastmod than to get it wrong?

Based on Google's own wording, a value that does not survive verification stops being used. We did not test what happens after that, so we cannot say whether the file is penalised or simply ignored on that field.

How do I check my own sitemap in one pass?

Fetch the file, pull every lastmod, cut each to its first ten characters, and count the distinct values. One distinct value across hundreds of URLs is the answer.

Where did these 30 sites come from?

They are the same 30 we surveyed on 2026-08-15 for who blocks AI crawlers, kept identical so the two measurements can be read side by side.

Sources checked 2026-08-17: Google Search Central, Build and submit a sitemap.