Sitemap 是最常见的 URL 发现入口，但站点规模上去之后，把所有地址塞进一个文件通常行不通。搜索引擎对单个 Sitemap 有明确的条数和体积上限，超出部分需要拆成多个分片，再用一个索引文件把它们串起来。分片做得好，蜘蛛能稳定地拿到 URL 清单；做得乱，反而会让一批地址长期停留在待抓队列之外。

单文件的两个硬约束

常见的处理原则是：

• 单个 Sitemap 文件最多包含 50000 条 URL；
• 未压缩状态下体积不超过 50MB；
• 文件需要 UTF-8 编码，压缩只能使用 gzip；
• 索引文件本身同样受这两条上限约束，一个索引可以指向多个分片。

也就是说，URL 数量到十万级时，靠一个文件已经不太可行；到百万级时，索引下面还要再分层，或者按业务线拆成多个索引分别维护。

索引文件解决什么问题

索引文件本身不包含页面地址，它只列出各个分片的位置。它的价值在于给蜘蛛一个稳定入口：只需抓取一个地址，就能顺着清单找到全部分片，而不必去猜你的 URL 规律。

实践中建议把索引放在站点根目录下的固定路径，并在 robots.txt 中声明，避免每次改版都换地址。分片地址尽量写成绝对 URL，且不要指向会跳转的地址——多一跳就多一次消耗。

按什么维度拆分更合理

• 按内容类型：文章、商品、栏目页分开，各自的更新节奏不同，便于单独维护。
• 按更新时间：把近期更新的 URL 放一个分片，历史 URL 放另一个，蜘蛛抓近期分片的收益更直接。
• 按语言或地区：多语言站点按语言拆，避免一个分片里混着大量与当前站点无关的地址。
• 按数量切齐：如果没有明显的业务维度，就按 2 万到 3 万条一个分片切，留出增长余量，不要卡着 50000 条顶格。

拆分维度没有唯一答案，判断标准是：更新频率相近、生命周期相近的 URL 放在一起，维护时才不会互相拖累。

lastmod 别乱写

lastmod 是蜘蛛判断分片是否需要重新抓取的参考之一。如果每次生成 Sitemap 都把全部条目的时间刷成当天，这个字段就失去了意义，时间久了蜘蛛也会逐渐忽略它。更稳妥的做法是让 lastmod 跟随内容真实的修改时间，只对确实变动过的 URL 更新。

分片的价值不在于“写了多少条”，而在于清单是否干净、时间是否可信。

几个容易踩的坑

• 分片里留着已经 404 或 301 的老地址，等于持续给蜘蛛制造无效抓取。
• 分片文件本身返回 404 或 5xx，整个索引就失去作用，需要把分片当成正式页面来监控。
• 分片数量过多、每个分片只有几十条，会增加蜘蛛的抓取次数，收益却不高。
• 只在提交时生成一次，之后长期不再更新，新增 URL 就进不了清单。

怎么确认分片被正常抓取

可以在服务器日志里单独筛出 Sitemap 相关请求，观察几个指标：分片是否被访问、返回码是否为 200、访问频率是否稳定、新生成的分片是否在几天内被取走。如果某个分片长期无人访问，优先检查它是否写进了索引文件、地址是否可以直接打开。

分片和索引只是 URL 发现的一环，它需要和内链结构配合：Sitemap 负责把地址交给蜘蛛，内链负责告诉蜘蛛这些地址值不值得反复来。两者对不上时，通常先看 Sitemap 里是否混进了不该出现的地址。