站点规模小的时候，一个 sitemap.xml 就能装下所有 URL。当页面数量涨到几万条，单文件会先撞上格式限制，再撞上加载时间。这时候真正需要处理的不是「要不要继续用 sitemap」，而是把它拆成多个文件，再用一个索引文件把它们串起来。
单文件 sitemap 的两条硬上限
按通用协议约定，单个 sitemap 文件最多容纳 50000 条 URL，未压缩体积不超过 50MB。这两个数字是格式层面的约束，不是建议值。文件超过上限后，抓取方可能只读取前面一段，后面的 URL 就停在队列之外。
即使没到上限，几万条 URL 塞在一个文件里，单次请求的响应时间也会变长。抓取方读取变慢，URL 发现的节奏自然被拖住。
sitemap index 解决什么
sitemap index 本身不是 URL 列表，而是一份文件清单。它只包含各个分片 sitemap 的地址和最后修改时间。抓取方先读索引，再按需去取分片，压力被摊开，单个文件的体积也回到可控范围。
索引文件的作用是分流，不是替代。它让抓取方知道有哪些分片，剩下的取舍仍由对方决定。
分片按什么维度切
切分方式没有唯一答案，但有一种原则值得遵守：让每个分片内部有共同特征，方便以后单独排查。
- 按目录或内容类型：文章、商品、专题、帮助文档各占一个分片，出问题时能快速定位是哪一块。
- 按更新时间：更新频繁的页面单独放一个分片，让它的 lastmod 变化更集中，也更容易被反复读取。
- 按语言或地区：多语言站点的各语言目录分开，避免一个分片里后缀混杂。
分片数量不必太少，但也不宜碎到几百个。几十个分片通常就够用，过多会增加索引文件本身的读取次数。
索引文件上容易犯的错
- 索引文件里混入了普通页面 URL，格式不对，解析直接失败。
- 分片地址写成相对路径，抓取方无法拼接。
- 分片返回了 404 或需要登录才能访问，索引里的链接形同虚设。
- 分片内容更新了，索引里的时间字段却一直没动。
压缩与提交
分片文件可以用 gzip 压缩，通常按 .xml.gz 命名。压缩后传输量下降，抓取方读取更快，但要注意响应头里的 Content-Type 与文件名一致，避免解码阶段出错。
索引文件提交之后，不等于里面的分片都会被取走。可以在抓取日志里观察分片的请求频率，判断哪些分片被读取过、哪些一直没动静。一个分片长期无人访问，先检查它在索引里的位置和自身是否可访问。
它替代不了内链
sitemap 提供的是 URL 清单，不提供页面之间的路径关系。一个只出现在 sitemap、任何页面都不链接的 URL，即使被发现，也很难判断它在站内处于什么位置。
更稳妥的做法是两条路并行：sitemap 负责把清单交出去，内链负责给出真实的进入路径。巡检时可以对一下两边数量——如果某个目录的页面大量只存在于 sitemap，说明内链结构出现了断层。
最后提醒一句：分片是为了让发现过程更顺，不是为了让所有 URL 立刻被抓取。文件拆得再整齐，能不能被访问、值不值得抓取，仍取决于页面本身和服务器状态。