Sitemap 是给搜索蜘蛛的一份候选清单，但它的作用不止于列 URL。当站点规模上万以后，单个文件很快就会撞上协议规定的上限，分片和索引文件就成了必须处理的结构问题。组织得好，抓取能顺着清单较快铺开；组织得乱，蜘蛛拿到的是过期、重复、甚至指向错误地址的入口，反而拖慢 URL 发现。

单文件的硬性上限

协议对 Sitemap 文件有明确约束，超过就得切分：

• 单个文件最多 50000 条 URL；
• 未压缩体积不超过 50MB；
• 只能是同一个域名（含协议与端口）下的 URL；
• 建议 gzip 压缩后传输，减少带宽与读取耗时。

很多站点不是败在数量上，而是败在体积上：一页塞进几万条带参数的长 URL，未压缩体积先超了，蜘蛛读到一半就中断。

索引文件：只列分片，不列内容

Sitemap 索引文件本身不包含具体 URL，它只指向其他 Sitemap 文件，最多 50000 个分片，同样受 50MB 限制。常见错误是把索引文件当普通 Sitemap 提交，里面混写了页面地址，结果蜘蛛按分片规则解析失败，整份清单被跳过。

分片粒度怎么切

切分方式直接影响回访效率。比较实用的做法是按更新节奏分组，而不是按数量硬切：

• 高频更新的栏目单独成片，蜘蛛回访时只需要重新拉这一小份；
• 历史归档、低频内容合并成大片，控制文件数量；
• 内容类型差异大的（商品、文章、标签页）分开，便于单独观察抓取效果；
• 分页与筛选参数页通常不该出现在清单里，避免稀释清单的有效性。

提交渠道与发现路径

索引文件要被发现，需要显式入口。robots.txt 里的 Sitemap 指令是最稳定的一条，写完整的绝对地址，包含协议。后台提交属于辅助手段，不能替代 robots.txt 中的声明。过去流行的主动 ping 接口已逐步关闭，不建议再把它当作推动抓取的主要方式。

清单只是候选，不是抓取保证。蜘蛛仍会按自身策略决定抓什么、抓多少，提交后没有任何数量上的承诺。

核对顺序：提交与抓取能不能对上

发现抓取量长期低于预期时，按下面的顺序排查，能省掉很多来回：

1. 直接访问索引文件地址，确认返回 200 且内容是 XML；
2. 确认索引中的每个分片地址都能打开，没有 404、301 或登录跳转；
3. 抽查分片内的 URL，状态码正常、canonical 指向自身、不存在重复；
4. 核对 robots.txt 是否误屏蔽了 Sitemap 路径或其中涉及的目录；
5. 对比分片条数与站点实际可索引页面数，差距过大说明分片内容陈旧；
6. 观察日志中蜘蛛对 Sitemap 文件的抓取频率，长期不抓说明入口没被识别。

三类常见偏差

lastmod 全站同一天。批量生成时把时间戳统一写成当前时间，蜘蛛很快会判定该字段不可信，之后即使内容真的更新，也不再提高回访优先级。

分片内容与实际页面脱节。页面已下线、改版换了路径，但分片还在推旧地址，蜘蛛拿到的是无效入口，等于用抓取投入去换 404。

索引层级套太多。索引指向索引、再指向分片，解析链路变长，出错概率上升。一层索引加一层分片基本够用。

把 Sitemap 当作需要长期维护的结构，而不是上线时生成一次的产物。分片跟着内容节奏走，索引保持简洁，入口声明放在 robots.txt 里，剩下的交给抓取策略本身去消化。