Sitemap 常被当成“提交就能被抓”的开关，实际它更像一份交给蜘蛛的清单：告诉它站点上还有哪些地址存在。至于这些地址什么时候被抓、抓多深，仍然由抓取系统和页面本身决定。把 Sitemap 写对，能减少无谓的探索成本；写歪了，反而会给自己的抓取数据添乱。

Sitemap 能做什么，不能做什么

它的主要价值是URL 发现：当站内链接结构有死角，或者新页面还没被内链串起来时，Sitemap 是一个补充入口。它不能提高某个页面的优先级，也不能保证被抓取。理解这一点，后面的取舍会清晰很多。

lastmod：只写真实修改时间

lastmod 是 Sitemap 里少数会参与抓取判断的字段，但前提是它足够可信。几个常见做法值得注意：

• 只在页面内容确实发生变化时更新，不要每次部署或模板调整就全站刷新。
• 使用带时区的 ISO 8601 格式，例如 2024-05-06T10:20:00+08:00，避免只写日期导致时间被随意解读。
• 批量生成的 lastmod 如果长期与实际情况不符，抓取方会逐步降低对该字段的参考程度。
• 列表页、聚合页这类频繁变动的地址，如果只是排序变化，未必需要跟着更新时间。

反过来，如果站点多数页面确实长期不动，lastmod 保持不变是正常的，不需要为了“看起来活跃”人为造时间。

分片与索引文件：怎么切更省事

站点大一些之后，通常会用 Sitemap 索引文件组织多个子 Sitemap。切分方式没有唯一答案，但有几条经验：

• 按目录或内容类型切，例如文章、商品、专题各自一个文件，出问题时容易定位。
• 单个文件的地址数量控制在合理范围，别让它变成一个巨大的响应体，读取起来更费时间。
• 每个分片的地址保持稳定，不要频繁改名或换路径，否则等于让抓取方重新熟悉一遍。
• 索引文件只列子 Sitemap 的地址，不要把页面 URL 混在里面。

哪些 URL 不该放进去

Sitemap 里混入不该抓的地址，会分散抓取资源。常见几类：

• 返回重定向或其他非 200 状态的地址，应该直接提供最终地址。
• 被 robots.txt 屏蔽的目录，放进去只是一份无效清单。
• 带会话、排序、筛选参数的变体地址，容易与规范地址重复。
• canonical 指向别处的页面，直接提供规范地址更清楚。
• 登录后、后台、测试环境的路径，本就不该暴露给抓取。

提交之后看什么

看日志比看后台数字更实在。可以留意 Sitemap 文件本身的请求记录：抓取方多久来取一次，取完之后有没有跟着访问里面的地址。再把清单中的 URL 和日志里实际被抓的 URL 做个对比，重合度低通常说明这些地址在别处已经被发现，或者站点整体抓取额度有限，新清单排在后面。

另一个常被忽略的点是响应码分布。如果 Sitemap 里的地址被抓时大量返回 3xx、404 或 5xx，先修这些，再谈更新清单。

Sitemap 是一份清单，不是一条命令。它的价值取决于清单里的地址是否真实、可抓、值得抓。

几个容易踩的坑

1. 把 Sitemap 当成新页面的唯一入口，站内没有任何链接指向该页面。即使被发现，页面在站内的位置也很难被理解。
2. 每次内容更新后重新生成全部 Sitemap，lastmod 全站翻新，反而让时间字段失去区分度。
3. 只提交不维护，站点改版、目录调整后，清单里还留着大量旧地址。

把 Sitemap 当成站点结构的备份说明来维护：结构清楚、地址干净、时间真实，它对 URL 发现的帮助才会稳定发挥。