Sitemap 在只有几百个 URL 的时候很简单，一个文件交上去就行。但当站点做到几万、几十万条页面时，单份文件的容量和蜘蛛的读取体验都会变成问题，这时候通常要拆成多份分片，再用一个索引文件把它们串起来。

为什么单份 Sitemap 不够用

协议对单个 Sitemap 文件有明确上限，超出的部分不会被读取，等于白交上去：

• URL 数量：一份文件不超过 5 万条；
• 文件体积：未压缩状态下不超过 50MB；
• 一份文件出问题（比如生成失败、返回 500），整份清单的可信度都会受影响。

除此之外，一个体积很大的 XML 文件对蜘蛛来说也是读取负担：它需要完整下载、解析，才能拿到里面的地址。拆小之后，蜘蛛可以按片读取，某一片暂时不需要更新时，其他片仍然正常。

索引文件不是清单，是目录

索引文件（sitemapindex）本身不包含页面 URL，它只列出各个子 Sitemap 的地址，每个子文件带一个 lastmod。写的时候注意几点：

• 索引里只放子 Sitemap 的地址，不要把页面 URL 混进去；
• 子文件必须和索引文件在同一个站点域名下；
• 每个子文件的地址要能直接访问并返回 200，且内容确实是 XML。

常见的做法是：索引文件固定在 /sitemap.xml 这个位置，子文件放在同一目录或独立目录下，命名上能看出这一片装的是什么内容。

分片的三种常见切法

• 按栏目或内容类型切：文章、商品、专题、帮助文档各自一片，排查问题时定位快；
• 按时间切：当月或当季一片，历史内容归档成较大的片，更新集中在少数几片上；
• 按数量切：每片 1 万到 2 万条，给增长留出余量，避免某天突然触顶。

切法没有标准答案，判断标准是运维和排查是否方便。当一个子文件报错时，能不能一眼看出影响的是哪一块内容。

容易踩的几个坑

• 子文件 404 或返回 HTML：服务器把错误页当成 200 返回，蜘蛛拿到一堆 HTML，这片清单就废了；
• 更新不同步：新 URL 加进了子文件，但索引文件里对应的 lastmod 没变，蜘蛛可能认为这一片整体没有变化；
• 体积按未压缩算：gzip 之后看着很小，但限制通常以未压缩体积衡量；
• 塞进不该出现的地址：带筛选参数的列表页、需要登录的页面、同一内容的多条规范化地址，都会稀释这份清单的价值。

Sitemap 表达的是这里有这些 URL，并不等于要求蜘蛛必须抓取。它替代不了站内链接结构，只能作为清单的补充。

提交之后怎么判断有没有生效

清单交上去只是第一步，接下来要看真实请求：

1. 日志里子 Sitemap 文件是否被请求、请求频率如何、返回码是不是 200；
2. 新 URL 从出现在 Sitemap 到第一次被抓取，中间隔了多久；
3. 抓取是否集中在某几片，另外几片长期无人问津。

如果长期没有变化，先排查 robots.txt 是否误挡了 Sitemap 目录，再确认索引文件本身可访问、服务器没有间歇性超时。清单再规范，也依赖一个能稳定返回内容的服务器。

小结

分片加索引解决的是清单规模变大之后怎么让蜘蛛读得完、读得准的问题。把上限记牢、把切法定清楚、让索引和子文件的更新保持同步，比一次性堆一个巨大的 XML 文件要稳妥得多。