Sitemap 是站点主動交出去的 URL 清單，但清單里的每個地址都带着一個時間戳。很多站点把 lastmod 当成“填上就行”的字段，结果蜘蛛看到的時間和頁面真實的改動時間對不上。一两次没有影响，長期不一致之後，這個字段就很难再被当作參考。
蜘蛛為什么在意這個時間戳
蜘蛛的抓取资源有限，它需要在“已知但可能過期的頁面”和“從未见過的頁面”之間决定先去哪里。頁面的改動時間，是判断“值不值得再来一次”的輸入之一。Sitemap 里的 lastmod 由站点自己声明，属于比較明确的信号——前提是它可信。
需要说清楚的是，lastmod 只是众多輸入中的一個。它不會單獨决定抓取顺序，也不會因為寫對了就保證頁面被重新抓取。它的價值在于：当其他條件差不多时，一個准确的時間戳能让判断更有依據。
格式先寫對
- 使用 W3C Datetime 格式，例如 2025-03-08T09:12:30+08:00。
- 带上时区偏移。只寫到 YYYY-MM-DD 也是合法格式，但精度只到天。
- 同一個 Sitemap 文件内保持一致，不要一部分带时区、一部分不带。
- 不要寫相對時間，也不要用“三天前”這類描述。
三種常见的错誤寫法
全站统一成今天
有些程序會在每次生成 Sitemap 时，把所有 URL 的 lastmod 都刷成目前時間。蜘蛛第一次看到，會以為整站都更新了；第二次、第三次還是同样的结果，這個字段就失去意义了。一個持續變化的 lastmod，和一個没有 lastmod，差別並不大。
用构建時間代替内容時間
静態站点常见的問题：每次部署都重新生成所有頁面文件，文件時間變了，lastmod 也跟着變，但頁面内容可能一年没動過。正确做法是记錄内容的最近一次實质性修改，而不是记錄文件系統的時間。
時間戳無法解析
寫成“2025/03/08”、中文日期，或者干脆留空，解析失敗的條目往往會被整條忽略，连同這條 URL 的其他信息一起打折。生成之後最好抽查几條，確認格式能被标准解析器讀懂。
让時間戳和真實改動對齐
判断什么叫“實质性修改”，可以给几條简單的线：正文内容、标题、主要结构化資料的調整，可以更新時間；评论排序變化、广告位轮換、推荐位調整，一般不算；样式微調、模板改動引起的全站“更新”，更不應该体現在 lastmod 上。
如果内容存在資料库里，取最後修改時間字段即可。如果内容来自發布流程，可以让編輯在儲存时决定是否打上新的時間戳。關键点是：只有人或者明确的規則認為内容變了，時間才變。
和其他信号配合起来
- lastmod 准确，配合頁面的 304 與 ETag 响應，蜘蛛可以用很小的成本確認有没有變化。
- Sitemap 分片时，索引文件里的 lastmod 應取该分片内頁面的最大值，而不是生成時間。
- 内鏈和 Sitemap 指向同一個 URL 时，時間戳也應對應同一個頁面版本，不要互相矛盾。
- 頁面已经刪除的，不适合靠改 lastmod 去“唤醒”，應当從 Sitemap 移除並返回正确的狀態碼。
一份可执行的自查清單
- 随机抽 20 條 URL，把 Sitemap 里的 lastmod 和頁面實际修改時間逐條對比。
- 检查是否存在全站 lastmod 等于生成時間的批量模式。
- 確認時間格式统一，並且带有时区。
- 检查有没有未来時間。
- 检查分片 Sitemap 索引中的 lastmod 是否取的是分片内的最大值。
- 後台里如果有多處记錄修改時間，確認 Sitemap 取的是同一個字段。
把 lastmod 寫准，不會让蜘蛛立刻来抓；把它寫乱，長期下来只會让這個字段變得可有可無。
站点對 URL 清單的维護方式，反映的是它對自身内容更新的掌控程度。時間戳只是其中一個细节，却很容易被自動化流程寫坏，也很容易被忽略。定期抽查一次，比每次全量刷新更省事。