搜索引擎爬虫：小流量灰度如何暴露全量发布的例外
📱 Mozilla/5.0 (Linux; Android 7.0;) AppleWebKit/537.36 (HTML, like Gecko) Mobile Safari/537.36 (compatible; PetalBot;+https://webmaster.petalsearch.com/site/petalbot)
🔗 /d3ab180ff1ae.html
📄
搜索引擎爬虫：小流量灰度如何暴露全量发布的例外
灰度发布只把少量入口或少量URL交给搜索引擎爬虫，常见做法是挑“干净样本”验证规则。真正的问题在于：全量发布后，例外URL会以你没预料到的路径进入抓取队列，而灰度阶段恰好把它们排除了。要判断该不该扩大灰度样本，先看例外是否出现在抓取入口层，而不是看灰度页面的返回码是否漂亮。
两种灰度策略的取舍：按入口切还是按URL切
按入口切，指只放出一部分栏目、子域或站点地图分片；按URL切，指从全站随机抽样一批URL。两者成立的条件不同。
- 按入口切成立的条件：例外集中在某类模板、某个参数组合或某个内容类型，且你能事先列出这些入口。代价是灰度覆盖面窄，跨入口的链接发现路径不会被触发。
- 按URL切成立的条件：例外来自链接关系、分页串联或历史遗留URL，无法按栏目归类。代价是样本里大部分是正常页，例外出现频率低，需要更长的观察窗口。
如果灰度目标只是验证新模板能否被抓取和解析，按入口切更快；如果目标是发现全量发布才会出现的例外，按URL切更接近真实。二者不必二选一，但必须明确这次灰度在回答哪个问题。
实施动作：用抓取路径而不是返回码做判别
灰度期间记录三类证据：请求的URL、请求来源（站点地图、内链、外链或历史队列）、以及响应状态。返回码只能说明这一次请求的结果，不能说明爬虫为什么找到它。
一个可执行的动作是：把灰度放出的URL与全量URL清单做差集，再检查差集中是否存在被内链指向、被分页串联或被旧站点地图保留的地址。假设某站点灰度只放出新的文章详情页，全量发布后才发现列表分页的第2页起仍指向旧参数URL。这个例外不是模板问题，而是链接发现路径的问题。发现它之后，下一步不是改返回码，而是决定这些旧参数URL是保留、重定向还是加抓取限制。
这个动作的结果直接影响下一步：如果例外来自站点地图，先修站点地图分片；如果来自内链，先修模板；如果来自历史队列，单靠灰度无法复现，需要单独观察日志。
灰度容易漏掉的例外类型
小流量灰度天然会漏掉低频但高影响的URL。常见的有：
- 只在特定参数组合下生成的页面，例如排序或筛选参数。
- 由用户生成内容或评论分页产生的深层链接。
- 旧域名、旧目录或大小写变体残留的地址。
- 只在移动端模板或特定语言版本中出现的链接。
这些例外在灰度样本中占比很低，但全量发布后可能被大量抓取。判断是否需要扩大样本，可以看灰度期间抓取日志里非样本URL的占比：如果爬虫已经绕过你放出的入口，从其他路径进入，说明链接发现路径比灰度范围更宽。
发现例外后的处理边界
robots.txt 的抓取限制不等于可靠的索引移除。即使灰度阶段用抓取限制挡住某类URL，全量发布后它们仍可能以其他形式出现在结果中。站点地图不保证收录，提交更多URL不等于例外会被正确处理。HTTPS 不保证安全无漏洞或排名，它不能替代对例外URL本身的判断。
不同搜索引擎对参数处理、抓取限制和索引移除的支持情况须分别核查。灰度暴露的例外，在一个引擎里可能被合并，在另一个引擎里可能被单独抓取。因此处理动作要按引擎分别验证，而不是用一次灰度结果推断全部。
决策顺序：先定例外归属，再定发布节奏
如果灰度只用于验证模板，例外归属不清时可以按原计划全量发布，但要在发布后单独观察日志，把例外URL作为独立任务处理。如果灰度用于验证抓取预算或索引质量，例外归属不清时应先缩小全量范围，比如分批放出入口，直到确认例外的来源层。
一个简单的判断依据：例外URL是否在灰度期间被任何路径请求过。如果被请求过但未进入样本，说明问题在链接发现；如果完全没被请求过，说明问题可能在站点地图或入口配置。前者需要修链接，后者需要修提交范围。两种情况的发布节奏不同，不能共用同一个结论。
