What should lastmod say to be trustworthy?
lastmod should be the time the page content really changed. Google's sitemap documentation (checked 2026-11) is specific: Google uses lastmod only if it is “consistently and verifiably” accurate; it should reflect the last significant update to the page, meaning changes to the main content, structured data or links, and changing the copyright year in the footer does not count.
Bing said the same in its 2025-07-31 Webmaster Blog post: lastmod is a key signal for deciding whether to recrawl, it should reflect the true last modification time of the page content and not the time the sitemap was generated, and the recommended format is ISO 8601 with a time. The post also says freshness signals affect how quickly updates show up in search results and AI-generated answers.
Also, Google's documentation says it ignores priority and changefreq, so do not spend time on those two. OpenAI's and Perplexity's crawler documentation pages do not mention sitemaps or lastmod, so we do not say whether it matters to those two.
Which ways of writing lastmod are not trustworthy?
| How it is written | Question | |
|---|---|---|
| Using the file's modified time | Deploys often build from a clean copy of the code, where every file's time is the moment of the deploy, so all pages “update” together. | |
| Using the time the sitemap was generated | Bing's blog says explicitly that it should not be the generation time; if it changes on every generation, it is as good as absent. | |
| Fingerprinting the whole page's HTML | Adding one analytics attribute to a button, or restyling, makes a large batch of pages count as changed. | |
| Using one date for the whole site | Pages that did not change carry the new date too, so a crawler cannot use it to pick out the pages that really changed. |
A real setup: MochiStamp fingerprints what a page “says”
MochiStamp's sitemap (mochistamp.com/sitemap.xml, read 2026-11-05) has 229 URLs, each with a lastmod accurate to the second and with a time zone, with dates spread from 2026-10-16 to 2026-11-05, not one shared date. It works like this:
The fingerprint looks only at what the page says
For each page it takes: the title, the description, the text inside the main content (main), the addresses that links and images in main point to, and the images' alt text. Styles, classes, analytics data attributes and scripts do not count.
The header, footer and language bar do not count
They are the same on every page. Adding a link to a new page in the footer should not make every other page look updated.
A new time is recorded only when the fingerprint changes
The database stores each URL's fingerprint and the time that fingerprint was first seen. If the fingerprint is unchanged, lastmod does not move; if it changed, the time of the change is recorded.
The historical date is not “now”
When recording began, the database was empty. They replayed every earlier release, and recorded each page as the time of the release where its content last changed, not the day recording first began.
This approach was corrected once, as recorded in the project log (2026-10-30): the first fingerprint included the whole page's HTML, so one release that only added an analytics attribute to a button made 119 pages count as changed. After switching to content only, the same change no longer alters any page's time.
In comparison, Pagent (pagent.kagentx.com/sitemap.xml, read 2026-11-05): all 81 URLs have lastmod 2026-10-27, date only with no time, one value for the whole site, taken from the date the data was updated. That is not wrong for a small site that updates as a whole, but a crawler cannot use it to tell which pages are really new.
How do you make a trustworthy lastmod for your own site?
1. Decide what counts as a page change
Body text, title, description, structured data and links count; styles, scripts, the footer copyright year and analytics attributes do not. Write this line down, so that people changing the code do not break it casually.
2. Fingerprint the content that counts, not the whole page
At build time, extract the part that counts and hash it. Leave out parts that are the same on every page, such as the header and footer.
3. Update the time only when the fingerprint changes, and store it
Store each URL's fingerprint and time in a file or database. On redeploy, compare first: if unchanged, keep the old time. Do not use file times.
4. Output ISO 8601 with a time and time zone
Like this. Google's documentation example shows only a date, and Bing recommends including a time; the full form is safer:
<url> <loc>https://example.com/pricing/</loc> <lastmod>2026-11-05T00:27:22+09:00</lastmod> </url>
5. Spot-check after going live
Open the live sitemap.xml, pick a few pages you did not change this time and see whether their dates moved; then pick one you just changed and see whether its date is new.
6. Notify search engines when needed
lastmod is about the judgment a search engine makes when it comes to crawl again; to let Bing and other engines know faster, see what IndexNow is.
However accurate lastmod is, it only matters if crawlers can get in and read the text; for those two, see AI visibility audit checklist.
FAQ
Will lastmod make AI cite my pages faster?
There is no guarantee. Bing says lastmod is a key signal for deciding to recrawl and that freshness affects how fast updates show up in search results and AI answers; OpenAI's and Perplexity's crawler documentation does not mention sitemaps or lastmod.
Can lastmod use the file's modified time?
Not recommended. When a deploy builds from a clean copy, every file's time is the moment of the deploy, and every page looks freshly updated. Record the time the page content really changed.
Do I update lastmod when I change the footer's copyright year?
No. Google's documentation says a significant update means changes to the main content, structured data or links, and changing the copyright year does not count.
Do I still need priority and changefreq?
No. Google's documentation says it ignores both values.
Should lastmod be a date or a time?
Google's example has only a date; Bing's blog recommends ISO 8601 with a time. A full time with a time zone suits both, as long as it really is the time the page last changed.
Sources
- Google Search Central · Build and submit a sitemap （checked 2026-11-05）
- Bing · Keeping Content Discoverable with Sitemaps in AI Powered Search （Published 2025-07-31, checked 2026-11-05）
- OpenAI · Overview of OpenAI Crawlers （checked 2026-11-05）
- Perplexity · Perplexity Crawlers （checked 2026-11-05）
- MochiStamp · sitemap.xml （Read 2026-11-05, 229 URLs）
- Pagent · sitemap.xml （Read 2026-11-05, 81 URLs）
- kagentx evaluations: the data on the case study pages; each example gives its date.