Sitemap 是站点主动交给搜索蜘蛛的一份 URL 清单。页面不多时，一个文件就能覆盖；当站内 URL 涨到几万、几十万条，单文件必然装不下，这时怎么拆、怎么用索引文件串起来，会直接影响蜘蛛读这份清单的效率和完整度。

先确认几个硬上限

各搜索平台的规则略有差异，但大方向一致：

• 单个 Sitemap 文件能放的 URL 数量有上限，未压缩体积也有上限。
• 超出上限就得拆成多个子文件，再用一个 Sitemap 索引文件把它们列出来。
• 索引文件本身同样受数量和体积约束，子文件特别多时要再分一层。
• 开启压缩能明显减小传输体积，但响应头与文件名要写对，别让蜘蛛下载到一个打不开的文件。

具体数字以各家官方文档为准。运营上更值得关注的是：每个文件是不是都能正常打开、返回的状态码是不是 200、内容是不是合法的 XML。

按什么维度拆分更顺手

按内容板块拆

商品、文章、分类、标签各给一个子文件，好处是出问题时定位快。某一类 URL 突然出现大批量抓取异常，看一眼对应的子文件就能把范围缩小。

按更新节奏或 URL 段拆

把高频更新的内容单独放一个子文件，低频的放另一个。这样观察新增 URL 的发现速度时，数据会更干净，不会因为新老内容混在一起而看不出变化。

不建议按 URL 参数或查询串去拆，那类地址本身就该收口，放进 Sitemap 只会把噪音一并递出去。

哪些 URL 不该出现在清单里

• 会跳转的地址，也就是 301、302 的源 URL，直接写最终地址。
• 返回 404、410 的失效页面。
• 已经设了 noindex 的页面。
• 被 robots.txt 屏蔽、蜘蛛本来就不能抓的 URL。
• 同一内容有多套地址时，只留 canonical 指向的那一个。

把不该出现的地址放进 Sitemap，等于给蜘蛛派了一批注定失败的任务，消耗的是抓取时间和服务器资源。

Sitemap 不能替代内链

Sitemap 解决的是“蜘蛛知道有这个地址”，但它不负责告诉蜘蛛这个页面在站内有多重要、从哪条路径能走到。一个只出现在 Sitemap、站内没有任何入口链接的页面，仍然容易变成孤岛。

把 Sitemap 当作发现通道，把内链和导航当作抓取主干道，两者各司其职，别指望其中一方包办。

新页面上线时，比较稳妥的做法是同时在两个地方露出：站内给它一个自然的入口链接，Sitemap 里同步更新。只做前者，蜘蛛可能晚几天才发现；只做后者，它进来了也未必会认真走。

提交之后该观察什么

• 后台的 Sitemap 相关报告：文件是否读取成功、识别到多少 URL。
• 服务器日志：Sitemap 文件本身的访问是否频繁报错或超时。
• 子文件里的 URL 被实际访问过的比例，用来判断发现通道是否顺畅。
• 新增 URL 从上线到第一次被抓的时间，作为发现速度的参考。

Sitemap 更新后不需要反复重新提交，让文件内容保持实时准确，比多按几次提交按钮更重要。

几个反复出现的坑

• Sitemap 文件本身被 robots.txt 挡住，或者放在需要登录才能访问的目录里。
• 子文件里长期混着已删除、已改版的旧 URL，没人清理。
• 索引文件引用的子文件用了错误域名，www 和非 www 混着写。
• 体积靠压缩达标了，但解压后仍然超限，蜘蛛读到一半就停。

这些问题的共同点是：不影响页面本身，只影响蜘蛛拿到清单的效率，所以平时不容易被发现，往往要翻日志才看得出来。定期抽查一次文件状态和日志里的读取记录，比事后排查省事得多。