站点 URL 从几百涨到几万之后，一个 Sitemap 文件往往就不好维护了：生成时间长、内容混杂、改一次要全量重出。这时候通常需要引入索引文件，把清单拆成多个分片分别管理。做得好不好，会直接影响蜘蛛对这些 URL 的发现效率。
单个 Sitemap 的硬性限制
按通行约定，单个 Sitemap 文件不超过 50000 个 URL，未压缩体积不超过 50MB。超出就需要拆分，并用一个索引文件把各分片串起来。
索引文件本身也是 XML，但它只列各分片的位置和最后更新时间，不直接列具体页面 URL。蜘蛛读到索引后，会按其中的地址逐个取分片，再解析里面的页面链接。也就是说，分片多一层，就多一层被发现和被请求的机会，这层结构本身要尽量简单、稳定。
分片可以怎么切
按栏目或业务线
最常见也最好理解的做法：文章列表一个分片，商品一个分片，帮助中心一个分片。某个板块出问题或需要暂停提交时，单独调整即可，不会牵连全站。
按内容类型
把页面分成详情页、列表页、标签或聚合页几类。聚合页数量容易膨胀、质量参差不齐，单独成片便于控制，也方便日后收紧或放开。
按更新时间
适用于更新频繁的站点：一个全量分片加若干增量分片，按时间段切分。这样每次只需要重新生成发生变动的部分，其他分片保持原样，维护成本低很多，也减少了因为重复生成引入错误的概率。
- 每个分片控制在几千到几万条，不要紧贴 5 万上限，留出余量
- 分片文件名保持稳定，不要每次生成随机名，否则等于换了一批新地址
- 所有分片地址必须可访问，返回正常的成功状态，不要中途跳转到别处
索引文件最容易踩的坑
- 索引里还写着已经下线的分片，取回是 404 或 410，蜘蛛会反复来试
- 生成了分片却忘了写进索引文件，等于没有提交
- 同一批 URL 同时出现在多个分片，造成重复发现和抓取浪费
- 每个分片都把更新时间写成当天，这个字段就失去了参考价值
Sitemap 是 URL 发现通道，不是收录保证。它只是告诉蜘蛛这里存在一个地址，至于抓不抓、抓多少、什么时候抓，仍由蜘蛛自己判断。
和内链、robots 怎么配合
在 robots.txt 里声明 Sitemap 位置对部分蜘蛛有效，但更关键的是站内链接是否可达。一个只出现在清单里、站内没有任何链接指向的 URL，长期看被抓取的意愿偏低。清单应当是对已有内链结构的补充，而不是替代品。
分片文件建议开启压缩，减少传输体积。压缩后的分片同样能被正常解析，对带宽和抓取耗时的压力都更小。
分片太多带来的隐性成本
分片越多，需要维护的对象就越多，任何一个失效都会让一批 URL 长期停在未被发现的状态。建议定期做一次对账：抓取日志里出现过哪些分片请求、返回什么状态，索引文件里列了哪些分片，两边的条目是否对得上。对不上的部分，往往就是长期没被处理的遗留问题。
一份可执行的检查清单
- 索引文件本身能正常访问，XML 格式合法
- 每个分片都能打开，条目数量与预估规模相符
- 分片内的 URL 与页面上的规范地址一致，不混入参数垃圾和已重定向的旧地址
- 更新时间取自页面真实变动时间，而不是每次生成时的系统时间
- 日志中能看到蜘蛛按索引依次访问各分片，而不是只反复取索引文件
不必追求把全站 URL 一口气全部塞进清单。可维护、能持续更新、结构清晰，比单纯堆数量更有意义。清单稳定下来之后，URL 发现这件事才有可预期的节奏。