Sitemap 的作用边界

Sitemap 解决的是“发现”问题，不是“收录”问题。它告诉蜘蛛这里有这些 URL，但抓不抓、什么时候抓、抓完是否收录，取决于内容质量、服务器响应和页面本身是否可抓取。所以不要把 Sitemap 当成收录开关，它的实际价值在于让新 URL 更快进入待抓队列，让老 URL 的更新信号更明确。

单文件的两个硬限制

通用规范里，单个 Sitemap 文件有两个限制：URL 条数不超过 50000 条，未压缩体积不超过 50MB。实际使用建议留出余量，比如控制在 30000 条以内，因为生成和传输过程中的开销常让实际体积超出预期。

超过限制就必须拆分。拆分的依据不要只按数量平均切，更合理的是按目录或内容类型切：文章、商品、标签、专题各一个文件。这样出问题时能单独定位，更新频率不同的内容也不会互相拖累。

索引文件怎么串联子文件

拆分后需要一个索引文件把子文件列出来，索引文件本身同样受 50000 条和 50MB 的限制。索引里每条记录包含 loc 和可选的 lastmod，loc 必须是完整的绝对地址，并且与子文件真实地址完全一致，大小写、结尾斜杠都要对得上，否则蜘蛛取不到内容。

索引地址可以在 robots.txt 里声明，也可以提交到站长平台，两者不冲突。但不要今天提交这个地址、明天换成另一个，让蜘蛛在两个入口之间反复确认，白白消耗抓取次数。

lastmod 怎么写才不算噪声

lastmod 是抓取调度中少数能直接被利用的时间信号，但滥用会失效。常见的问题有：

• 每次生成 Sitemap 时把全站 lastmod 刷成当前时间，蜘蛛会认为所有页面都在频繁更新，最终忽略这个字段；
• 内容没变，只因模板或样式的改动更新了时间戳；
• 时间格式不统一，有的写日期，有的写带时区的时间戳。

比较稳妥的做法是：只在正文发生实质变化时更新 lastmod，格式统一用带时区的 ISO 8601。如果做不到准确，宁可不写，也不要写一个假的。

容易被忽略的几类错误

• 把 robots.txt 里已被拦截的 URL 放进 Sitemap，蜘蛛读到也会跳过，等于浪费一次抓取；
• Sitemap 里混入 404 或 301 的旧地址，尤其是改版后没清理干净的历史路径；
• URL 带上会话 ID、排序参数等无意义变体，等于自己制造重复内容；
• Sitemap 动态生成时读取全站数据，接口超时返回空文件，蜘蛛拿到 200 但内容是空的；
• 压缩格式与地址声明不一致，比如文件是 gzip 压缩，但地址结尾写成 .xml。

提交之后要验证什么

提交只是开始。接下来看日志：Sitemap 文件本身有没有被稳定抓取，返回码是不是 200，蜘蛛是否顺着清单去抓了里面的 URL。如果 Sitemap 被频繁抓取，但里面的新 URL 迟迟没有动静，问题通常不在 Sitemap 本身，而在于站点整体抓取预算被低价值页面占满，或者内链没有把入口留给新页面。

把 Sitemap 当成一份需要持续维护的“待处理清单”，而不是一次性提交完就不用管的任务。

和内链的分工

Sitemap 负责广度，内链负责深度和优先级。一个页面如果只出现在 Sitemap 里、站内没有任何链接指向它，蜘蛛抓取后很难判断它处在什么位置，回访频率也会被压低。比较稳的组合是：新内容发布后既有内链入口，比如列表页、相关推荐、频道页，也在 Sitemap 里出现，两条路径互相印证。

至于分页、筛选参数这类页面，一般不建议放进 Sitemap，让它们靠内链自然被发现即可，避免把有限的抓取次数花在内容高度重复的路径上。