不少站点的 URL 早就不止五万条，提交 sitemap 时才发现文件生成失败、上传被拒，或者报告里只识别了一部分。问题往往不在搜索引擎，而在 sitemap 的格式硬性限制，以及事先没有想清楚“哪些 URL 值得放进去”。
先记住三条硬性上限
- 单个 sitemap 文件最多包含 50,000 个 URL。
- 单个文件未压缩不超过 50MB，即使上传 .gz 压缩包，也按解压后的体积计算。
- 单个 sitemap 索引文件最多列出 50,000 个子文件，并且索引文件不支持再嵌套索引文件。
超过其中任意一条，文件就可能失效或被截断。URL 数量到几十万时，分片基本是必选项。
分片怎么切，比切多少更重要
分片不是把列表按每五万条砍一刀就完事。文件怎么划分，决定了以后排查问题的效率。
- 按目录或内容类型：文章、商品、标签页各用一个文件，某一类收录异常时能立刻定位。
- 按更新时间：把近期有改动的页面单独成片，便于观察更新是否带来重新抓取。
- 按语言或地区：多语言站点按子目录划分，避免混在一起难以核对。
- 按业务优先级：真正希望被索引的栏目单独放，次要页面另作处理。
不推荐“每五万条随机切一刀”的切法，文件之间没有语义差别，出问题时只能整批重跑。
索引文件怎么写
分片之后需要一个 sitemap 索引文件指向各个子文件，内容形如 sitemap-article-1.xml、sitemap-article-2.xml 的列表。有几点常被忽略：
- 索引里的地址必须是完整 URL，并与子文件的真实路径一致，包括是否带 .gz 后缀。
- 子文件必须与索引文件处于同级或更下一级目录，不能指向上级目录中的页面。
- 索引文件不能再套索引文件，想“分层管理”的做法在这里行不通。
- 在 robots.txt 里可以写多行 Sitemap，但一般只需写索引文件这一条，不必把每个子文件都列出来。
哪些 URL 不该放进 sitemap
分片只解决“放不下”，解决不了“放错了”。下面这些地址放进 sitemap，通常只会稀释信号、干扰自己的判断：
- 返回 301 或 302 的地址，应直接写跳转后的目标地址。
- 被 robots.txt 屏蔽或带 noindex 的页面。
- canonical 指向其他页面的重复地址，只保留规范版本。
- 返回 404 或 410 的历史路径，以及由参数组合生成的大量筛选页。
- 需要登录才能访问、站内搜索结果等对搜索引擎没有意义的页面。
sitemap 只解决“被发现”，不解决“被收录”。把不该索引的地址塞进去，反而会让人误判真实的收录情况。
分片之后的自查顺序
- 在浏览器中直接打开索引文件和每个子文件，确认返回 200、无需登录、没有被防火墙拦截。
- 检查文件是否声明了正确的命名空间与编码，带中文的 URL 是否做了规范的百分号编码。
- 抽查若干条 URL，确认返回 200 且 canonical 指向自身，而不是指向别处。
- 对照 sitemap 报告里“已提交”与“已编入索引”的数量差距，再结合日志看抓取频次是否匹配。
- 如果某一分片的收录表现明显低于其他分片，先检查该分片里是否混入了上面提到的不该提交的 URL。
还有一点：文件里的 lastmod 不要每天统一刷成当天。全站时间都变成同一天，相当于告诉搜索引擎“所有页面每天都改了”，更新信号会失去参考价值。只在页面内容确实变动时，更新对应条目的时间。
几个实用的小建议
- 用脚本自动拆分并生成文件，不要手工维护一堆 XML。
- 命名保持规律，例如 sitemap-{类型}-{序号}.xml，方便和日志、报告对照。
- 子文件不必用满 50,000 条上限，几千到一两万条一个文件，重跑成本更低。
- 删除或合并分片时，同步更新索引文件，别留下指向已删除文件的条目。
把分片结构和 URL 取舍理清楚之后，就能比较快地判断：收录不理想究竟是 sitemap 没被正确处理，还是这些页面本身就不该或暂时不该进入索引。