站点刚上线时，一份 Sitemap 往往只有几十条 URL，随手写完就行。等到栏目铺开、商品或文章累积到几千上万条，同一个文件会变得又大又难维护，蜘蛛读取时也容易在中间被打断。这时要考虑的不是再写一份更大的文件，而是把申报结构拆开，用索引文件把它组织起来。
什么规模适合上索引文件
单个 Sitemap 文件有约定俗成的上限：通常不超过 5 万条 URL、未压缩体积不超过 50MB。实际使用建议留出余量，比如到两三万条就开始规划拆分。判断依据不只是条数，还包括下面几点：
- 更新节奏差异大：新闻栏目每天在变，产品页几周不动，混在一起不利于频繁重新生成。
- 由不同系统生成：CMS、商城、论坛各自输出，硬拼成一个文件容易出错。
- 需要单独观察：某一类 URL 的抓取情况想分开看，就必须分开申报。
只要满足其中一条，用 Sitemap 索引把多个子文件串起来，申报和排错都会轻松一些。
分片的几种实用切法
- 按目录切：栏目各自一个文件，与站内结构对齐，出问题时容易定位到具体栏目。
- 按内容类型切：文章、商品、专题、图片或视频各成一路，方便对比不同类型的抓取结果。
- 按更新时间切：活跃内容与沉淀内容分开，活跃文件可以频繁重新生成和提交。
- 按语言或地区切：多语言站点除了 hreflang，申报通道也分开会更清晰。
切法不必追求唯一正确，关键是稳定。分片规则频繁变动，等于让蜘蛛反复重新认识你的申报结构。
文件层面的细节
- 每个子文件都是完整的 urlset 结构，索引文件用 sitemapindex 结构，两者不要混着写。
- 地址一律用绝对 URL，且指向最终可访问的规范形态，不要写成会跳转的地址。
- 只放值得被发现的页面，登录页、站内结果页、带大量参数的筛选页不要塞进来。
- lastmod 写内容真正发生变化的时间，不要每次生成都刷新成当前时间。
- 大文件可以压缩后再提交，但索引文件里要写压缩后的那份地址。
索引文件要和内链、robots 对得上
Sitemap 负责申报，内链负责背书，两者的口径要一致。索引里列出的子文件，应该能被 robots.txt 声明到，或者直接提交到站长平台；而子文件里的 URL，最好在站内也有能走到的入口。如果某个分片里的地址几乎都是孤儿页，申报出去也未必走得通。
把 Sitemap 当作“建议你先看这些”，而不是“必须收录这些”。它影响的是发现顺序和排队节奏，并不决定最终结果。
几个常见坑
- 分片之间互相引用，或者索引文件指回自己，形成循环。
- 子文件已经返回 404 或 500，却长期留在索引里，拖累整份申报的可信度。
- 提交后从不看数据，不知道哪一片抓得多、哪一片没动静。
- 把生成的 URL 数量当成被抓取、被收录的数量，忽略了这是两件事。
一套简单的巡检节奏
不必天天盯，固定一个周期做三件事就够：
- 检查每个子文件的可访问性和状态码，确认没有死链。
- 核对索引里列出的分片数量与实际生成是否一致，避免漏掉某一类内容。
- 对照服务器日志，看蜘蛛实际读到了哪些分片、跳过了哪些，再决定要不要调整切分方式。
URL 规模变大之后，申报结构本身就是一份站内地图。把它整理清楚，不只是方便蜘蛛，也方便你自己在出问题时快速定位到具体是哪一类地址出了状况。