Sitemap 用得久了，URL 数量迟早会超过单个文件能承载的范围。这时真正决定蜘蛛能不能稳定拿到清单的，不再是「有没有提交 Sitemap」，而是索引文件和分片组织得是否清楚。
为什么单个 Sitemap 迟早要拆
主流搜索引擎对单个 Sitemap 文件有明确上限：条目数不超过 5 万条，未压缩体积不超过 50MB。只要站点在持续增长，这两条线都会碰到。除了硬限制，拆分的实际意义还在于：
- 不同栏目更新频率差别很大，全站挤在一个文件里，每次都要重新生成、重新读取；
- 单个文件过大时，抓取和传输本身就会变慢，出错概率随之上升；
- 某一类内容出了问题，只需排查对应分片，不必全站返工。
拆分之后，需要一个 Sitemap 索引文件把各个分片串起来：蜘蛛先读索引，再按索引里的地址逐个取分片。
索引文件与分片的写法要点
索引文件只放分片地址
索引文件使用 sitemapindex 结构，每一项是 sitemap 标签，包含 loc 和可选的 lastmod，指向一个分片文件。常见错误是把 url 标签直接写进索引文件，或者把 sitemapindex 与 urlset 混在同一个文件里，这会让解析直接失败。
分片文件仍然是普通 Sitemap
每个分片本身是一个完整的 urlset，里面每一条 URL 才是真正要给蜘蛛的地址。分片地址应当是固定、能直接返回 200 的地址，不要带会变化的查询参数，也不要经过重定向。
lastmod 各管一段
分片里的 lastmod 描述的是某条 URL 的更新时间，索引文件里的 lastmod 描述的是这份分片清单本身的更新时间，两者含义不同。不要为了「看起来更新」每次都把全量时间改掉，时间戳长期不准，蜘蛛会逐渐降低对它的信任。
分片按什么维度切更实用
切分维度没有唯一答案，关键是让每一片内部的更新节奏相对一致，既方便维护，也方便蜘蛛按需取用：
- 按内容类型：文章、商品、分类、标签各成一片，出错时影响面可控；
- 按更新时间：新增或近期改动的 URL 单独成片，便于重点传递；
- 按语言或地区：多语言站点按目录切，避免互相干扰；
- 按数量均分：纯按 ID 或时间分段，适合超大规模站点，但每片数量别太悬殊。
单个分片控制在 1 万到 3 万条比较稳妥。数量太少会制造大量小文件请求，顶到上限则每次改动都要重写整个文件。
和 robots.txt、内链怎么配合
robots.txt 里用 Sitemap 指令指向索引文件即可，不必把每个分片都列出来，索引文件本身会把分片串起来。同时要记住，Sitemap 是补充手段，不是内链的替代品。一个写在 Sitemap 里、站内却没有任何入口的 URL，往往只能被零星抓取，很难形成稳定的抓取路径。清单和入口两条路都通，URL 才会被持续关注。
上线前的一份自查清单
- 索引文件能被直接访问，返回 200，Content-Type 为 XML 或纯文本；
- 分片地址未被 robots.txt 屏蔽，也不依赖登录或 Cookie；
- 索引文件里只有 sitemap 标签，分片里只有 url 标签；
- 所有 loc 使用完整绝对地址，且与实际可访问地址完全一致；
- 启用压缩传输时，确认服务端正确返回 gzip 编码，避免解压失败；
- 抽查若干分片，确认其中 URL 确实返回 200，而不是 404 或跳转。
索引和分片解决的是「清单怎么交」的问题；抓取顺序和频率，仍然由站点质量、内链结构和服务器响应决定。
把 URL 清单拆成结构清晰、各自独立更新的分片，并保持长期稳定，蜘蛛取用清单的成本会明显下降。剩下的功夫，还是要花在页面本身和内链上。