网站不收录：一次小流量灰度如何暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fef55fa468c3.html
📄
网站不收录：一次小流量灰度如何暴露全量发布的例外
小流量灰度能暴露全量发布例外的原因，不是样本大，而是它把“发布成功”拆成了可核对的抓取与索引事实：灰度路径下某些URL被抓取、某些没有，说明问题往往不在服务器是否返回200，而在发布范围、链接入口与规则作用域不一致。灰度如果只看流量和转化，不看抓取日志与索引状态，就无法提前发现例外；若同时记录URL分组，就能在放量前定位是哪一类页面被规则或入口遗漏。
灰度验证抓取与索引，还是只看流量
两种做法都成立，但适用条件不同。若灰度目的是确认页面能被发现，就必须把“抓取请求是否到达该组URL”和“索引状态是否变化”作为主要观察项；若灰度只是验证功能与转化，流量指标可以作为主指标，但需要承认它无法回答收录问题。选择依据是发布目标：新增内容页、改版目录、批量生成页面，属于前者；已有页面的样式或交互调整，属于后者。
实际操作上，把灰度URL按发布批次分成若干组，例如A组为新目录页，B组为旧页改版，C组为仅换模板的页面。发布后分别检查这些组的抓取记录与索引状态，而不是只看整站总量。结果会影响下一步：如果A组有抓取、B组没有，说明入口或内链没有覆盖B组，应先补入口再放量；如果三组都没有抓取，才需要回到规则与可访问性层面排查。
为什么全量发布才暴露例外
灰度阶段常被忽略的事实是：灰度入口往往由人工指定，链接可能来自测试导航、临时列表或直接提交，这些入口在全量发布时并不存在。于是灰度时“看起来能被发现”的页面，在全量后失去了唯一入口。另一种情况是规则作用域：灰度只放行了少量路径，全量后新增路径落入某个限制范围，抓取被拦下，但页面本身仍可正常访问。
要区分这两类原因，可以核对三项证据：灰度URL是否出现在正式导航或站点地图中；robots.txt 的限制是否只覆盖了灰度路径之外的范围；服务器日志中全量发布后该组URL的抓取请求是否归零。需要说明的是，抓取量归零还有别的合理解释，例如发布时段与抓取高峰错开、站点整体抓取预算被其他目录占用、日志采样不完整。因此不能只凭一项归零就断定规则错误。
放量前把分歧转成可核对的项目
多个角色对“是否已收录”理解不同，通常是因为各自看的是不同层面：开发看HTTP状态，运营看搜索前台是否出现，SEO看抓取与索引状态。把分歧转成项目，就是为每个URL组定义同一组可核对字段，并约定由谁在什么时间点检查。
- URL组标识：按发布批次或目录划分，避免只记录整站数量。
- 入口证据：该组是否出现在正式导航、内链或站点地图中；站点地图不保证收录，只能作为发现线索。
- 规则证据：
robots.txt与页面级限制是否作用于该组；抓取限制不等于可靠的索引移除。 - 状态证据：抓取请求、索引状态、前台展示分别记录，不合并成“收录了没有”。
一个假设例子：某次灰度只放行20个新页面，其中18个被抓取；全量发布200个同类页面后，抓取请求集中在前50个，后150个没有请求。此时不应直接判定规则出错，而应先检查后150个页面是否有独立入口、是否与已抓取页面高度重复、以及抓取预算是否被前50个占满。若入口缺失，补内链后继续观察；若入口完整但仍无请求，再检查规则与服务器响应。
实施动作与例外处理
放量前先做一次入口与规则的交叉核对：把灰度期间实际产生抓取的URL，与全量发布后正式入口覆盖的URL做对比，找出只存在于灰度入口的页面。这个动作的结果决定放量节奏——若差异集中在少数目录，可以先补齐入口再放量；若差异分散且无法快速补齐，应缩小首批放量范围，保留灰度组作为对照。
例外处理的原则是分层回退，而不是整体回滚。只影响入口的，补入口；只影响规则的，调整规则作用域；只影响单一批次的，暂停该批次放量。HTTPS 不保证安全无漏洞或排名，因此不要把协议切换当作收录问题的解释终点。不同搜索引擎对规则与提交方式的支持情况须分别核查，同一现象在不同引擎下可能对应不同原因。
最后，把这次灰度中出现的例外写回发布流程：哪些URL组必须带正式入口才能放量，哪些规则变更需要先做小范围验证。这样下一次全量发布时，灰度不再只是流量试验，而是提前暴露例外的手段。
