当站点 URL 数量达到几万甚至更多时，单个 Sitemap 文件很容易触到条数和体积的上限。这时继续往一个文件里塞，不仅维护困难，搜索蜘蛛读取时也可能只拿到一部分。更稳妥的做法是用 Sitemap 索引文件把多个子地图组织起来，让 URL 发现入口保持清晰。
Sitemap 索引文件解决什么问题
常见的 XML Sitemap 有两条硬限制：单个文件最多 5 万条 URL，未压缩体积不超过 50MB。超过之后，就需要拆成多个子地图。索引文件本身不直接列 URL，它只负责告诉搜索蜘蛛：这个站点有哪些子地图、它们分别在哪里。
可以把索引文件理解成一本总目录。搜索蜘蛛先读总目录，再按顺序去读各个子地图。这样即使站点有几十万条 URL，也能通过一个固定地址被发现。
拆分维度：按什么逻辑切分
分片不是随便切，最好和站点本身的结构对齐。常见的拆分方式有几种：
- 按栏目或频道：新闻、商品、帮助中心各自一个子地图，边界清楚，更新频率也接近。
- 按内容类型：文章页、列表页、标签页分开。不同类型页面的抓取价值不一样，放在一起反而不便观察。
- 按更新时间：把最近更新的内容单独放一个子地图，方便搜索蜘蛛优先回访。
- 按 URL 数量均匀切：如果站点结构比较平，也可以单纯按条数切，每个子地图控制在几千到一两万条，便于排查。
无论选哪种，子地图的地址一旦确定就尽量保持稳定。频繁更换分片地址，等于把已经建立的 URL 发现入口拆掉重建，搜索蜘蛛需要重新适应。
索引文件的基本写法与注意点
索引文件的根标签是 sitemapindex，里面每个 sitemap 子项包含一个 loc，也就是子地图的完整地址。可选的 lastmod 用来标注该子地图最后修改时间，但不要为了“显得新鲜”而随意改动。
有几个细节容易被忽略：
- 索引文件里不要再嵌套另一个索引文件，搜索蜘蛛通常不希望你绕来绕去。
- 子地图地址必须是绝对地址，并且和站点协议、主机名保持一致。
- 子地图如果启用了 gzip 压缩，索引里的地址仍然写未压缩前的 .xml 地址即可。
- 索引文件本身也要能被正常访问，返回 200 状态码，不要被 robots.txt 误拦。
分片之后，URL 发现还要靠内链
Sitemap 是补充型入口，不是唯一入口。分片做得再整齐，如果页面之间没有内链，搜索蜘蛛读完地图后仍然可能只抓取一部分。比较稳的做法是：重要页面既出现在合适的子地图里，也能从栏目页、列表页或正文链接被点到。
另外，子地图里的 URL 应当是可抓取的规范地址。如果里面混入大量带追踪参数、会话 ID 或重定向地址，分片反而会把抓取队列搞乱。定期抽查子地图内容，比单纯增加分片数量更有用。
服务器响应与分片维护
子地图数量多，对服务器稳定性的要求也会提高。如果某个子地图返回 5xx 或超时，搜索蜘蛛这次可能就跳过它。如果索引文件本身访问不稳定，整批 URL 发现入口都会受影响。建议把 Sitemap 文件当成静态资源来对待，做好缓存，避免每次请求都动态生成。
排查时可以从外到内：先确认索引文件能正常打开，再逐个检查子地图是否返回 200，最后看子地图里的 URL 是否真实可访问。哪一层断了，就先修哪一层。
一个简单的检查顺序
- 索引文件地址是否固定、可访问、协议主机名统一。
- 子地图是否按栏目或类型拆开，单个文件没有超限。
- 每个子地图里的 URL 是否返回 200，是否包含规范地址。
- 重要页面是否有内链支撑，而不是只依赖 Sitemap。
- 服务器日志里，索引文件和子地图是否被稳定抓取。
把这些环节理顺之后，Sitemap 索引与分片才能真正承担起大站点 URL 发现入口的角色，而不是变成一份没人维护的清单。