把sitemap里的lastmod和正文发布时间对齐后，抓取频次差了两倍多

上周排查一个客户的站，发现一个挺反直觉的事：sitemap 里的 lastmod 和正文里的发布时间对不上，抓取频次能差两倍多。

先上场景。客户站里有两批产品页，A 批 120 个页面，sitemap 的 lastmod 是每次编辑都更新，但正文里那行「发布日期」一直没动，还是 2022 年的。B 批 80 个页面，lastmod 只在实质内容变更时更新，正文发布时间同步改。

我拉了两周的抓取日志做对比：

A 批那 61% 的重抓率看着热闹，其实全是无效抓取——爬虫被 lastmod 骗过来，发现正文没变，白跑一趟。两周下来，A 批的「有效抓取」占比只有 22%，B 批是 78%。

判断依据就一条：lastmod 本质是承诺，正文发布时间是账本。承诺和账本对不上，爬虫会先信承诺，但信两次就不信了。A 批里我抽了 20 个页面看日志时间戳，有 7 个页面在连续 3 次抓取后，重抓间隔从 6 小时拉长到 40 小时以上，等于被降权了。

踩坑细节：我一开始想直接批量改 lastmod，把假的都改回去。后来翻日志发现不行——已经抓过的页面，lastmod 往回改会被当成「内容回滚」，反而触发一次全量重抓。最后是按批次灰度，只改没被爬过的页面，老的等自然衰减。这个坑我记下来了：lastmod 只能单调前进，不能往回拨。

另一个细节，正文里的 <time datetime=""> 字段口径要统一。客户站里一部分页面用的是 ISO 8601 带时区，一部分是纯日期，我在日志里看到带时区的页面被抓的时间戳更准，纯日期的那批在跨时区 CDN 上会漂移一天。这个后面再单独测。

现在想问一下：你们站上 sitemap 的 lastmod 是怎么生成的？是构建时自动写，还是 CMS 里手动维护？我总感觉手动维护的那部分才是噪声最大来源。