Sitemap 里除了 URL 本身，還有一组可選字段，其中 lastmod 是最容易被随手填寫、也最容易被忽略的一個。它的作用是告诉搜尋引擎這個頁面最後一次發生實质性變更的時間。蜘蛛並不會因為一個新鲜的 lastmod 就立刻来抓，但一個稳定、可信的 lastmod 會帮助它判断哪些 URL 值得優先安排、哪些可以往後放。
简單说，lastmod 是建议，不是命令。它影响的是調度时的參考權重，而不是抓取與否的開關。
格式：不是随便寫個日期就行
主流搜尋引擎認可的寫法是 W3C Datetime 格式，可以完整到秒，也可以只到日期。带时区的時間戳比不带时区更明确。
- 2024-05-21 這種只到日期的寫法可用，但含义是该日 00:00
- 2024-05-21T09:30:00+08:00 這種带时区的寫法最清晰
- 20240521 這類紧凑格式在部分實現里能被解析，但兼容性不如标准寫法
- 只寫時間不寫日期，或使用“今天”“昨天”等相對描述，會直接失效
三類常见的填寫問题
每次生成 Sitemap 都把全站刷成当下時間
這是最常见的一種。程序每次輸出 Sitemap 时统一用目前時間填充 lastmod，结果是全站几萬個 URL 的最後修改時間每天都一样新。蜘蛛多次對比後發現這個字段没有区分度，就會降低對它的信任，之後即使某個頁面真的更新了，也很难通過 lastmod 传達出去。
用当天日期批量覆盖
與上一條思路類似，只是時間粒度不同。常见的触發场景是运营在後台点了“全站重建”，脚本顺手把所有條目的時間改成了今天。對蜘蛛来说，這等于告诉它整個站点每天全部重寫了一遍。
时区與格式混用
一部分條目带时区、一部分不带，或者不同栏目由不同系統生成導致格式不统一。解析时可能出現偏移，让頁面看起来的修改時間比實际更早或更晚，反而干扰判断。
lastmod 與服務端响應头的關系
Sitemap 里的 lastmod 和服務器返回的 Last-Modified 是两套信息，来源不同，用途也不同。
- lastmod 由站点在 Sitemap 中主動声明
- Last-Modified 由服務器在响應中被動给出
- ETag 更多用于缓存校驗，配合 If-None-Match 判断内容是否變化
三者如果互相矛盾，比如 Sitemap 说今天更新、Last-Modified 却是半年前，蜘蛛會更倾向相信服務端實际返回的内容與校驗信息。所以更稳妥的做法是让 Sitemap 的 lastmod 由内容系統的真實更新時間生成，而不是人工或模板拼出来。
一套可落地的自查方式
- 抽 10 個近期确實更新過的 URL，看它們的 lastmod 是否集中在更新当天，而不是全站同一個值。
- 检查格式是否统一、是否带时区，是否都是标准日期寫法。
- 對比同一個 URL 的 lastmod 與响應头 Last-Modified，看两者是否大致吻合。
- 检查栏目頁、标簽頁這類聚合頁面，確認它們的 lastmod 會随内容變化而更新，而不是長期不動。
- 發布新内容後隔几天再拉一次 Sitemap，看新 URL 是否带着合理的時間出現。
一個現實提醒
lastmod 不會让頁面凭空被收錄，也不會让蜘蛛跳過正常的抓取路径。它只是一條帮助調度判断的辅助信息，寫對了有用，寫错了也不會立刻出問题，但長期失真會让這條信息失去價值。
把 lastmod 做對，成本不高，主要靠内容系統里那個真實的“更新時間”字段。真正麻烦的是站点结构复杂、多套系統拼装的场景，這时宁可少寫、寫准，也不要為了填满字段而全站刷同一個時間。