当一个站点的 URL 从几百条涨到几万条，单个 Sitemap 文件很快就不够用了。这时候真正影响 URL 发现的，往往不是“有没有提交 Sitemap”，而是这份清单被拆成了什么样、放在哪里、蜘蛛能不能顺畅地一个个读完。

先看清单文件的两个硬上限

主流搜索引擎对单个 Sitemap 文件有两个限制：URL 条数不超过 50,000 条，未压缩体积不超过 50MB。任意一条触顶，超出的部分就会被忽略，而不是报错提示你。所以当 URL 规模接近上限时，继续往同一个文件里追加内容，等于把后面的地址直接丢掉。

另外还有一条容易被忽略的：同一个目录下的文件数量、生成耗时、传输体积，都会影响服务器在蜘蛛集中请求时的响应表现。

Sitemap 索引文件解决的是什么问题

Sitemap 索引（Sitemap index）本身不是 URL 清单，它只是一份“清单的清单”，里面列出若干个 Sitemap 文件的地址和最后修改时间。蜘蛛先取索引，再按索引去取各个子文件。

它带来的实际变化有三点：

• 单个文件的容量压力被分散，不会因为一个文件超限而整体失效；
• 可以按内容类型分别提交，某个分片出错不影响其他分片；
• 更新频率高的分片可以频繁重建，低频分片保持不动，减少生成开销。

分片怎么切才合理

切分逻辑没有唯一答案，但要避免两种极端：切得太碎（几百个只有几十条 URL 的文件）会增加蜘蛛的请求次数；切得太大又回到容量问题。常见的做法是按内容类型和更新节奏来分：

• 按内容类型：文章、商品、分类、专题各一个分片，便于单独观察抓取覆盖情况；
• 按更新频率：每日更新的内容放一个分片，长期稳定的页面放另一个分片；
• 按语言或地区：多地区站点按目录或子域拆分，避免混在一起互相干扰。

每个分片保持在几千到两三万条之间比较从容，既留有余量，也不会让索引文件指向过多的子文件。

索引文件本身的写法

索引文件里每一条记录包含子 Sitemap 的地址和 lastmod。这里的 lastmod 指的是该文件内容的最后修改时间，不是里面某一条 URL 的修改时间。时间戳频繁跳动而内容没变，会让蜘蛛对这个字段的参考价值打折。

索引文件的地址通常放在 robots.txt 的 Sitemap 行里，而且这里只需要写索引地址，不必把每个子文件都列一遍。重复列出反而容易让人误以为有多个入口。

分片之后容易踩的坑

• 分片里的失效 URL 不清理：已经 404 或 301 的地址长期留在 Sitemap 里，会持续消耗抓取请求；
• 新旧分片同时存在：改版后生成了新文件却忘了移除旧文件的引用，蜘蛛会抓到两份重复清单；
• 子文件动态生成太慢：每次请求都要查全表，蜘蛛并发取几个分片时，响应时间就会明显上升；
• 把参数页、筛选页全塞进去：这类地址数量容易失控，把真正需要发现的页面挤到后面。

比较稳妥的做法是让 Sitemap 文件静态化或加缓存，把生成过程与线上请求解耦，保证蜘蛛取文件时的响应稳定。

索引不是唯一入口

即使 Sitemap 拆分得再整齐，它也只是 URL 发现的辅助通道。蜘蛛的主要路径仍然是链接：从首页、栏目页、相关推荐一步步走到目标页。Sitemap 能告诉蜘蛛“这些地址存在”，但一个页面在站内没有任何内链指向它，被抓取和评估的机会依然有限。

所以拆分 Sitemap 的同时，值得同步检查一件事：这些分片里有多少 URL 是站内链接可以走到的。两者差得越远，说明站点结构还有补的空间。

一个简单的自查清单

1. 索引文件里的子 Sitemap 地址是否都能正常返回 200，且返回的是 XML；
2. 每个子文件的条数是否远离 50,000 上限，体积是否远离 50MB；
3. 索引和子文件里的 lastmod 是否和真实修改时间对得上；
4. robots.txt 中引用的 Sitemap 是否为索引地址，且只出现一次；
5. 分片中是否混入了参数页、已删除页、其他站点镜像的地址；
6. 蜘蛛集中抓取这些文件时，服务器响应时间是否仍在正常范围。

Sitemap 分片的本质，是把一份长长的清单变成一份可维护的清单。它不会让页面自动被收录，但能让蜘蛛少走冤枉路，把抓取时间花在真正值得读的地址上。