Sitemap 的作用是给搜索蜘蛛一份明确的 URL 清单。当站点 URL 数量涨到几千、上万，单个文件会变得又大又难维护，这时通常要引入 Sitemap 索引文件（Sitemap Index），把众多子 Sitemap 组织成一个总入口。
什么时候该用索引文件
并不是所有站点都需要分片。判断标准大致有三条：
- URL 总量接近或超过单个文件的容量上限；
- 站点包含多个栏目、子域名或多语言版本，希望分批提交；
- 不同板块的更新频率差异很大，混在一个文件里不好定位问题。
如果站点只有几百个页面，内链结构也清楚，一个普通 Sitemap 就够了，额外加一层索引反而增加维护成本。
分片维度怎么选
按栏目或目录拆
最常见也最省心的方式。文章、商品、帮助文档各自一个子 Sitemap，路径保持稳定，例如 /sitemap-articles.xml。某个板块出问题，只影响对应分片，排查范围小。
按语言或地区拆
多语言站点按语言分片，能看清每个语言版本的 URL 数量是否合理，也方便核对 hreflang 指向的页面是否都在这份清单里。
按内容类型或更新频率拆
更新频繁的列表页、新发布内容放一个分片，历史归档放另一个分片。这样在抓取日志里更容易判断：搜索蜘蛛是先去翻新内容，还是一直在旧归档里打转。
单片文件的边界与写法
- 单个 Sitemap 的 URL 数量上限是 5 万条，未压缩体积上限 50MB，任一超标都要继续拆。
- 条目地址必须是绝对 URL，注意实体转义与特殊字符编码。
- 体积较大时可以使用 gzip 压缩，但索引文件里引用的地址要指向实际可访问的压缩文件。
- 索引文件本身只列子 Sitemap 的位置与最后修改时间，不要再混入普通页面 URL。
分片之后，入口仍要能被找到
索引文件不会自己被发现。至少保证三件事：robots.txt 里声明主索引文件地址；在站长平台提交同一个地址；站内保留一个 HTML 版本的站点地图页，让用户和搜索蜘蛛都能顺着链接进入各分片。三条路径相互补位，单条失效时不至于完全断掉。
分片管理最容易踩的坑
- 只提交子分片，不提交索引：新增分片容易被漏掉，也看不到整体规模。
- lastmod 全站写成同一时间：这个字段就失去了参考意义，不如只对真正更新的分片做改动。
- 旧分片长期没人动：内容下线后分片仍指向 404 地址，成了无效入口。
- 频繁改名或换路径：每改一次，之前的入口就作废一次，历史提交记录也跟着断掉。
- 索引里塞外部地址：只有同一站点体系下的地址才适合放进索引。
索引文件解决的是“清单怎么组织”，不是“一定会被收录”。它让搜索蜘蛛更容易拿到一批可用地址，剩下的仍然取决于页面本身、内链结构和服务器稳定性。
一个够用的维护节奏
- 每月核对索引文件列出的分片是否都能正常访问，返回 200 且内容非空。
- 检查各分片的 URL 数量，接近上限时提前拆分。
- 内容下线时同步从分片移除，而不是把地址留在清单里。
- 抓取日志出现异常时，先确认最近的抓取集中在哪个分片，再决定优先修哪一块。
把分片当作站内目录结构的另一种映射，维护起来就不会太费劲：结构变了，分片跟着变；结构稳定，分片基本不用动。