站点规模小的时候，一个 Sitemap 文件就能装下所有页面。但当 URL 数量到几万、几十万，或者不同栏目更新节奏差得很远时，继续把东西塞进一个文件，既写起来吃力，也不方便判断蜘蛛到底抓走了哪一批。这时候通常的做法是拆成多个 Sitemap，再用一个索引文件把它们串起来。

什么情况下该上索引文件

先记住两个硬限制：一个普通 Sitemap 文件最多放 5 万条 URL，未压缩体积不超过 50MB；索引文件本身同样最多引用 5 万个子 Sitemap。只要接近这些数字，就该拆分。

还有几种不靠数量也能判断的情况：

• 不同栏目更新频率差很多，日报类天天变，帮助文档几个月不动。
• 站点有多个语言或地区版本，URL 前缀不同。
• 商品、文章、专题等类型混在一起，生成逻辑本身就分开了。

分片按什么维度切

切分的核心原则是：一个分片内部的页面最好有共同特征。这样更新时可以整体重生成，也方便在日志里观察某一类的抓取情况。

按内容类型或栏目

例如文章、商品、分类、标签各一个文件。好处是同类页面的生成规则一致，出问题时影响面清楚。

按更新频率

把每天变的页面和几乎不变的页面分开。频繁变化的文件被反复抓取是正常的，稳定页面则没必要跟着一起更新，避免蜘蛛一次次拉取没有变化的大文件。

按语言或地区

多语言站点按语言拆分，配合 hreflang 使用时，索引关系更清楚，排查问题也不容易串线。

索引文件本身的几个要点

• 索引文件里只放子 Sitemap 的地址，不要混入普通页面 URL。
• 索引不能再套索引，官方格式不支持多层嵌套。
• 所有地址写完整绝对路径，包含协议和域名。
• 提交入口用索引文件本身，同时在 robots.txt 里声明它的位置。
• 子 Sitemap 的路径尽量稳定，不要每次生成都换文件名，否则等于让蜘蛛重新认识一遍。

常见写错的地方

• 全站 lastmod 填成同一个生成时间，时间字段就失去参考意义。
• 索引文件里挂着一个已经 404 的子文件，蜘蛛反复抓到错误地址。
• 分片命名带日期，每天换一个，历史文件还留在索引里。
• 子文件内容超限被截断，后面的 URL 压根没出现在文件里。
• URL 参数、编码处理不当，蜘蛛拿到的地址和真实地址对不上。

怎么验证分片真的起了作用

看抓取日志是最直接的办法。重点观察三件事：蜘蛛对各个子 Sitemap 的抓取频率、返回状态码是否正常、以及抓完 Sitemap 之后有没有出现对应的详情页抓取。如果某个分片长期被抓但里面页面的抓取量没有变化，就要检查这个分片里的 URL 是不是本身有问题，比如被 robots 屏蔽、返回 404、或者与其他分片重复。

需要说明的是，Sitemap 只是 URL 发现渠道之一，提交和抓取都不等于收录。它解决的是“让蜘蛛知道有这个地址”，能否被索引还要看内容质量、重复度和站点整体情况。

和其他发现渠道怎么配合

Sitemap 不该被当成唯一手段。新页面上线时，从栏目页、相关文章、面包屑等位置给出内链，通常比等 Sitemap 被重新抓取更快被发现。日常运营里更稳的组合是：内链负责主干路径，Sitemap 负责兜底和全量覆盖。

另外，无论分片写得多规范，服务器不稳定都会让发现效率打折。抓取过程中频繁超时或返回 5xx，蜘蛛会降低访问频率，Sitemap 抓取也会被拖慢。所以分片、内链、服务器响应速度这几件事，通常是放在一起看的，单独优化其中一项，收益往往有限。

小结

页面规模上来之后，把 Sitemap 分片并用索引文件汇总，能让你更清楚地掌握蜘蛛分批发现 URL 的过程。切分维度按内容类型、更新频率或语言来选，索引文件只放子文件地址并保持路径稳定，然后通过日志确认每一批 URL 是否真的被带走。做到这一步，URL 发现这件事就从“提交完等结果”变成了可以观察和调整的日常动作。