Sitemap 通常被当成一份 URL 清单来处理，但它其实还携带了另一类信息：时间戳。lastmod 和 changefreq 就是其中最常见的两个字段。很多站长把它们当作向蜘蛛发出的“抓取指令”，写完就等着回访加快。实际情况要复杂一些。

lastmod 是什么，蜘蛛怎么读它

lastmod 表示这个 URL 最后被修改的时间。蜘蛛拿到 Sitemap 后，不会立刻按时间戳逐条抓取，但它会把这些信息放进自己的调度参考里。一个长期没有变化的页面，和一个刚刚标记为更新的页面，在回访优先级上通常会有差别。

关键在于，这个差别建立在一个前提上：蜘蛛认为你的 lastmod 是可信的。如果整份 Sitemap 里每个 URL 的 lastmod 都是抓取当天的时间，或者每次生成都自动刷新，这个字段就失去了区分度。蜘蛛不会因此提高回访频率，反而可能逐渐降低对它的参考权重。

changefreq 和 priority 的现状

changefreq 用来描述页面大概多久变化一次，priority 用来表示页面在站内的相对重要程度。这两个字段在早期的 Sitemap 协议里被提出，但主流搜索引擎后来都公开表示过：它们对这两个值的依赖很有限，因为站点自己填写的频率和权重很难客观。

这并不意味着写了没有意义，而是不要指望靠把 changefreq 设成 hourly、priority 设成 1.0 来换取更频繁的抓取。蜘蛛对页面的判断，更多来自它自己观察到的更新历史、内链位置和外部信号。

时间戳的可信度从哪里来

一个可用的 lastmod，至少要满足两点：准确和稳定。准确是指它确实对应页面的实质更新，而不是模板改动、广告位轮换或时间戳自动刷新；稳定是指同一个页面在没有内容变化时，这个值不应该变来变去。

如果是程序自动生成 Sitemap，建议把 lastmod 绑定到内容本身的修改时间，比如文章表的更新时间字段，而不是 Sitemap 的生成时间。对于列表页和聚合页，如果每次刷新排序都会变化，可以考虑不写 lastmod，或者只在大范围调整时更新。

把 lastmod 写成生成时间，等于告诉蜘蛛“全站刚刚更新过”。这种信号用一次两次也许有效，长期使用只会让这个字段变得没有参考价值。

和 HTTP 头、内链更新怎么配合

Sitemap 里的 lastmod 不是孤立的信息。蜘蛛在真正抓取页面时，还会看 HTTP 响应头里的 Last-Modified 和 ETag（如果服务器提供了）。如果 Sitemap 说昨天更新，响应头却说三个月没变，蜘蛛自然会更相信服务器返回的实时信息。

所以更稳妥的做法是：让 Sitemap 的 lastmod、HTTP 的 Last-Modified、页面上显示的更新时间尽量保持一致。三者对得上，时间戳才更容易被当作有效参考。

另外，页面更新之后，别忘了从内链上给它一点推动。比如在栏目页、相关推荐或首页列表里把它放到更靠前的位置。蜘蛛很多时候是通过内链发现“这个页面最近动过”的，而不是靠 Sitemap 的时间戳。

可以落地的几个做法

• lastmod 只写内容实质变化的时间，不用生成时间；
• 没有变化的页面，不要为了“看起来新”而手动改时间戳；
• changefreq 可以按实际更新规律填写，但不必逐页纠结；
• priority 对抓取的影响很小，重点放在内链结构和页面本身；
• 定期检查 Sitemap 中是否有大量重复时间戳或明显错误的时间；
• 结合服务器日志观察蜘蛛对标记更新页面的实际回访情况，再决定是否调整。

Sitemap 的时间戳不是加速收录的开关。它更像一份备注，帮助蜘蛛判断哪些页面值得优先看一眼。写准、写稳，配合内链和服务器响应头的一致性，比反复调整 changefreq 和 priority 更实际。