站点 URL 数量上来以后，单份 Sitemap 会撞到两个限制：协议对文件大小和 URL 条数的上限，以及蜘蛛读取一份大文件时的处理成本。Sitemap 索引文件（sitemap index）就是为这种情况准备的：它本身不列具体页面，只列出若干份子地图的地址。蜘蛛先读到索引，再顺着里面的地址去取每一份子地图，URL 的发现路径就变成了两层。
索引文件不负责排序
很多人会默认索引里排在前面的子地图会被优先抓取，实际上索引文件只是提供地址清单。蜘蛛拿到清单后仍按自己的调度逻辑处理，抓取顺序受更新频率、站点整体抓取节奏、服务器响应状况等因素影响。把索引当成“优先级队列”来用，通常得不到想要的结果。
它真正的作用是让 URL 清单变得可维护：按业务或更新时间切成多份，出问题时可以只替换其中一份，而不用重写整个文件。
常见的几种拆法
- 按内容类型拆：文章、商品、分类、标签各一份。适合结构清晰、模板差异大的站点。
- 按更新时间拆：例如按月或按周生成子地图。更新频繁的站点用这种方式，能让新 URL 集中出现在固定的几份文件里。
- 按语言或地区拆：多语言站点常见，便于和 hreflang 一起核对。
- 按目录或业务线拆：适合由不同团队维护内容的站点，责任边界清楚。
如果只是 URL 多、结构单一，按更新时间拆通常最省事；如果各模块的页面模板完全不同，按内容类型拆更容易发现遗漏。
子地图里的 lastmod 表达什么
子地图中的 lastmod 描述的是页面内容的最后修改时间，而不是这份文件生成的时间。索引文件里也可以带 lastmod，它指的是对应子地图的更新时间。两者混淆时，蜘蛛可能反复回取一份实际没有变化的子地图。
子地图每次重新生成都会变，但里面的页面未必变。如果每次生成都把 lastmod 刷成当前时间，这个字段的参考价值就会下降。
拆分时的操作清单
- 先统计当前可被抓取的规范化 URL 总量，再决定每份子地图放多少条，给后续增长留出余量。
- 子地图地址保持稳定，不要带随机参数或时间戳。
- 索引文件与子地图都使用绝对地址，并确保协议、域名与站点当前规范一致。
- 子地图自身不要放进 sitemap 列表里，避免索引与子地图互相引用。
- 检查 robots.txt 没有误屏蔽子地图路径，否则索引存在、入口却取不到。
- 确认子地图返回的是 XML 内容类型，而不是被重写规则带回首页或返回 HTML。
容易踩的几个坑
- 索引嵌套索引：索引文件里只能放子地图，不能再指向另一份索引，多层的写法无法被正常读取。
- 子地图返回 404 或 5xx：索引仍在，但这一支的 URL 发现路径等于断了，日志里通常能看到反复请求失败的记录。
- 列了已下线模块的子地图：文件长期返回空内容，既不提供有效 URL，也占用蜘蛛的请求次数。
- 压缩格式没声明：直接提供 .gz 文件时，要确认响应头与文件后缀一致，否则取回来也解析不了。
- 同一批 URL 出现在多份子地图：蜘蛛会看到重复入口，虽然不会直接导致问题，但会让统计和排查变复杂。
怎么验证拆分是否有效
把服务器访问日志按 URL 前缀分组，观察三件事：索引文件和子地图是否被定期回取；子地图里的 URL 是否出现在后续抓取记录中；失效子地图的请求是否长期停留在错误状态。如果某个模块的页面在日志里始终没有抓取记录，先看它对应的那份子地图是否被成功读取，再回头看内链是否提供了另一条路径。
Sitemap 索引解决的是“URL 清单怎么组织”的问题，不解决“蜘蛛一定来抓”的问题。把分片做清楚、地址保持稳定、错误能快速定位，它就是一个可靠的基础设施；把它当成抓取量的开关，反而容易在排查时被误导。