在 Sitemap 的字段里，lastmod 大概是最容易被随手填寫的一個。很多站点要么全部用构建時間，要么干脆不寫。它本身不會让頁面被收錄，但會影响蜘蛛判断“這個 URL 是否值得再来一次”的優先級，所以值得認真對待。
lastmod 在抓取調度里的位置
蜘蛛安排下一次抓取时，通常會參考几個信号：頁面上次被抓取的時間、内容是否發生變化、站点整体的更新节奏，以及 Sitemap 中声明的 lastmod。前几項来自蜘蛛自己的观察，最後一項来自站点自己的声明。
当声明與观察長期一致时，這個信号會被更信任；当声明经常和實际情况對不上，它就會逐渐被忽略。這也是“全部填今天”這種做法往往不如不填的原因。
三類常见的 lastmod 错誤
- 全站统一時間：每次生成 Sitemap 都把当天日期寫给所有 URL。蜘蛛抓回来發現内容與上次一样，声明就失去了參考價值。
- 時間倒流或超前：修改内容後忘了更新，或者用了未来的時間戳。前者让新内容被当成舊内容，後者通常直接被忽略。
- 粒度太粗：只精确到天，或者每次构建都刷新一遍。對更新不频繁的栏目頁影响不大，但對新闻、商品、库存類頁面，粗粒度會把“刚改過”的信号淹没掉。
怎么生成一份相對可信的 lastmod
- 让 lastmod 跟随内容本身的變化，而不是构建動作。可以在内容表里保留 updated_at 字段，編輯儲存时更新，构建时讀取。
- 只有正文、價格、库存這類實质字段變化时才更新；導航、頁脚模板調整不應触發全站時間戳變化。
- 统一时区與格式，使用带时区的 ISO 8601 寫法，避免服務器时区和蜘蛛理解不一致。
- 不要人工填寫。人工维護的字段在几百個 URL 之後基本必然失控。
把 lastmod 当成内容變更日誌的投影，而不是 Sitemap 的生成日誌，判断标准會清晰很多。
lastmod 之外，蜘蛛還在看什么
HTTP 层的信号同样在起作用。Last-Modified 和 ETag 让蜘蛛可以用條件請求確認内容是否變化，命中 304 时能省下一次完整的响應传輸；Cache-Control 的 max-age 則影响它多快愿意再来確認一次。這些响應头與 Sitemap 里的 lastmod 如果互相矛盾，通常以响應头為准。
頁面自身展示的更新時間，例如文章頁的發布日期與更新日期，如果和 lastmod 差得太遠，也會让信号變得模糊。
落地时的取舍
對中小站点来说，比較稳妥的做法是：只给确實需要频繁再抓取的栏目開啟精确 lastmod，其余頁面保留一個大致准确的時間即可。與其追求所有 URL 都精确，不如保證被频繁訪問的那一批不出错。
如果暂时没有能力维護，宁可不寫這個字段，也比系統性寫错要好。抓取調度本来就有多個信号，一個持續失真的字段只會稀释站点其他信号的可信度。