站点规模一大，单个 Sitemap 文件就不够用了。几万个 URL 塞不进一个文件，硬塞的后果是文件超限被忽略，蜘蛛一个 URL 也读不到。这时候需要的是站点地图索引（sitemapindex）加多个分片文件的组合，把一个巨大的清单拆成若干份，分批交付给蜘蛛。
先弄清容量边界
Sitemap 协议对单个文件有明确限制，超出了就不会被正常解析：
- 单个 Sitemap 文件最多包含 50,000 条 URL。
- 单个文件未压缩时不超过 50MB。
- 一个索引文件里最多可以列出 50,000 个 Sitemap 文件。
也就是说，五万条 URL 是单文件的天花板。很多站点的真实体量远不止这个数，尤其是带参数的商品页、论坛帖子、文档版本页。
索引文件做什么
索引文件本身不列 URL，它列的是一份份子 Sitemap 的地址。蜘蛛读索引，再按需去读各个分片，这样就绕开了单文件的容量限制。
做法上，根目录放一个 sitemap.xml 作为索引，子分片可以命名为 sitemap-1.xml、sitemap-2.xml，或按内容命名，例如 sitemap-article.xml、sitemap-product.xml。索引只负责指路，真正的内容在分片里。
需要注意的是，索引文件里只能出现 Sitemap 地址，不能混入普通页面 URL；分片文件里则只能出现页面 URL。两者层级不要写反，也不要让分片再指向分片，嵌套过深会让蜘蛛半路放弃。
分片怎么切比较合理
切法不止一种，选哪种取决于你希望蜘蛛按什么顺序读：
- 按栏目或内容类型切：文章、商品、分类各一份。适合希望蜘蛛优先补齐某一类内容的站点。
- 按更新时间切：把近期更新的 URL 放在单独一份里。适合需要频繁推送新内容的站点。
- 按语言或地区切：多语言站点用这种方式能减少无关 URL 的干扰。
- 按数量均分：最简单，但对抓取优先级没有引导作用。
实际运营中，常见的组合是「按类型切 + 近期更新单独一份」，既方便观察，也方便在需要时单独调整某个分片的提交。
lastmod 别乱写
lastmod 是给蜘蛛判断「这个 URL 有没有变过」的重要线索。它的价值建立在真实之上。如果全站几万个 URL 的 lastmod 都是同一个时间戳，或者每次都自动刷成当天，这个字段基本就失去了参考意义，还可能让蜘蛛对整份清单的可信度打折扣。
只在你确实修改了页面正文、价格、库存等实质内容时更新 lastmod。模板改版、页脚换文案这类不影响主体信息的改动，不必整站刷新时间。
几个常见错误
- 索引里写的分片地址返回 404 或 302，蜘蛛读索引时就直接断了。
- 分片文件本身被 robots.txt 的 Disallow 规则挡住，索引能读、内容读不到。
- 索引文件用了 gzip 之外的压缩格式，或压缩后仍然超限。
- 把站内搜索结果页、筛选参数页大量塞进分片，清单虚胖，真正重要的页面反被稀释。
- 分片更新后浏览器能访问，但服务端返回的 Content-Type 不是 XML，解析失败。
提交之后的观察方法
把索引文件地址写进 robots.txt 的 Sitemap 指令，同时在搜索后台提交一次即可，不必每天重复提交。之后要看的是三件事：分片文件的抓取日志有没有出现、返回码是不是 200、清单里的 URL 有多少进入了已抓取状态。
如果某个分片长期没有抓取记录，先自查它的地址是否可达、是否被规则挡住，再考虑把它拆小。分片过大、单份动辄几万条，蜘蛛分次读取的周期会更长，把大分片拆成几份反而更容易被陆续读完。
一句话收尾
Sitemap 索引和分片解决的是「交付方式」问题：让蜘蛛能用更少的请求、更清楚的层级，分批拿到你要它知道的 URL。它不保证收录，也不能替代内链结构——没有内链支撑的页面，即便写进清单，抓取后的处理依然可能悬在半空。