站点还小的时候，一个 sitemap.xml 就够用；当 URL 数量涨到几万甚至几十万，单份文件就会撞上大小和条数的上限。蜘蛛每次取回的只是其中一段，剩下的 URL 迟迟进不了发现队列。这时候要做的不是把文件写得更长，而是把它拆成一张索引加多个分片。

先搞清楚上限在哪

主流搜索引擎对单份 Sitemap 有两条硬限制：文件体积（未压缩前一般在 50MB 量级）和 URL 条数（一般 5 万条）。两者任意一条超了，超出部分就不会被读取——注意是不会读取，不是报错。很多站点以为自己提交了全量地图，其实后面的内容从第一天起就没被看到。

压缩成 .gz 可以绕过体积问题，但条数上限绕不过去。所以 URL 上万之后，分片就是必选项。

sitemap index：一张总目录

索引文件本身也是一份 Sitemap，只是里面列的不是页面 URL，而是各个分片文件的地址。它放在站点根目录下比较自然，例如 /sitemap_index.xml。结构上每个分片用一个 sitemap 标签包裹，可以带上该分片自己的 lastmod。

几个容易踩的点：

• 索引文件同样受体积和条数限制，分片数量别失控，几百个通常已经很多了。
• robots.txt 里只需要声明索引文件这一条 Sitemap 指令，不用把每个分片都写进去。
• 索引里引用的分片必须真实可访问、返回 200，否则蜘蛛会跳过，甚至降低对整份地图的信任。

分片按什么维度切

切法没有唯一答案，但最好让每个分片有清晰的含义，方便日后定位问题：

• 按栏目或内容类型：商品、文章、专题各自一份，出问题时能快速缩小范围。
• 按更新时间滚动：单独留一份“最近更新”分片，只放近段时间有变动的 URL，方便蜘蛛优先回访。
• 按语言或地区目录：多语言站点按目录切，和 hreflang 的划分保持一致。

实际使用中常见的是混合策略：主力分片按栏目拆，再加一份时间维度的小分片承载新内容。

哪些 URL 不该放进分片

地图里塞的每一类无效 URL，都在消耗蜘蛛有限的抓取机会：

• 带筛选参数、排序参数产生的变体页面。
• 已经设置 noindex、被 robots.txt 屏蔽的地址。
• 会 301/302 跳走的旧 URL，直接写最终地址即可。
• 返回 404 或内容空壳的软 404 页面。
• 需要登录才能看到的页面。

把这些清掉，地图整体的“命中率”会好看很多。

维护时的几个细节

lastmod 要写真实修改时间。如果每次生成地图都把所有分片的时间刷成当前时刻，这个字段就失去了参考价值。分片内部的 lastmod 保持真实，分片本身的 lastmod 取该批页面里最新的一个即可。

分片之间不要互相重复。同一个 URL 出现在多份分片里不会带来额外好处，反而让统计口径变乱。

生成过程要稳定。地图是静态文件的话，尽量在发布流程里一次性写好，避免出现半截文件或者某次发布后分片全部缺失。

地图解决的是“蜘蛛能不能发现这个 URL”，它不决定页面值不值得被展示，也不替代站内链接。

地图是补充，不是主路径

蜘蛛在站内的主要移动方式仍然是跟随链接。Sitemap 的作用更像一份候补名单：内链走不到的角落页面，可以靠它被发现。所以不要因为有了地图，就放松导航、面包屑和列表页的铺设。

上线后的检查与观察

1. 用浏览器和命令行分别访问索引文件与每个分片，确认返回 200、内容类型正确、没有被 CDN 或 WAF 拦下。
2. 在 robots.txt 中确认只声明了索引文件，且路径与实际一致。
3. 提交后等一段时间，从服务器日志里看蜘蛛访问各分片的频率，判断哪部分被优先处理。
4. 在 Search Console 的 Sitemap 报告里核对“已发现 URL 数”和站点实际 URL 数的差距，差得多说明有分片没被读到。
5. 定期清理分片里的失效地址，尤其是做过分页或下架内容之后。

站点规模越大，地图越像一份需要长期维护的清单，而不是一次性任务。把它切清楚、保持干净，蜘蛛的 URL 发现过程才会顺畅一些。