📍 WDQWDWQD987AAAAA:216.73.216.136
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d7d824cbb7f0.html
📄

网站收录提交，小流量灰度为什么没暴露全量发布的例外

小流量灰度只验证了“被选中的那部分 URL 能走通”，如果全量发布时会新增灰度中不存在的 URL、参数或子域，灰度通过并不能推出全量提交有效。要让灰度结论成立，前提是灰度集合与全量集合在“提交对象”这一维度上同构；一旦全量多出灰度从未覆盖的类别，例外就会在放量后集中出现。

灰度真正验证的是子集，不是全集

灰度通常按比例或按目录抽样提交，比如只推送主站文章路径，或只取 sitemap 的前若干条。它检验的是这条链路上的抓取、解析和入库是否正常，而不是“所有会被提交的 URL 都正常”。

因此要区分两件事：

• 链路可用：灰度中的 URL 能被发现、抓取、建立索引。
• 集合完整：全量发布时进入提交范围的 URL 与灰度同构。

灰度能证明第一件事，第二件事需要额外核对。很多“灰度没问题、全量出问题”的情况，本质是第二件事从未被验证。

让灰度结论失效的一个反例

假设一个站点按目录灰度，只提交 /article/ 下的 URL。灰度期间这些页面全部正常被抓取，团队据此认为提交逻辑已经可靠，随后全量放开。

但全量集合里还包含 /tag/ 聚合页、带 ?page= 的分页参数、以及新上线的子域。这些类别在灰度中一条都没出现过，于是放量后出现三类例外：

1. 参数页被去重：分页参数被规范化到主路径，实际内容未进入索引。
2. 聚合页被判定为低价值：与文章页规则不同，灰度从未覆盖。
3. 子域未在提交范围内：提交清单按主域生成，子域整体缺失。

这个反例说明，灰度通过只能说明“已覆盖类别没问题”，不能说明“未覆盖类别也没问题”。例外恰恰集中在灰度没有抽到的部分。

放量后先分辨例外的真实原因

发现全量提交后收录不及预期时，不要直接改配置。先按可区分证据归类：

• 提交清单缺项：全量 URL 总数明显多于灰度覆盖的类别，缺的是整类而非零散几条。
• 抓取被限制：robots.txt 或服务器策略拦住了灰度未涉及的路径。注意抓取限制不等于可靠的索引移除，它只影响能否被抓。
• 页面自身问题：新类别页面存在重复、空内容或渲染失败。
• 提交动作未生效：提交接口返回成功但清单未更新，需要核对提交记录与站点地图是否一致。

站点地图不保证收录，提交也不保证收录；这些现象只能作为线索，不能单独作为结论。抓取量或提交量归零，也可能是采集延迟、日志采样或统计口径变化，而不一定是处理错误。

下一步：把灰度改成按类别抽样

与其按比例抽样，不如按 URL 类别抽样，让灰度集合覆盖全量会出现的每一种形态。具体动作：

1. 列出全量提交会包含的所有类别：内容页、聚合页、参数页、子域、多语言路径等。
2. 每类至少抽一条进入灰度，记录其提交结果与抓取状态。
3. 放量前比对灰度类别清单与全量类别清单，确认没有整类缺失。
4. 放量后按类别分别统计，而不是只看总量。

这样做的结果是：当某类 URL 出现例外时，你能立刻判断它是“灰度没覆盖”还是“链路真的坏了”，从而决定是补抽样还是改配置。灰度是否通过，取决于它是否覆盖了全量会出现的例外类别，而不是取决于比例大小。