URL 数量上到几万条之后，单个 Sitemap 文件通常就不够用了，需要用一个索引文件把多个分片串起来。拆文件本身不难，麻烦的是拆分依据、命名方式和后续核对——分片一旦混乱，日志里就看不出蜘蛛究竟读到了哪一部分。
先确认上限，再决定要不要拆
- 单个 Sitemap 在未压缩状态下不超过 50MB，URL 条数不超过 50,000。
- 索引文件同样不超过 50,000 个分片、50MB；压缩后的大小不计入这个上限，但解压后仍需合规。
- 超过上限就要拆分，并用一个索引文件列出所有分片。分片单独提交也可以，但索引更利于统一管理。
按什么维度拆分更实用
常见有三种拆法，各有适用场景：
- 按内容类型：文章、商品、标签页、作者页各成一组。好处是不同模板的抓取情况可以分开看，出问题时能直接定位到具体类型。
- 按更新时间：近期更新的 URL 放一片，历史内容放另一片。适合更新频繁的站点，便于高频回读新片。
- 按语言或分站：多语言、多域名站点按站点维度拆，避免不同站点的抓取数据混在一起。
实际操作中，先按内容类型拆，再在类型内部按体量分序号，是比较省事也容易维护的做法。
索引文件里放什么
索引文件只承担目录职责，每个条目指向一个分片文件的绝对地址，可以附带该分片的最后修改时间；分片文件里才写具体页面 URL。索引不要再嵌套索引，层级过深只会增加回读成本。索引一般放在站点根目录，方便在 robots.txt 中声明。
索引文件是目录，分片文件才是清单。把页面 URL 直接写进索引是常见错误，蜘蛛读到一份没有可抓页面的目录，只会白白多一次回读。
命名要能一眼看懂
分片命名建议带上类型和序号，例如 sitemap-article-001.xml 这样的形式，不要用随机哈希值，也尽量不要在分片路径上带查询参数。命名规整的好处在于：日志里出现某个分片路径时，你立刻知道它对应哪类 URL，核对覆盖率时可以直接按分片分组统计，而不必一条条比对。
分片与抓取路径不是一回事
Sitemap 只是清单，蜘蛛读完清单仍要逐个抓取页面。分片里塞进大量内链找不到的 URL，确实能提高被发现的速度，但收录与否仍取决于服务器响应、页面质量与重复程度。把 Sitemap 当成内链的替代品，往往只会得到一批「已发现未抓取」的记录。
日常核对清单
- 在日志中筛选 Sitemap 路径，确认蜘蛛是否定期回读索引与各分片，而不是只读一次就再也不来。
- 统计每个分片的实际输出条数与预期条数是否一致，模板循环漏掉最后一条的情况并不少见。
- 抽查分片内 URL 的响应状态与 canonical 指向，确认没有混入 404、重定向或 noindex 地址。
- 页面下线后同步从分片移除，避免同一批死链被反复提交。
- 观察索引文件的最后回读时间，长期不更新时先排查 robots.txt 与服务器响应，再考虑重新提交。
容易被忽略的几个坑
- 分片内容更新了，lastmod 却没变，抓取端可能按缓存判断为无需重读。
- 压缩分片没有正确声明内容类型，导致解压失败。
- 索引与分片使用了不同的域名形态，http 与 https、带 www 与不带 www 混用。
- 分片数量只增不减，旧片长期留存，清单越来越难维护。
小结
Sitemap 分片是一种清单结构，不是收录手段。把上限规则、拆分维度、命名约定和核对清单固定下来，URL 发现的过程才可控；剩下的，仍然交给内链、响应速度和内容本身。