Sitemap 通常被当成一次提交就完事的文件，但真正影响抓取路径的，往往是它的组织方式：是一个大文件，还是索引文件加分片；分片按什么维度切；lastmod 是否可信。这些细节决定了蜘蛛多久来读一次、读到哪些 URL，以及后续会不会按你预期的路径继续抓。

Sitemap 索引文件不是摆设

当 URL 数量超过几万，或者站点有多个内容类型时，用一个 Sitemap 文件硬扛并不划算。更好的做法是使用 Sitemap 索引文件，指向多个子 Sitemap。这样有几个实际好处：

• 更新时可以只重写变化的分片，不必全量重新生成；
• 蜘蛛读取索引文件后，可以按分片逐个抓取，路径更清晰；
• 排查问题时能快速定位是哪个分片没有被抓取。

索引文件本身不需要塞入所有 URL，它只负责告诉蜘蛛“还有哪些 Sitemap 文件可读”。如果索引文件长期不变，而子文件定期更新，蜘蛛仍可能根据子文件的 lastmod 重新抓取。

分片怎么切更合理

分片维度没有唯一答案，但常见做法有以下几种：

1. 按内容类型切：文章、商品、分类页各一个分片。不同类型更新频率不同，重访节奏也可以不同。
2. 按更新时间切：把近期更新的 URL 放在一个分片，历史归档放在另一个。蜘蛛更容易发现新内容。
3. 按数量切：每个分片控制在几千到几万条，避免单个文件过大导致读取超时。

需要注意，分片不是越多越好。分片过多会增加蜘蛛读取索引和子文件的请求次数，也会让日志分析变得零散。一般保持每个子文件在 1 万到 4 万条之间，按实际更新量调整即可。

lastmod 的准确性比 priority 更重要

很多站点会在每次生成 Sitemap 时，把所有 URL 的 lastmod 都写成当前时间。这样做会让 lastmod 失去参考价值，蜘蛛多次读到“全部刚更新”之后，可能降低对该字段的信任。

更稳妥的做法是：只在实际内容发生修改时更新对应 URL 的 lastmod。对于列表页、筛选页这类频繁变动的页面，如果内容没有实质变化，不必强行刷新时间。priority 和 changefreq 字段可以保留，但不必过度纠结，蜘蛛更多是综合判断，并不会只按这两个字段决定抓取顺序。

抓取路径不会只跟着 Sitemap 走

Sitemap 是 URL 发现的通道之一，但它不是抓取路径的全部。蜘蛛进站后，仍然会结合内链、入口页、导航结构和服务器响应来决定下一步。常见的情况是：

• 重要页面在 Sitemap 里，但没有内链指向，蜘蛛可能只抓一次就很少重访；
• 页面在 Sitemap 里，但服务器响应慢或经常 5xx，抓取会被推迟；
• 内链层级过深，蜘蛛更依赖 Sitemap 才能发现，路径稳定性就差一些。

比较稳的做法是：Sitemap 负责兜底和批量暴露，内链负责提供持续路径。两者重合度越高，蜘蛛发现和重访的路径越不容易断。

用日志验证 Sitemap 有没有被读

提交了 Sitemap 不等于蜘蛛会频繁读取。可以在服务器日志里过滤蜘蛛 UA，观察几个点：

• 蜘蛛是否访问了 Sitemap 索引文件；
• 是否继续访问了子 Sitemap 文件，哪些子文件被跳过；
• 从 Sitemap 中出现的 URL 是否在之后进入抓取日志；
• 读取 Sitemap 时返回的状态码是否是 200，有没有 304 或 5xx。

如果索引文件被读，但子文件长期没人访问，可能是子文件太大、响应太慢，或者索引里指向的路径有误。如果子文件被读，但对应 URL 很少被抓，就要回到内链和服务器稳定性上找原因。

分片更新与服务器负载

Sitemap 文件本身也会消耗服务器资源。分片更新时，尽量只重写有变化的部分，避免一次性生成超大文件。对于访问量较大的站点，可以把 Sitemap 放在静态目录或 CDN 上，减少动态生成带来的压力。

把 Sitemap 当作抓取路径的辅助线，而不是唯一路线。它的价值在于稳定地暴露 URL，并在内链之外提供一条可核对的线索。

最后，定期检查 Sitemap 里的 URL 是否仍然返回 200，是否出现大量 301、404 或软 404。保持 Sitemap 干净，比不断往里塞新 URL 更能帮助蜘蛛维持稳定的抓取路径。