URL提交，批量页面只有一部分被发现时怎样划分对照组
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /288c8a0c841d.html
📄
URL提交，批量页面只有一部分被发现时怎样划分对照组
不要把“已发现”和“未发现”直接当成两组做对比，因为这两组在提交那一刻就已经被系统区别对待了。更可靠的做法是先按“提交方式是否真正生效”切一刀，再在每一层内部随机划分对照组。具体说：把同一批URL按提交渠道拆成若干层，每层内随机取一半作为对照、一半作为处理，然后观察两组的发现率差异。这样得到的差异才能归因到提交动作本身，而不是页面质量或链接结构的先天差别。
先确认“未发现”是提交失败还是抓取失败
在划分对照组之前，必须先区分两种完全不同的“未发现”。一种是提交接口本身没接收，另一种是接收了但抓取队列没动。两者的处理路径不同，混在一起会让后续所有对比失去意义。
- 提交未生效：接口返回错误、配额已满、格式不合法、站点地图未被读取。此时“未发现”是提交环节的问题，与页面本身无关。
- 提交已生效但未抓取：接口确认接收，但日志里没有对应的抓取请求，或抓取请求被 robots.txt 拦截、返回非 200。此时问题在抓取可达性。
- 已抓取但未索引：抓取日志正常，索引状态仍为“已发现未编入”。这是第三层问题，不要和前两层合并统计。
判断方法：拉取提交接口的响应记录和服务器访问日志，按 URL 逐一比对。如果某一批 URL 的提交响应全部成功，但访问日志里完全没有对应请求，那这批的“未发现”属于抓取未触发，而不是提交失败。这一步做完再进入分组，否则对照组里会混入本不该参与比较的样本。
按提交渠道分层，而不是按页面类型分层
常见的错误做法是按页面类型分组——比如把商品页放一组、文章页放一组，然后比较两组的发现率。但页面类型本身就与内链深度、更新频率、模板结构相关，这些因素会同时影响发现率。用页面类型分组，等于把提交效果和页面先天条件混在一起，无法分离。
正确的分层变量应该是提交渠道。例如：
- 层 A：通过站点地图提交的 URL
- 层 B：通过单条提交接口逐条推送的 URL
- 层 C：既在站点地图中、又通过接口推送的 URL
在每一层内部，再随机抽取一半作为对照组（不额外做任何提交动作，维持原有状态），另一半作为处理组（追加一次提交动作）。这样每一层内部的页面在分层变量上是同质的，差异只来自“是否追加了这次提交”。
需要说明的是，站点地图不保证收录，接口提交也不保证抓取。对照组和处理组的差异只能说明“这次提交动作是否与发现率变化相关”，不能证明提交本身导致了收录。
随机化的前提条件与常见失效情形
随机划分对照组有一个硬前提：两组页面在提交之前没有系统性差异。如果做不到，随机化就只是形式上的。
以下几种情形会让随机分组失效：
- URL 本身携带可被系统识别的优先级信号，比如带参数的 URL 和不带参数的 URL 被分到了不同组。这时应按参数模式先分层，再在层内随机。
- 页面发布时间不同。新发布的页面和已存在数月的页面，发现速度本身就有差异。应按发布时间窗口分层。
- 某一组恰好集中在内链较浅的位置。如果内链深度与分组相关，对比结果会偏向内链更好的那一组。
一个可操作的检查动作：分组完成后，先比较两组在“内链数量”“页面年龄”“是否在站点地图中”这三个维度上的分布。如果某一维度上两组差异明显，说明随机化没有生效，需要重新按该维度分层后再随机。
一个注明假设的比较方法示例
假设某站点有 2000 个商品页，其中 600 个已被发现，1400 个未发现。运营者想判断“追加一次接口提交”是否与发现率变化相关。以下是假设性的操作步骤，数字仅用于说明比较方法，不代表任何实际结果：
- 第一步：把 1400 个未发现 URL 按提交渠道分成三层——仅站点地图、仅接口、两者都有。
- 第二步：在每层内随机取一半作为处理组，追加一次接口提交；另一半作为对照组，不做额外动作。
- 第三步：等待一个固定的观察窗口（例如两周），记录两组中新增“已抓取”和新增“已索引”的数量。
- 第四步：分别计算每层的处理组与对照组的差异。如果某一层处理组明显高于对照组，且其他层没有类似差异，说明该层的提交渠道可能是关键变量。
这个方法的局限在于：观察窗口内可能发生其他变化（如站点整体改版、外链增加），这些变化如果只影响其中一组，就会污染对比。因此观察窗口内应尽量避免对其中一组做其他改动。
根据对比结果决定保留、改写还是退出
拿到分层对比结果后，决策取决于差异出现在哪一层：
- 保留：如果处理组在多个层中都稳定高于对照组，说明追加提交这个动作本身与发现率提升相关，可以保留该提交方式并扩大范围。
- 改写：如果差异只出现在某一层，比如仅站点地图层有效、仅接口层无效，说明问题可能出在接口提交的格式或频率上，应优先改写接口提交的参数或节奏，而不是放弃提交。
- 退出：如果各层处理组与对照组都没有可区分的差异，且提交响应和抓取日志都正常，说明当前提交动作对这批页面没有额外作用。此时应把精力转向内链结构或页面内容质量，而不是继续加大提交量。
需要提醒的是，提交量或抓取量归零不能单独证明处理正确。抓取量下降的合理解释还包括服务器响应变慢、robots.txt 变更、站点整体流量波动等。在做出退出判断之前，应先排除这些替代解释。HTTPS 不保证安全无漏洞或排名，不同搜索引擎对提交接口的支持情况也须分别核查，不能把某一渠道的对比结论直接套用到所有渠道。
