灰度期间收录正常、全量发布后新增页面却不再被收录,最常见的原因不是抓取预算,而是灰度与全量之间存在一个只对部分URL生效的例外条件。灰度只覆盖了主路径样本,全量才第一次把带参数、分页、多语言或登录态的变体放出来,这些变体恰好落在某个规则之外。要解决它,先别急着改站点地图,而是把灰度样本与全量URL集合做差集,找出灰度没验证到的那一类。
两种情况下动作完全不同,判断依据是灰度URL与全量URL的模板是否一致。
?sort=、?page=、地区子域或登录后路径。此时灰度验证的结论不能外推到全量,例外条件就藏在这些新形态里。判断方法很直接:拉出灰度期间被成功抓取的URL样本,再拉出全量上线后新产生的URL,按路径模板分组做差集。差集中占比最高的那一类模板,就是灰度没有覆盖的例外。
小流量灰度通常按用户维度或百分比切流,而不是按URL模板切流。这意味着灰度命中的是“一部分用户访问全部URL”,或者“全部用户访问一部分URL”。前者会让灰度期间出现所有URL形态,但每类样本量都很小;后者会让灰度只覆盖少数模板。
如果你用的是按用户切流,灰度期间某个低频模板可能只被访问过几次,抓取工具甚至没来得及发现它,于是“灰度收录正常”这个结论本身就不成立——你验证的只是高频模板。按URL模板切流才能暴露全量发布时的例外,因为例外本身就是模板级的。
一个可操作的动作:在灰度阶段就按URL模板统计抓取与索引状态,而不是只看整体收录数。若某个模板在灰度期样本数为零或个位数,把它标为“未验证”,全量前单独为它安排一次小范围可抓取测试。
站点地图不保证收录,重发通常只是重复提交同一批已经被判定的URL,对例外模板没有帮助。更有效的顺序是:
这里有一个容易误判的点:robots.txt 的抓取限制不等于可靠的索引移除。反过来也成立——robots.txt 里没有禁止某个路径,不代表它一定可被抓取,中间可能还有WAF、地区拦截或登录态跳转。所以差集里的URL要逐个看实际响应,而不是只看规则文件。
假设一个场景:某站点灰度只放出中文详情页,全量增加了英文详情页,英文页由同一套模板渲染但依赖一个语言接口。灰度期中文页抓取正常,全量后英文页全部返回302到首页。差集会把英文模板单独列出来,抓取工具会显示302,指向语言接口未对爬虫放行。修复动作是让该接口对匿名请求返回正常内容,然后只对英文模板重新提交一批代表URL。结果如何影响下一步:如果这批代表URL在后续抓取中返回200并进入索引,说明例外已消除,可以按模板批量放量;如果仍返回302,说明还有第二层条件没暴露,需要继续缩小到具体参数。
HTTPS不保证安全无漏洞或排名,它只说明传输层加密存在,与某个模板是否可被抓取无关。同样,站点地图只是发现渠道之一,提交了不等于被处理。灰度暴露的例外往往发生在服务端逻辑层,而不是协议层或提交层。
不同搜索引擎对同一例外的处理也可能不同:某个引擎可能跟随重定向抓到最终页,另一个可能直接放弃。因此核查例外时要分别确认目标引擎的抓取行为,不要用一个引擎的结果推断全部。
把验证动作固定在模板级,而不是全站级。全站级指标会掩盖模板级差异,灰度样本量又不足以让模板级差异显现,这正是“灰度正常、全量异常”反复出现的原因。
下一次灰度前,先列出全量会新增的URL模板清单,逐个标注灰度是否覆盖。未覆盖的模板,在全量发布前用一个可抓取的最小样本验证返回码与可见内容。只有灰度覆盖过的模板,才允许直接套用灰度结论。这个动作的结果直接决定全量发布是分批放模板,还是一次性放开全部——分批放模板能让下一个例外在影响扩大前被单独看到。