Sitemap 的入门用法很简单：把 URL 一行行列出来，提交到搜索平台即可。但当站点从几百个 URL 增长到几万、几十万个时，单文件方案会迅速失效——文件体积超标、每次更新都要全量重写、出错后难以定位范围。这时就需要用 Sitemap 索引把 URL 拆成多个分片来管理。

索引文件解决的是什么问题

Sitemap 索引本身不包含页面 URL，它只列出各个子 Sitemap 的地址。搜索引擎先读索引，再按分片逐个抓取。这样做的好处主要有三点：

• 绕开单文件限制：单个 Sitemap 在 URL 数量与文件体积上都有上限，索引可以把总量拆到多个文件里。
• 降低维护成本：只更新发生变化的那一个分片，不必全量重写。
• 便于定位问题：某个分片返回异常或整体失效时，影响范围可控，排查路径也更清晰。

需要注意的是，索引的嵌套层级通常只支持一层，不要试图用索引去套索引。

分片按什么维度切

分片方式没有标准答案，但应尽量让同一个分片内的 URL 具有相似属性，方便后续核对。

按内容类型切

文章、商品、专题、标签页各自成片。不同类型页面的更新频率和数量级差异很大，混在一起会让 lastmod 失去参考意义。

按更新频率切

高频更新的栏目单独成片，低频或归档页面放在另一片。日常只需重写高频分片，低频分片可以长时间保持稳定，减少无意义的变动。

按语言或站点切

多语言、多子域站点按站点维度切分，每个分片只包含同一站点下的 URL。跨站混放会让抓取范围难以界定，也不利于分站点排查。

分片文件的书写要点

• 使用绝对地址，包含协议与域名，便于蜘蛛直接解析。
• 每个分片控制在合理规模内，不要把上限顶满，留出增长空间。
• 整个分片的 lastmod 应反映分片内 URL 的真实变化，而不是每次生成都刷新成当前时间。
• 文件较大时启用 gzip 压缩，减少传输开销。
• 分片之间的 URL 不要重复，重复会带来额外的规范化判断成本。

维护节奏与核对顺序

索引不是一次生成就不用管了，建议按固定节奏检查：

1. 确认索引文件可访问，返回正常状态码，内容为有效 XML。
2. 逐个访问分片地址，检查是否有空分片、失效分片或历史遗留的旧分片。
3. 抽查分片内 URL 能否正常打开，是否存在跳转、noindex 或已下线的页面。
4. 对照服务器日志，看各分片是否被周期性读取，频率是否与预期相符。
5. 对长期不被读取的分片，检查它是否被正确声明在索引中，或者是否已经失去维护价值。

用日志验证分片是否有效

日志是检验 Sitemap 是否真正发挥作用的直接依据。可以在日志中筛选对 Sitemap 文件本身的请求，观察索引与各分片的访问频次、时间间隔，以及是否出现大量 4xx、5xx。如果索引被频繁读取，而分片长期无人访问，通常说明索引声明存在问题，或者分片内容长期没有变化，已不再被优先处理。

提交 Sitemap 只是提供一条发现线索，并不等于页面一定会被抓取或收录。真正决定抓取量的，仍是页面价值、内链结构与站点整体质量。

Sitemap 索引与分片管理属于基础设施层面的工作，做得好不会带来额外收益，做得差却会在站点规模扩大后不断制造麻烦。把分片划分、字段书写与日志核对固定成常规流程，URL 发现这件事会稳定很多。