Does Google use lastmod in a sitemap? Sometimes. That is not a hedge, it is the documented answer, and the condition attached to it is the whole subject of this note.
Google’s build and submit a sitemap documentation settles two of the three optional tags in one sentence:
Google ignores
<priority>and<changefreq>values.
No qualifier, no conditions. Every hour anyone has spent tuning priority values in an SEO plugin was spent on a field Google does not read. The third tag is different:
Google uses the
<lastmod>value if it’s consistently and verifiably (for example by comparing to the last modification of the page) accurate.
So lastmod is the only optional tag with any weight, and it carries that weight on credit. Google checks your claim against the page it fetched. Get caught lying often enough and the field stops counting for your whole site.
What “verifiably accurate” is checking
The parenthetical is the important part: Google compares the date you declared against the last modification it can observe on the page itself. That makes lastmod a claim being audited, not an instruction being obeyed.
The same documentation defines what a real modification is:
The
<lastmod>value should reflect the date and time of the last significant update to the page. For example, an update to the main content, the structured data, or links on the page is generally considered significant, however an update to the copyright date is not.
Three things count: main content, structured data, links. A footer year, a rotating testimonial, a fresh build hash, a recompiled stylesheet: none of those are a page update, and stamping a new date because one of them changed is exactly the behaviour that costs you the field.
The failure I actually meet
Almost nobody sets lastmod by hand. A plugin or a static site generator sets it, and the default behaviour of a lot of them is to write the build timestamp into every URL on every deploy.
Publish one new post, redeploy, and all 4,000 URLs now claim they were modified thirty seconds ago. Do that twice a week and you have taught Google that your lastmod values carry no information at all. The word in the documentation is “consistently”, which is a judgment about the file over time, not about the row Google is looking at today. Nothing tells you when that judgment has been made against you. There is no report for it, no status in Search Console, no warning. The field just quietly stops being worth anything.
This is the same shape of problem as a sitemap listing redirected and 404 URLs, which I covered in how many URLs a sitemap can have. A sitemap is a set of claims. Claims that keep turning out to be wrong devalue the whole file, and the limits people worry about are almost never the actual issue.
What my own sitemap does
I pulled my own file while writing this, because it would be a poor look to recommend something I am not doing. shahidali.co/sitemap-0.xml returns 200 and contains 128 URL entries with zero lastmod, zero priority and zero changefreq. Nothing but <loc>.
Two honest halves to that. The half I stand behind: no lastmod is strictly better than a lastmod that lies, and shipping the two ignored tags would have been pure decoration. On a 128-URL site that Google recrawls comfortably, the field was never going to be the bottleneck.
The half I do not stand behind: I have real modification dates. Every post in this site carries a date, and updated posts carry an updated field, which is exactly the “significant update” the documentation describes. That is a true signal I am declining to send because the default sitemap output did not include it and I never went back. It is on the list, and when it ships it will ship from the content dates, not from the build clock.
That distinction is the practical rule. Emitting lastmod from your build timestamp is worse than emitting nothing. Emitting it from a real content modification date is worth doing.
When it matters and when it does not
On a small site, barely at all. Google will recrawl 128 pages on its own schedule and an accurate lastmod moves that by very little.
It matters at scale, and it matters in the shape people usually get wrong: not “index my new page faster”, but “stop wasting crawl on the 90 per cent of pages that have not changed”. On a large catalogue or a large archive, a trustworthy lastmod is how you tell Google which slice is worth the fetch. That is the same budget conversation behind discovered, currently not indexed, where the pages are known and simply are not worth crawling yet.
What lastmod is not is a submission mechanism. Changing the date on an unchanged page does not request anything, and it is the same category error as hammering the request indexing button on a page Google has already judged. If the page did not change, the accurate value is the old date.
Checking yours
Fetch your sitemap and count. Not in a browser, which will render the XML into something pleasant to read and tell you nothing.
- Request the file and check that it returns 200. A sitemap that 404s or 500s in an index is a common and entirely silent failure.
- Count the
<lastmod>values and compare them. If every single one is identical, or every one is today, your generator is writing the build time. That is the bug. - Pick three URLs you know you have not touched in a year and check what their lastmod claims. Those are the rows that reveal the truth about the file.
- Take the two ignored tags out if you are emitting them. They do nothing for Google and they add bytes against a 50MB cap.
The sitemap health check here runs the mechanical half of that, and if you want the per-sitemap indexing numbers next to it, the sitemap index coverage tool reads those from Search Console. Neither of them can tell you whether a date is true. That part needs someone who knows when the page actually changed.
Update, 3 September 2026: the cache-busting sitemap trick
A question put to John Mueller on Bluesky on 1 September describes a workaround for the whole lastmod problem. On “a large rigidly structured site”, the child sitemap URLs listed inside the sitemap index “get a fresh ?v=timestamp every day”, so that each day Google sees what looks like a brand new sitemap file and fetches it, whether or not anything inside changed. The person asking noted the point precisely: “Since its the URL changing rather than lastmod, im wondering if this causes any harm?”
Mueller’s reply, in full: “I think that’s a bad idea because you’re signaling that the canonical URL for a piece of content should be constantly changing. That’s not good for search engines, it’s not good for your tracking. Having clean, stable URLs is important. (Cue the TBL page ‘Cool URIs don’t change’)”.
Two things to take from that. First, the trick is not a lastmod trick at all. It is the same category error as stamping today’s date on every page, moved one level up: it manufactures change where there is none, and it does so on the one file whose job is to tell Google what changed. Second, the objection is about URL stability, which is a bigger principle than sitemaps. A resource that lives at a new address every day cannot build a history, and the sitemap file is a resource like any other. If you want Google to refetch a child sitemap, give it an accurate lastmod in the index and change the file when the content changes. That is the mechanism, and it costs nothing.
- John Mueller, reply on Bluesky, 1 September 2026, checked 3 September 2026
- The original question, @seoharbour on Bluesky, 1 September 2026, with the follow-up describing the daily
?v=rotation, checked 3 September 2026 - Tim Berners-Lee, Cool URIs don’t change, the page Mueller cites
Sources
- Google Search Central, build and submit a sitemap, lastmod, priority and changefreq handling, checked 27 August 2026
- Sitemaps.org, sitemaps XML protocol, tag definitions, all three optional tags
- First-hand: shahidali.co/sitemap-0.xml, fetched 27 August 2026, 128 url entries, 0 lastmod, 0 priority, 0 changefreq