Sitemap 里的 lastmod 常被当作「告诉搜尋引擎這個頁面更新了」的開關，但很多站点並没有認真维護它。一旦時間戳與實际内容更新的關系被破坏，抓取調度拿到的就是噪声，而不是信号。结果是频繁被抓取的頁面其實没變，真正更新的長尾頁面却迟迟等不到訪問。下面從 lastmod 的生成、校驗和协同三個环节，讲一套可以落地的维護方式。
為什么 lastmod 會影响抓取優先級
搜尋引擎在决定「下一次抓哪個 URL」时，會把多個信号叠加起来：内鏈權重、歷史抓取质量、頁面變更频率、Sitemap 声明的時間戳等。其中 lastmod 是站点唯一能直接、批量表達「這個 URL 變了」的手段。它不保證一定被采信，但如果大量頁面的 lastmod 同时刷新、抓取後内容並無變化，這個字段的可信度會被整体打折，之後即便某篇文章真的更新，也很难被優先安排回訪。
lastmod 失真的常见来源
- 模板級時間戳：頁脚或侧栏輸出了目前時間，導致每次渲染出来的 lastmod 都等于「現在」。
- 批量重建：整站重新生成静態頁或重建缓存，所有 URL 的修改時間被统一改寫。
- 依赖文件系統時間：部署、複製、迁移都會改變 mtime，與正文實际改動無關。
- 时区與格式混用：同一份 Sitemap 中同时出現带时区和不带时区的時間，解析结果不一致。
- 预览與草稿外泄：未發布内容先進入 Sitemap，正式發布时時間戳反而不變。
修正顺序
- 确定唯一来源：lastmod 只取正文内容的最後編輯時間，與發布時間、模板渲染時間区分開，寫入資料库字段而不是執行时計算。
- 统一格式：全部使用带时区的 ISO 8601 格式，例如 2024-06-01T09:30:00+08:00，避免只寫日期带来的歧义。
- 只在内容實质變化时更新：修正错別字、补充段落可以更新；調整導航、广告位不應触發全站時間戳變化。
- 分批提交：一次性把全站 lastmod 刷成同一时刻，等于放弃這個信号。按實际改動分组，让時間戳自然分散。
- 回查抓取日誌：观察高频抓取的 URL 與 lastmod 靠前的 URL 是否重合，若明顯错位，說明仍有模板時間在干扰。
與其他抓取信号的配合
lastmod 不是孤立的，它需要和 Sitemap 的 URL 集合、頁面内鏈入口、服務器响應质量保持一致：
- Sitemap 中的 URL 應当是可稳定返回 200 的地址，不要混入重定向鏈或多變体路径。
- 更新後的頁面最好能從栏目頁、相關推荐等位置获得一條内鏈，纯靠 Sitemap 表達的更新信号更容易被忽略。
- 服務器在抓取高峰出現超时或 5xx，會让調度降低對该站点的抓取配額，此时再精准的 lastmod 也难換来額外訪問。
把 lastmod 当作「内容變更的日誌」，而不是「想被多抓一次的借口」，這個字段才有長期價值。
驗證方式
建立一個简單的對照表：记錄 URL、lastmod、實际内容修改日期、最近一次抓取時間。每隔一段時間抽查一批，重点關注三類頁面——高频更新但抓取稀疏的、lastmod 長期不動但内容已改的、時間戳密集却没有任何實质變化的。這三類問题分別指向内鏈不足、字段未维護和批量刷新，處理方式並不相同。
维護 lastmod 的成本不高，难的是让它長期保持诚實。当字段與實际内容變更贴近时，抓取調度才有依據判断哪些 URL 值得優先回訪，站点也更容易把有限的抓取配額用在真正更新的頁面上。