Sitemap 从几十条 URL 涨到几万条之后，问题往往不再是“要不要提交”，而是“怎么切”。一个文件塞不下，或者说塞得下但每次更新都要整份重写，这时候就需要用到 sitemap 索引文件。它本身不列具体页面，只列出若干个子 sitemap 的位置，蜘蛛先读索引，再按需去读各个分片。

先记住两个硬上限

无论是普通 sitemap 还是索引文件，都有一个通行的规模上限：单个文件最多 50000 条 URL，未压缩体积不超过 50MB。索引文件里最多放 1000 个子 sitemap。这些数字不是建议值，超过之后文件很可能被直接判为不可用，蜘蛛读到的就是一份残缺甚至完全无效的清单。

按上限推算，一个索引文件理论上能覆盖 5000 万条 URL。对绝大多数站点来说，真正的瓶颈不是这个总数，而是每次更新时要动多少文件。

按什么维度切片更省事

切片的维度决定了后续维护的成本，常见的三种：

• 按内容类型：文章、商品、专题、标签页各成一片。结构清晰，某一类出问题时容易定位。
• 按业务板块或目录：与站内 URL 层级基本对齐，改版时改动范围可预期。
• 按更新时间滚动：比如按月份或按周分片，新片只放新增和更新的 URL，老片基本不动。

第三种对蜘蛛比较友好：更新频繁的 URL 集中在一个小文件里，蜘蛛重访时只需要拿这一小份，不必重新拉取整个大文件。第一种和第二种更适合做全量底稿，再配合一个只含近期更新的小分片。

分片数量不是越多越好

每多一个分片，就多一次独立的抓取请求，多一份需要维护的文件。片数太少，单文件体积大、更新代价高；片数太多，索引文件变长，蜘蛛在索引和分片之间来回跳转的开销也会上升。一个折中的做法是把数量控制在几十到几百片之间，并且让每片的大小相对均匀，避免出现一个几万条、另一个只有几十条的极端情况。

分片本身不会带来抓取量，它只是把 URL 线索整理得更清楚。真正影响蜘蛛是否来访的，是站点的整体质量、更新节奏和服务器响应。

索引文件里的 lastmod 与更新顺序

索引文件中的每个子 sitemap 也可以带 lastmod。这个时间应当反映该分片内容的实际变动时间，而不是部署时间或生成脚本的运行时间。如果每次发布都把所有分片的 lastmod 刷成同一时刻，那些其实没变的分片会被反复标记为有更新，蜘蛛白跑一趟，久了反而降低对该文件的信任。

排序上，把更新最频繁、最希望被优先发现的分片放在前面，是一个低成本的习惯。它不改变抓取总量，但能在蜘蛛只读了一部分索引时，让重要的线索先被看到。

落地时容易忽略的几点

1. 索引文件和子 sitemap 都要在 robots.txt 里声明，或者提交到搜索平台的站长工具里，通常只声明索引文件即可，不必逐个列出子文件。
2. 索引中的 URL 必须是绝对地址，且能被正常访问，不要出现重定向到另一个域的情况。
3. 子 sitemap 里只放返回 200、可索引的页面，把 404、软 404、需要登录或带大量参数的页面剔除，否则等于把无效线索递给蜘蛛。
4. 删除分片时同步从索引文件里移除，别留一个指向 404 的空壳。
5. 生成脚本失败要有告警，一份空的 sitemap 被提交上去，比不提交更糟。

和服务器稳定性配合看

分片拆得再合理，如果蜘蛛来取文件时服务器频繁超时或返回 5xx，它拿到的仍是不完整的数据。尤其是索引文件，一旦读取失败，后续分片基本不会被触发。把 sitemap 的访问日志单独拉出来看响应码和响应时间，是判断“究竟是文件写得不对，还是服务器没扛住”的比较直接的办法。

归根结底，分片策略要回答的是一个问题：当你只想让蜘蛛看一小部分文件时，能不能精准地把那部分挑出来。能做到这一点，索引文件才算用对了。