很多人把 Sitemap 当成一次性配置：生成、提交、然后就不管了。但站点地图更像是一份持续更新的待办清单，蜘蛛会照着它决定先去哪、后去哪。清单本身如果乱，蜘蛛的节奏也就跟着乱。
lastmod 到底在影响什么
lastmod 不是强制指令，而是一个参考信号。当站点规模较大、更新频繁时，蜘蛛不可能每次都把所有页面重抓一遍，它需要一个粗略的排序依据：哪些页面值得优先回访。如果这个时间戳长期失真，这个排序依据基本就废了。
判断 lastmod 是否可信，标准很简单：随机挑十个 URL，把时间戳和后台真实的修改记录对一遍，看看能不能对上。
分片结构怎么划更合适
单份 Sitemap 有体积和条目数量的上限约定，超过就需要拆分成索引文件加多份子文件。拆分方式没有唯一答案，但要选一种后续好维护的：
- 按栏目拆：适合栏目更新频率差异大的站点，比如资讯区和产品区分开，各自独立更新。
- 按内容类型拆：文章、商品、专题页各一份，便于单独排查某一类的异常。
- 按时间区间拆：适合大量历史归档内容，把不再更新的老内容单独放一份，减少重复生成。
不建议每次全量重写所有分片。增量更新时只改动受影响的那几份，既能降低服务器负担，也让抓取日志里的变化更容易看懂。
lastmod 最容易写错的几处
全站同一个时间戳
有些生成脚本图省事，把当前时间直接写到所有条目上。结果是每份分片的时间都是“刚刚”，蜘蛛看到所有页面同时更新，等于没有提供任何区分度。
构建时间覆盖了真实修改时间
静态站点重建时，如果时间戳取自构建过程而不是内容本身的修改记录，就会出现没改过的页面也被标成新页面。正确做法是从内容源或数据库里取真实修改时间。
格式与时区不统一
时间格式需要完整、带时区标识，且和服务器、后台记录保持一致。如果生成环境用 UTC、后台用本地时间，两边就会差几个小时甚至一天，对账时很难判断是谁错了。
只改了样式也更新时间
模板调整、导航微调会触发生成流程，但内容本身没变。这类改动是否该刷新 lastmod，取决于改动是否影响页面主体内容。如果只是样式，通常没必要。
一套可以照做的自查流程
- 列出当前所有分片地址，确认索引文件能正常访问，没有遗漏或重复引用。
- 抽样比对：每个分片随机抽几条，和后台修改时间对照，记录偏差。
- 检查格式，确认时区标识统一，没有缺失或格式错误的条目。
- 核对内容范围，把不该在里面的 URL 剔除出去。
- 观察日志，看蜘蛛访问 Sitemap 的频率、返回状态，以及 Sitemap 中 URL 的实际抓取情况。
- 把核对动作固定成周期性检查，比如每月一次，而不是等发现问题再回头翻。
哪些 URL 不该出现在 Sitemap 里
- 设置了 noindex 的页面，两边信号互相矛盾。
- 会跳转的旧地址，应直接给出最终地址。
- 已经失效的页面，Sitemap 里留着只会让蜘蛛反复撞墙。
- 大量参数组合产生的筛选结果页，这类地址更适合交给页面内部链接处理。
- 登录后、购物车等无收录意义的页面。
和日志、后台记录对照着看
Sitemap 只是链条的一端。真正判断它是否有效，要看蜘蛛访问站点地图后有没有实际去抓 URL，抓的是不是清单里的地址，以及新发布的内容多久能被访问到。把这些观察和内容更新记录放在一起看，才能判断是站点地图的问题，还是抓取预算、内链结构的问题。
这份清单不需要做得很复杂，关键是保持和实际更新节奏一致。清单准了，蜘蛛的时间才花得值。