当站点 URL 数量到几万甚至几十万时，单个 Sitemap 文件已经放不下，通常的做法是拆成多个子文件，再用一个索引文件（sitemapindex）把它们串起来。这一步做得好不好，会直接影响蜘蛛从 Sitemap 这条路径上能发现多少 URL。
先弄清几个硬性边界
- 单个 Sitemap 文件：URL 数量上限 50000 条，未压缩体积不超过 50MB
- 索引文件：指向的子文件数量上限 50000 个，体积同样有上限
- 索引文件里不能再嵌套索引文件，只能指向普通 Sitemap
- 所有 URL 必须是同一域名（或已在站长平台验证的同一站点）下的完整绝对地址
- 不支持相对路径，也不支持跨域名混放
这些边界不是建议值，超出后文件会被判定为无效。
分片按什么维度切
分片方式没有唯一答案，但要考虑一个前提：同一分片里的内容，更新节奏是否一致。
- 按内容类型：文章、商品、分类、标签页各成一片，便于单独排查
- 按更新频率：高频更新的内容单独一片，可以配合更短的复查周期
- 按语言或地区：多语言站点按目录拆分，与 hreflang 结构对齐
- 按时间：新增内容按月分片，老内容归档成固定片，减少整体变动
避免按随机平均的方式分片，那样每次更新都会让几乎所有分片的指纹发生变化，反而不利于稳定抓取。
lastmod 要写得诚实
蜘蛛在安排抓取时会参考 lastmod，但它不会盲信。如果每个分片、每条 URL 的 lastmod 都写成当天，这个信号很快会被当作噪音处理，参考价值下降。
与其让所有 URL 都显示刚刚更新，不如只标记真实改动过的页面。
建议使用带时区的时间格式，例如 2024-06-01T08:30:00+08:00。精度到秒或分钟都可以，但不要出现未来时间。
索引文件放哪里、怎么声明
索引文件一般放在站点根目录，例如 /sitemap.xml，子文件放在 /sitemap/ 目录下。声明入口通常有两个：
- robots.txt 中用 Sitemap 行指向索引文件的完整地址
- 站长平台里手动提交
只需要声明索引文件，不必把每个子文件的地址都写进 robots.txt，蜘蛛会顺着索引文件自己去取子文件。这里有一个常见矛盾：文件提交了，但存放目录被 Disallow 规则挡住，蜘蛛取不到，等于白交。
取不到分片时的排查顺序
- 用日志筛选 Sitemap 相关请求，看状态码是 200、404 还是 403、500
- 确认服务器对 .xml.gz 的 Content-Type 与 gzip 压缩处理正常
- 检查索引文件里的子文件地址是否写错、是否误用了相对路径
- 确认 robots.txt 没有把 sitemap 目录屏蔽
- 频繁出现 304 属正常现象，说明蜘蛛在按缓存策略做校验
如果日志里几乎看不到对子文件的请求，说明索引文件可能没被解析成功，优先回头检查索引文件本身的格式。
Sitemap 不能替代内链
Sitemap 解决的是存在哪些 URL，内链解决的是这些 URL 有多重要、从哪个入口进入。两者分工不同。新页面既要有可被抓取的链接入口，也可以出现在 Sitemap 中；只靠 Sitemap 而没有内链的页面，被发现之后往往抓取优先级也不高。
分片数量不必刻意追求精简
有人为了看起来干净，把几十万 URL 挤进少数几个分片，结果单文件逼近体积上限，响应变慢，反而影响蜘蛛取用。更稳妥的做法是按内容节奏拆分，让每个文件保持在可控大小，通常几万条以内、压缩后几百 KB 到几 MB 比较合适。
定期用日志和站长工具核对三件事：索引文件是否可访问、子文件是否被实际抓取、lastmod 是否真实反映改动。这些基础工作做扎实，Sitemap 在 URL 发现中的价值才稳定。