Sitemap 里的 lastmod 字段，很多站点是顺手生成的——要么全站用同一个时间，要么每次发布都刷新一遍。它看起来只是个时间戳，但对搜索引擎来说，这是一个“这个页面变了没有”的声明。写不准，最直接的后果不是惩罚，而是它逐渐失去参考价值：抓取调度不再把它当回事，该早点来的页面还是按老节奏来。

lastmod 在抓取流程里扮演什么角色

搜索引擎在已有的 URL 队列里决定先抓谁，会参考多个信号：内链位置、历史更新频率、页面本身的重要性、上次抓取时间，以及 Sitemap 里声明的最后修改时间。lastmod 是其中比较直接的一个——它相当于告诉抓取系统“这个地址的内容有更新，可能值得重新取一次”。

需要明确的是，它只是一个信号，不是命令。写了 lastmod 不代表蜘蛛一定立刻来访；如果抓取方长期发现声明的时间和实际内容对不上，这个字段的权重会被降低，甚至被忽略。

三种常见写法，问题各在哪里

全站共用一个时间戳

生成 Sitemap 时统一写当天日期，是最省事的做法。结果是每次提交都像在说“全站一万个页面刚刚全部更新”，抓取系统无法从中区分哪个页面真的改了，这个字段也就等于没有。

每次生成都刷新

如果 Sitemap 是程序定时生成的，而 lastmod 取的是“生成时间”而不是“内容修改时间”，那每次输出都会把所有 URL 标记成新的。抓取方看到大量虚假更新之后，自然会降低对这个字段的信任。

改了模板但没改内容

页头、页脚、侧栏调整，页面正文没变。这时把全站 lastmod 刷新，属于误报；完全不刷新，又和事实略有出入。比较稳妥的判断是：只有影响到页面正文、结构化数据或主要内链结构的改动，才值得更新 lastmod。

落地时可以做的事

• lastmod 取页面内容的真实修改时间，而不是 Sitemap 文件的生成时间。
• 批量模板改动，除非影响正文或重要的站内链接，否则不必逐页刷新。
• 用 W3C 日期格式，只写日期（YYYY-MM-DD）通常就够了，没必要精确到毫秒。
• 已删除的页面从 Sitemap 中移除，不要留着反复声明。
• 分片 Sitemap 的 lastmod 可以取该分片内页面的最大修改时间，不要每次重建都改。
• 列表页、聚合页的 lastmod，建议跟着实际内容变化走，而不是跟着发布流程走。

怎么验证它到底有没有起作用

比较实际的方法是对照日志：挑一批真实更新过正文的页面，看它们更新后多久被重新抓取；再挑一批只是模板变动、lastmod 未更新的页面，看它们的抓取频率有没有变化。如果两组没有明显差异，说明抓取系统更多依赖其他信号，lastmod 的作用有限。

也可以结合抓取统计里的“上次抓取时间”，观察更新频繁的栏目是否被访问得更勤。这类观察需要几周的数据，只看一两天容易得出错误结论。

它不是一个收录开关

常见的误解是：把 lastmod 写好，页面就会被抓、被收录。实际上，能进入抓取队列的前提是 URL 已经被发现——来自内链、外链或 Sitemap。lastmod 影响的是“已发现的 URL 什么时候被重新抓”，不影响“能不能被发现”。

发现靠链接和 Sitemap，调度由多种信号共同决定，lastmod 只是其中一条，且需要长期写准才有参考价值。

所以更合理的顺序是：先保证 URL 能被稳定发现、页面能被正常访问，再来把 lastmod 写准。前者是地基，后者是锦上添花。