站点刚上线时，一个 sitemap.xml 就能装下所有 URL。但当 URL 数量涨到几万条，或者页面地址很长导致文件体积变大，单个文件就会触到上限。这时候需要用 sitemap index（索引文件）把 URL 拆成多个分片，否则蜘蛛可能读不完，甚至直接放弃这个文件。
单文件有硬上限，超了就得拆
按目前通用的规则，一个 Sitemap 文件最多包含 50000 条 URL，未压缩时体积不超过 50MB。两个条件任何一个先到，就需要拆分。拆分不是把文件随便切两半，而是把 URL 按某种逻辑分组，放进不同的子文件，再用一个索引文件把它们串起来。
- URL 条数先到 5 万：按栏目或时间切分；
- 体积先到 50MB：通常是页面地址很长，或包含了大量带参数的链接，需要先精简；
- 两者都没到但读取缓慢：检查服务器响应速度和压缩设置。
索引文件本身只做一件事
sitemap index 不包含任何页面 URL，它只列出各个子 sitemap 的地址和各自的最后更新时间。蜘蛛先读索引，再按里面的地址去读分片。因此索引文件要保持稳定，文件名和路径不要频繁变动，否则蜘蛛每次都要重新确认一遍。
索引文件也要在 robots.txt 里声明。常见的做法是只声明索引文件，让蜘蛛顺着索引去找分片；也可以把分片一并声明，但要注意别把不再维护的旧文件留在里面。
分片怎么切：三种常见方式
按栏目或内容类型
文章、商品、标签、帮助文档各占一个分片。这种方式便于维护，某个栏目更新频繁时，只需要重新生成对应的分片，其他分片的内容和 lastmod 保持不动。
按时间
按周或按月切分，适合更新量大的内容型站点。但要注意，老内容的分片一旦不再变化，就不要每次都重新生成并刷新时间，否则等于在告诉蜘蛛这个文件又变了。
按 ID 段
按数字区间切分，实现简单，适合内容 ID 连续的站点。缺点是可读性差，排查问题时不容易判断某个 URL 落在哪个分片里。
lastmod 怎么写才不会误导
每个分片的 lastmod 应当是该文件内 URL 最近一次真实更新的时间，而不是文件生成的时间。如果每次跑脚本都写当前时间，蜘蛛会以为内容有变化而反复来读，读完却发现没有更新，长期下来对这个文件的参考价值会下降。
lastmod 是一个提示，不是催促蜘蛛的工具。时间写得越准，蜘蛛对它的参考价值越高。
Sitemap 负责发现，内链负责走进去
Sitemap 解决的是这个 URL 存在，它不保证蜘蛛一定会抓取。真正决定蜘蛛能不能从首页一步步走到的，还是站内的链接结构。如果一批页面只出现在 Sitemap 里，站内没有任何入口，蜘蛛即便读到了地址，抓取优先级也会比较低。比较稳妥的做法是两者配合：重要页面既有内链入口，也在 Sitemap 中列出。
几个常见的坑
- 分片切得太碎，几十个文件每个只有几百条 URL，蜘蛛读取索引本身也要花时间，反而增加负担。
- 旧分片不再更新，却一直留在索引里，蜘蛛会持续访问这些没有内容的文件。
- 分片放在别的域名下，需要注意跨域声明的限制，否则可能读取失败。
- 分片里混入了 404、403 或重定向地址，会消耗抓取资源，也容易让蜘蛛对整份文件打折扣。
- 索引文件没有在 robots.txt 中声明，导致蜘蛛只能靠外链或历史记录才发现它。
检查分片是否生效，可以看抓取日志里蜘蛛对各 sitemap 文件的访问频率和返回状态，也可以在站长平台里对比已提交与已发现的 URL 数量。两者长期对不上，通常不是 Sitemap 写得不够多，而是分片结构或内链入口出了问题。