Sitemap 里的 lastmod 是很多人随手填、又很少有人回头检查的字段。它不像 robots.txt 那样一错就被发现，也不像 404 那样立刻有报错提示，填错了通常什么都不会发生——只是蜘蛛对“这个页面值不值得再来”的判断慢慢偏离实际。下面说清楚 lastmod 是给谁看的、怎么填相对可靠，以及哪些情况下不必在它上面花太多精力。
lastmod 到底给谁看
lastmod 是给抓取调度用的参考值，不是给用户看的发布时间。蜘蛛在决定要不要重抓某个 URL 时，会综合站点历史抓取表现、页面本身的更新节奏，以及其他更新信号，比如响应头里的 Last-Modified、ETag，以及带条件请求时是否返回 304。lastmod 只是其中一个输入项，但它有个特点：这是站点自己声明的。
也就是说，lastmod 不保证重抓，填了新时间也不保证第二天就来。它的作用是让调度在做取舍时多一个依据，而不是一个开关。一旦它和实际内容长期对不上，参考价值就会打折。
常见的几种填法及其问题
全站统一时间
每次生成 Sitemap 都把全站 lastmod 刷成当前时间，是最常见也最容易被忽略的做法。表面上“看起来在更新”，实际上等于告诉调度所有页面都在同一秒变了。这类信号无法区分重点，长期下来容易被当成噪声。
只在发布时写一次
页面初次发布时写上一个时间，之后改了正文也不动它，会让真正有实质更新的页面被低估。尤其是价格、库存、政策条款这类改动幅度不大、但影响用户判断的内容。
用模板渲染时间
有些站点直接输出模板里的“最后修改时间”变量，结果列表页、聚合页每次访问时间都在变。这类页面本身没有需要索引的独立内容，lastmod 抖动只会放大重复抓取。
相对可靠的填法：跟着内容走
比较稳妥的原则是：lastmod 只在页面正文出现用户可感知的变化时才更新。可以按这几类来判断：
- 正文、标题、主要段落有增删改，属于应更新。
- 结构化数据里的关键字段变化，比如价格、评分、库存状态、营业时间，属于应更新。
- 主体配图、视频更换，通常不值得单独更新 lastmod，除非页面信息依赖它。
- 底部广告位轮换、推荐位调整、访问计数器，不属于内容更新。
- 模板改版导致全站 HTML 变化，但正文未动，不必逐个刷新 lastmod。
如果站点内容量大，可以把判断收敛成一条规则：写入内容库时记录一次“内容版本时间”，Sitemap 直接读这个字段。这样 lastmod 天然跟着内容走，不需要人工维护。
HTTP 层也有更新信号，两边要一致
除了 Sitemap，蜘蛛还会看响应头。服务端给出的 Last-Modified 和 ETag 如果和 Sitemap 里的 lastmod 明显矛盾，调度端往往更依赖实际响应，毕竟那是它亲自验证过的。
常见的不一致：Sitemap 写着上周更新，响应头里的 Last-Modified 却是三个月前，并且带 If-Modified-Since 回来时仍然返回 200 和完整正文。这种情况下，重复下载的成本会落在站点自己身上。
所以条件允许的话，让内容库的版本时间同时驱动 Sitemap 的 lastmod 和响应头的 Last-Modified，并确保支持 304。蜘蛛带条件请求回来时返回 304，比返回 200 更省服务器，也更快。
一个可以落地的维护流程
- 确认 Sitemap 里的 lastmod 来源字段，是内容版本时间还是生成时间。
- 抽取 20 到 50 个近期确实有内容变更的 URL，逐一比对其 lastmod 与实际改动时间。
- 在服务器日志里观察这些 URL 是否被重新抓取，以及抓取时是否返回 304。
- 如果大量 lastmod 与实际不符，先修生成逻辑，再观察一段时间的抓取变化。
- 把“内容版本时间”写进发布流程，避免长期依赖人工填写。
什么时候不必纠结这个字段
更新极少的企业介绍页、联系方式、历史归档类页面，lastmod 精确与否影响很小。这类页面本来就不需要频繁重抓，准确填上一次发布的时间即可。同理，分页、标签聚合、筛选结果这类页面，重点往往不是 lastmod，而是它们该不该出现在 Sitemap 里——如果本身不被期望被索引，纠结更新时间意义不大。
把精力放在真正会变化、且变化后需要被重新认识的内容上，比全站统一刷新时间更有意义。lastmod 不是排名手段，它只是让调度的判断更接近事实的一个细节。