站点地图里的 lastmod 字段，本意是告诉搜索引擎“这个 URL 的正文最后一次实质性变化发生在什么时候”。它不决定页面能否被收录，但会影响抓取调度：抓取资源有限时，一个看起来很久没变过的 URL 往往排在后面。问题在于，很多站点的 lastmod 是程序自动写入的时间戳——每次部署、每次生成缓存、每次模板微调都会刷新它，这个信号很快就失真了。
lastmod 失真后会看到什么
它不会让站点立刻出问题，通常会表现为几种慢性症状：
- 全站 URL 的 lastmod 每天一起变化，搜索引擎无法从中区分哪些页面真的更新了；
- 真正修改过的页面淹没在大量“伪更新”里，重新抓取要排更久的队；
- 反过来，如果某个栏目的时间戳长期不动，抓取频次也可能随之下降；
- 报告里“已抓取，尚未编入索引”的比例升高时，很难判断是内容问题还是调度问题。
先给 lastmod 一个明确的定义
在动手改之前，团队内部要先统一它代表什么，例如：
- 只表示正文主体的变化，包括标题、正文内容、关键数据与图表的修订；
- 不触发更新：模板改版、CDN 刷新、评论新增、广告位调整、文件重新部署；
- 触发更新：正文增删、数据修订、错别字与事实纠错、正式发布时间调整。
如果页面同时展示“发布时间”和“更新时间”，要保证结构化数据、页面文字和站点地图三者一致，不要出现页面写着 2019 年、lastmod 却是今天的情况。
核对顺序
- 抽样比对。从站点地图里随机取 20 到 30 条 URL，把 lastmod 与页面上显示的更新时间、版本记录逐条对照，先看有没有明显不吻合的样本。
- 看整批分布。把全站 lastmod 按日期做一次统计。如果九成 URL 集中在最近两三天，基本可以判断这是程序统一写入的时间，而不是真实更新时间。
- 定位写入位置。找到生成 sitemap 的那段代码，确认时间字段取的是内容表的更新时间，还是文件系统修改时间、构建时间或运行时间。
- 按页面类型区分。文章、商品类页面适合细粒度的最后修改时间；分类页、标签页可以取“该分类下最新一篇内容的时间”，但不要用当前时间。
- 处理历史值。如果站点有版本记录或历史快照，可按内容实际修订时间回填；没有可靠依据时，宁可留空或写一个偏保守的时间，也不要继续写当天。
- 观察后续变化。修正后观察几周的抓取频次，以及“已发现—尚未抓取”的数量变化。这类信号需要时间才反映出来，不要频繁反复调整。
另外两个字段可以少花精力
changefreq 与 priority 早已被主流搜索引擎忽略，继续维护它们意义不大。真正值得投入的，是让 lastmod 接近事实，同时保证 URL 本身干净、可访问、返回正常状态码，并且站点地图里只放需要被抓取的地址。
lastmod 只是一个调度提示。它不能让质量不够的页面被收录，也不能替代内容本身的更新。把它写准，是为了让抓取资源更多地花在你真正改动过的页面上。
如果你在访问日志里看到某个搜索引擎反复抓取同一批入口页、却很少深入内页，除了检查内链与结构，也不妨回头看一眼站点地图里的时间戳是不是在频繁抖动。这种“看起来一直在更新”的假信号，往往是抓取集中在内层几个地址上的原因之一。