Sitemap 的本质是一份交给蜘蛛的 URL 清单。站点只有几十、几百个页面时，一个文件就能装下；到了几万甚至几十万 URL 的量级，就需要把它拆成分片，再用一个索引文件把它们串起来。这一步做得好不好，直接决定蜘蛛能不能完整、及时地知道你有哪些页面。

为什么必须拆成索引加分片

单个 Sitemap 有硬性上限：一般不超过 5 万条 URL，未压缩体积不超过 50MB。超过就得拆。而且拆分本身也有好处——按栏目或内容类型拆开后，某个频道大量更新时，只需要让对应的分片显示新的时间戳，不必把整站清单的时间都刷新一遍。

索引文件的作用很简单：它是一个只列分片地址的清单文件。你只需要把索引文件地址提交出去，蜘蛛顺着索引就能拿到全部分片。

拆分维度怎么选

• 按栏目拆：新闻、商品、问答各自一个分片，便于追踪各频道的收录与抓取情况。
• 按内容类型拆：文章、图片、视频页面分开，不同类型可以带不同字段。
• 按更新时间拆：例如按天或按周生成新的分片，配合 lastmod 使用，适合更新量大的站点。

拆得太碎也不好维护。几十个分片属于正常范围，几千个分片往往说明拆分逻辑失控了。

分片里到底该放什么

这是最容易出错的地方。分片不是备份清单，不是把数据库里所有 URL 导出来就完事。

• 只放返回 200、且允许被索引的规范化 URL。
• 不要放 301、302 的目标之外的旧地址，更不要放 404、410 的地址。
• 不要放被 robots.txt 屏蔽、或页面上带 noindex 的页面。清单和页面上的指令互相矛盾，只会让蜘蛛反复确认。
• 同一页面只出现一次。带参数的、带会话 ID 的、www 与非 www、尾斜杠变体，都应先统一再写入。
• 被屏蔽的目录整段不要出现在清单里，避免制造无意义的抓取请求。

lastmod 别乱写

lastmod 表示该 URL 内容的最后实质修改时间。如果每次生成清单时都全量刷新成当前时间，蜘蛛很快会发现这个字段不可信，进而忽略它。更稳妥的做法是：只有正文或关键内容真的变了，才更新对应条目的时间；纯粹改模板、改样式，不必动它。

索引文件本身也有一个 lastmod，它指这份分片最后更新的时间，同样不建议无差别刷新。

几个高频的踩坑点

1. 索引里混入页面 URL：索引文件只能列分片地址，列页面地址属于格式错误，整份文件可能被忽略。
2. 压缩与响应头不对：使用 .gz 压缩时，要保证服务器返回正确的类型和编码，否则蜘蛛读到的是一串乱码。
3. 分片长期不变：一个分片生成后再也没更新过，蜘蛛对它的重访频率自然会慢慢降低。
4. Sitemap 地址没写进 robots.txt：在 robots.txt 里声明 Sitemap 地址，是最省事的告知方式之一。
5. 分片数量很多，索引只列了一部分：索引和分片之间要能一一对上，拆分逻辑变更后记得同步。

Sitemap 解决发现问题，内链解决路径问题

有一点需要说清楚：Sitemap 只负责告诉蜘蛛「有哪些 URL」，它并不保证这些 URL 都会被立刻抓取，也不决定抓取顺序。页面之间怎么连、链接出现在什么位置、从首页点几下能到，这些仍然由内链结构决定。

比较常见的失衡是：Sitemap 里列了几十万 URL，但站内几乎没有任何链接指向深层页面。蜘蛛拿到清单后，仍然可能因为缺少内链支撑而只抓走一小部分。清单和内链应该是互相印证的两套东西，而不是二选一。

用日志验证分片有没有被读到

想知道分片到底有没有生效，最直接的办法是看服务器日志：筛选出 Sitemap 分片地址的请求记录，观察状态码是否为 200、抓取频率是否稳定、是否集中在某几个分片上。

如果某个分片长期没有任何抓取记录，先检查它是不是被索引文件正确引用，再检查响应状态和响应时间，而不是先去怀疑蜘蛛。

一份可以照着做的检查清单

• 索引文件只列分片，分片只列有效 URL。
• 每个 URL 在整站清单中只出现一次。
• lastmod 反映真实的内容变动。
• 分片按清晰、稳定的维度拆分，数量可控。
• Sitemap 地址已在 robots.txt 中声明。
• 分片的抓取记录能在日志里查到。
• 清单中的 URL 在站内都有可达的内链路径。

把这些基础工作做扎实，比反复调整字段优先级更有意义。