百度蜘蛛：一次小流量灰度如何暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a3efdc3d8288.html
📄
百度蜘蛛：一次小流量灰度如何暴露全量发布的例外
灰度发布时百度蜘蛛表现正常，全量上线后抓取却出现异常，这通常不是蜘蛛“变脸”，而是灰度样本没有覆盖全量才有的例外路径。最该先查的不是抓取量，而是灰度与全量在入口、参数、缓存和权限上的差异。
先分清两种解释：样本偏差还是发布引入的新状态
第一种解释是样本偏差。灰度只放出一小部分 URL 或一小部分用户入口，百度蜘蛛恰好访问的是最规范的那批页面，例如带完整静态路径、能命中缓存、无需登录态的版本。全量发布后，更多长尾 URL、带参数 URL 或依赖特定 Cookie 的页面才第一次暴露，问题一直存在，只是灰度没抽到。
第二种解释是发布动作本身改变了状态。全量时切换了反向代理规则、CDN 缓存策略、robots.txt、站点地图生成逻辑或权限校验，导致蜘蛛在全量环境看到的内容与灰度环境不同。这两种解释对应完全不同的修复方向：前者要补抽样，后者要回退或修正发布配置。
用一组可区分证据判断是哪一种
不要只看总抓取量。抓取量下降或归零既可能来自发布阻断，也可能来自蜘蛛正常调度、日志采样丢失、CDN 回源日志未采集，甚至只是灰度期间蜘蛛集中抓过一轮后进入低频期。单一指标不能证明处理正确。
- 对比灰度 URL 与全量新增 URL 的响应状态码分布。如果异常只集中在全量新增的 URL 上，更偏向样本偏差。
- 用同一批灰度 URL 在全量环境重新请求。如果同一 URL 在灰度正常、全量异常，更偏向发布引入的新状态。
- 检查全量发布前后的 robots.txt、站点地图和缓存规则是否被改动。改动本身不是结论，但能缩小范围。
- 看日志里蜘蛛请求的 User-Agent、来源 IP 段和请求路径是否与灰度期一致。若路径结构变了，说明入口暴露方式变了。
缺少完整数据时能做的最小动作
如果没有全量日志权限，可以先用curl -A "Baiduspider"对灰度 URL 和全量新增 URL 各取一组样本，记录状态码、响应大小和是否返回登录页。这个动作的结果会直接影响下一步：如果全量样本返回 403 或跳转登录，应先修权限或代理规则，而不是继续调站点地图；如果状态码正常但内容为空，应先查缓存和渲染链路。
假设一组 20 个全量新增 URL 中，有 12 个返回 200 但正文为空，而灰度 20 个全部正常。这只能说明全量环境存在内容差异，不能推出百度蜘蛛一定不会收录，也不能推出收录量会按比例变化。它给出的下一步是：把空正文样本按模板或参数分组，找出共同特征，再决定是回退发布还是补规则。
灰度结论不能直接外推到全量
灰度验证的是“被抽到的那部分”，不是“全部”。如果全量发布包含新模板、新参数或新权限分支，灰度没有覆盖这些分支，就不能用灰度正常来证明全量对百度蜘蛛友好。反过来，全量异常也不能直接否定灰度方案，可能只是抽样范围不足。
robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。灰度期间即使蜘蛛抓取正常，也不代表全量后一定保持同样节奏。把灰度当作一次范围有限的探测，而不是上线许可，才能在全量异常出现时快速定位是抽样缺口还是发布缺陷。
把例外变成下一次灰度的检查项
全量发布后若确认是样本偏差，应把全量新增的 URL 类型、参数组合和权限分支补进下一次灰度的抽样清单。若确认是发布引入的新状态，应把对应的代理、缓存或权限配置加入发布前检查。两种结果都会改变后续动作：前者改抽样策略，后者改发布流程。没有这一步，下一次灰度仍可能只验证了最顺利的那部分。
