当站点 URL 数量达到一定规模，单个 Sitemap 往往放不下，或者虽然放得下，但每次更新都要重新生成整个文件。这时 Sitemap 索引文件（Sitemap index）就派上用场：它本身不列具体页面，只列出多个子 Sitemap 的地址，让蜘蛛按图索骥地去找。

什么时候需要拆出索引文件

常见触发条件有三个：一是 URL 总数超过单个 Sitemap 的上限，二是站点分多个栏目、语言或地区，更新节奏差异大，三是希望把不同类型的 URL 分开观察抓取情况。如果站点只有几百个页面，一个普通 Sitemap 就够了，不必为了形式而套索引。

拆分子地图的几个常用维度

按栏目或内容类型

文章、商品、分类、标签各自一个子地图，优点是定位清晰，某个栏目抓取异常时容易排查。缺点是子地图数量可能很多，索引文件会变长。

按更新时间

把最近更新的 URL 单独放在一个子地图里，其余归档到历史地图。这样蜘蛛抓取近期地图时能更快看到新内容，适合更新频繁的站点。但要注意 lastmod 必须真实，不要为了催促抓取而批量改成当前时间。

按语言或地区

多语言站点可以按语言拆分子地图，再配合 hreflang 使用。拆分后每个子地图只包含同一种语言的 URL，便于验证覆盖情况。

索引文件本身的写法要点

• 索引文件只放子 Sitemap 的 loc，以及可选的 lastmod，不要直接放页面 URL。
• 不能嵌套索引，即索引文件里不能再指向另一个索引文件。
• 所有子地图必须与索引文件同域，不能跨域引用。
• 压缩成 gzip 时，要确保服务器返回正确的 Content-Type，并让文件可公开访问。
• 子地图的数量和单个文件大小都要在协议限制内，不要只关注 URL 条数。

索引文件的作用是告诉蜘蛛去哪里找，不是让蜘蛛必须抓。它解决的是发现效率，不解决内容质量与服务器稳定性。

提交与验证

1. 在 robots.txt 中写一行 Sitemap 指令，指向索引文件的绝对地址，而不是某个子地图。
2. 在搜索资源平台提交索引文件，观察子地图是否被陆续抓取。
3. 查看服务器日志，确认蜘蛛请求的是索引文件还是子地图，状态码是否为 200。
4. 定期检查索引里的每个子地图，避免出现 404、403 或返回 HTML 错误页的情况。
5. 对比子地图中的 URL 与实际可访问 URL，剔除已下线或重定向的地址。

常见问题与排查方向

• 子地图 404：索引文件更新了，但旧子地图被删除，蜘蛛仍按旧地址来抓。保留一段时间或做 301。
• lastmod 失真：所有 URL 的 lastmod 都一样，蜘蛛会降低对该字段的信任，反而影响判断。
• 索引文件过大：子地图太多导致索引本身超限，应合并低频子地图或按时间归档。
• 只提交不维护：Sitemap 是动态资产，站点改版、栏目调整后要同步更新。

把 Sitemap 索引文件当作 URL 发现的基础设施，而不是一次性任务。结构清晰、更新真实、可稳定访问，蜘蛛才更有可能按你安排的路径去走。蜘蛛池、主动推送等手段可以作补充，但不能替代内链、服务器响应和内容本身。