网站被百度收录，小流量灰度暴露了全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /bdfeb23c5fc7.html
📄
网站被百度收录，小流量灰度暴露了全量发布的例外
灰度只放出一小部分 URL 时，百度抓取和收录表现正常，一旦全量发布就出现大量页面不进索引。这通常不是灰度本身失效，而是灰度样本没有覆盖全量才会触发的例外：参数拼接、分页组合、缓存键、权限分支、模板兜底，这些分支在小样本里很可能一个都没被命中。灰度能验证的是“被抽到的那批页面没问题”，不能验证“全部页面都没问题”。
先判断例外属于哪一类，再决定保留还是回退
把灰度和全量之间的差异归因，是取舍的前提。常见有三类，证据形态不同：
- 样本偏差型：灰度只选了首页、栏目页这类干净 URL，全量才放出带参数、带筛选、带排序的列表页。表现为新出现的 URL 形态集中不收录，而原有形态正常。
- 容量触发型：灰度流量低，缓存命中率高；全量后缓存击穿，同一 URL 短时间内返回不同内容或不同状态码。表现为抓取日志里同一地址多次响应不一致。
- 规则冲突型：全量上线时新增了 robots.txt 规则、canonical 或跳转，与灰度期间的行为不同。表现为原本可抓取的路径突然被限制或被指向别处。
能区分这三类的关键证据是抓取日志与响应状态的时间线，而不是收录数量的涨跌。收录量下降本身不能证明是发布导致的，也可能是抓取配额波动、站点整体改版或外部链接变化。先确认“同一 URL 在灰度期和全量期返回是否一致”，再谈保留还是回退。
保留、改写、退出各自的适用前提
保留适用于例外只影响低价值分支，且这些分支本来就不需要被收录。例如筛选组合页数量庞大但无独立搜索需求，此时正确动作是收敛而非修复：对这类 URL 统一加 canonical 指向主列表页，或在 robots.txt 中限制抓取路径。注意 robots.txt 只约束抓取，不等于把已收录页面移出索引；如果目标是移除，需要配合页面级 noindex，且要等百度重新抓取该页后才生效。
改写适用于例外页面确有搜索价值，只是实现方式让百度无法稳定处理。典型动作是把依赖前端渲染或参数拼接的内容，改为服务端输出稳定 HTML，并保证同一语义只有一个 URL。判断是否值得改写，看两个条件是否同时成立：该分支有真实检索需求，且改写后 URL 数量可控。如果参数组合是无限膨胀的，改写成本会随组合数增长，这时应优先收敛。
退出适用于例外已经影响核心页面。例如全量后新增的跳转规则把栏目页也卷了进去，导致主路径响应异常。此时应回退发布，而不是边修边观察。回退的判据是“核心页面响应是否恢复一致”，不是“收录是否立刻回来”——收录恢复有延迟，用它做回退判据会误判。
一个假设例子：怎样用最小代价定位例外分支
假设某站点有 5000 个商品页和 20000 个筛选组合页。灰度只放了 200 个商品页，全量后筛选页大量不被收录。
- 从抓取日志中按 URL 形态分组，统计每组的响应状态码分布，而不是看总量。
- 如果筛选页普遍返回 200 但内容高度重复，属于样本偏差型，动作是收敛：canonical 指向主列表，并评估是否需要在 robots.txt 中限制组合参数抓取。
- 如果筛选页状态码在 200 与 5xx 之间波动，属于容量触发型，动作是先修缓存与超时，再重新提交站点地图。站点地图只帮助发现 URL，不保证收录，所以提交后仍需回看抓取日志确认响应是否稳定。
- 如果筛选页被新规则挡在抓取之外，属于规则冲突型，动作是回退该条规则并单独验证，而不是整体回退发布。
这个顺序的价值在于：每一步的结论决定下一步做什么。若跳过日志分组直接改模板，可能把容量问题当成内容问题处理，改完仍然不稳定。
灰度设计上可以立刻改的一件事
把灰度样本从“按流量比例随机”改为“按 URL 形态分层抽样”，每类形态至少覆盖一条。这样灰度阶段就能暴露参数页、分页页、兜底模板这些分支，而不是等全量才撞上。分层抽样的代价是灰度覆盖面看起来变杂，但换来的是发布前就能拿到分支级证据。
另外要明确一点：HTTPS 只解决传输加密，不保证页面无漏洞，也不保证被收录或获得更好排名。把它当作收录问题的解释，方向就错了。
最后，无论选择保留、改写还是退出，都要为下一步留下可验证的判据。灰度暴露的例外如果不写进发布检查项，下一次全量还会以同样的方式出现。
