Sitemap 是 URL 发现里最直接的一条通路，但站点一大，把所有地址塞进一个文件就行不通了。搜索引擎对单个 Sitemap 文件有明确的条数和体积上限，超过之后要么提交失败，要么抓取器只读到前面一部分。稍具规模的站点最后都会走到分片加索引文件这一步，问题只在于怎么拆、怎么维护。
单文件的上限与拆分的理由
目前主流搜索引擎通用的限制是：单个 Sitemap 最多 50,000 条 URL，解压后不超过 50MB。看着很宽松，但对电商、内容站来说，商品加标签页很容易就冲过这条线。拆分不只是为了绕过限制，还有几个实际考虑：
- 文件过大时解析变慢，抓取器可能中途放弃，后面的地址等于没交；
- 一次提交全站地址，很难判断到底哪一批 URL 被处理了；
- 不同栏目更新频率差别大，混在一个文件里，每次都要整份重读；
- 新开栏目时，无法单独拿出一批地址做提交和观察。
常见的分片方式
拆分维度没有唯一答案，按自己最想观察的口径来定就行：
- 按内容类型拆：文章、商品、分类、标签各一个文件；
- 按目录或频道拆：新闻、商城、帮助中心分别成文件；
- 按更新频率拆：日更内容一个，历史归档一个；
- 按语言或地区拆：多语言站点按语言分层；
- 结构扁平、没有明显分类时，按每两万条左右纯数量切分。
需要提醒的是别拆得太碎。几百个只含几十条地址的小文件，抓取器逐个请求的开销反而更大，后期维护也容易出错。单文件放几千条，是比较舒服的区间。
索引文件本身怎么写
Sitemap 索引文件里只放各个 Sitemap 的地址，不要再混入普通页面 URL。几个容易踩的点：
- 地址写绝对路径，协议和域名补全，不要用相对地址；
- XML 特殊字符要转义，URL 里的连接符不能直接写；
- 每个节点可以带一个 lastmod，表示该文件整体的更新时间；
- 文件用 UTF-8 编码，开头保留 XML 声明；
- 若提交的是压缩文件，索引里引用的也要是压缩后的地址。
索引文件是目录，不是清单。把页面 URL 直接写进索引里，多数抓取器不会把它当成有效入口。
提交之后该看什么
提交 Sitemap 只是告诉搜索引擎有这批地址，既不保证抓取，更不保证收录。真正值得盯的是这几项：
- 提交数量与已处理数量的差值，长期悬殊通常说明页面本身存在问题；
- 各个 Sitemap 的抓取次数，能看出抓取器更愿意走哪个目录；
- lastmod 是否被参考，页面内容没变却天天改时间，这个信号会逐渐失效；
- 服务器日志里 Sitemap 地址的访问节奏，判断抓取器有没有定期回来取。
它解决不了的问题
Sitemap 只负责把地址交出去，不负责让蜘蛛爬到，也不决定谁排前面。页面之间的内链关系、从入口到详情页的点击深度、页面本身是否值得抓，仍然是抓取路径的主干。一个只被 Sitemap 引用、没有任何内链指向的地址，即使被发现，回访频率通常也很低。
比较稳妥的配合方式是：内链保证常规路径通畅，Sitemap 作为新页面和深层地址的补充通道，服务器保持稳定响应，别在抓取时掉链子。三者对齐之后，URL 发现的节奏才会稳下来。