内链外链：批量页面只有一部分被发现时怎样划分对照组
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b6c244aa0900.html
📄
内链外链：批量页面只有一部分被发现时怎样划分对照组
先给结论：把“被发现”当成一个二值结果来分组，通常会得到一组假对照。更稳妥的做法是按页面进入发现路径的方式划分——从站点地图进入、从内链进入、从外链进入，各自成组；再在同一组内比较处理前后的变化。如果无法还原进入路径，就退而按“是否被至少两个独立来源指向”分组，这比按是否被发现分组更能隔离内链和外链的作用。
先确认“只有一部分被发现”是哪一类部分
批量页面里一部分进入发现队列、另一部分没有，原因通常不是随机的。常见有三类：一是站点地图提交后只有部分条目被处理；二是内链结构本身不均匀，导航、分页、相关推荐只覆盖了子集；三是外部链接集中指向少数页面。这三类对应完全不同的对照组划分方式。
判断依据可以从服务器日志或抓取记录里找：看未发现的那批页面是否从未收到过任何抓取请求，还是收到过但被 robots.txt 拦下，或是抓取后没有进入后续处理。robots.txt 的抓取限制不等于可靠的索引移除，被拦下的页面可能仍通过外链被外部系统感知；站点地图也不保证收录。因此“提交了但没被发现”和“从未出现在任何发现路径里”要分开对待，不能合并成一个对照组。
条件一：能还原发现路径时，按来源分层设组
如果日志或抓取记录能区分页面是被谁发现的，就按来源分成三组：仅站点地图组、仅内链组、仅外链组。每组内部再随机抽一半作为处理组、一半作为对照，处理动作只施加在实验组上。
具体动作：假设有一批旧内容需要退出，但其中一部分仍有价值。先保留有价值页面的内链入口，把准备退出的页面从导航和相关推荐里移除，然后观察两组在抓取请求上的差异。结果是：如果仅内链组的抓取请求明显下降而仅站点地图组变化不大，说明这批页面的发现主要依赖内链，下一步就该优先修复内链而不是反复重提站点地图。
这里的关键是，处理动作必须只作用于一个来源。同时改内链又改站点地图，就无法判断哪一项起了作用。外链组通常最难控制，因为外部链接不受自己支配，这一组更适合作为观察组而非实验组。
条件二：无法还原路径时，按来源重叠度分组
很多旧系统或旧合作关系退出后，日志不完整，无法还原每个页面是被哪条路径发现的。这时改用一个可操作的代理指标：页面被多少个独立来源指向——站点地图条目算一个来源，站内至少一条内链算一个来源，至少一条外链算一个来源。
按重叠度分成两组：单一来源组（只被一个来源指向）和多来源组（被两个及以上来源指向）。这个划分的好处是，单一来源组里每个页面的发现都依赖唯一通道，一旦该通道失效，页面就会掉出发现队列，因果链更清晰；多来源组则用来观察冗余是否真的起到保护作用。
实施时先只对单一来源组做处理，例如补一条内链或补一个站点地图条目，然后看这批页面的抓取请求是否出现变化。如果变化只出现在被补了内链的那部分，说明内链是这批页面的有效发现通道，后续动作应向内链倾斜；如果补站点地图条目后同样出现变化，则说明两条通道都有效，可以按成本选择。
需要排除的例外与常见误判
- 抓取请求归零不能单独证明页面已退出发现队列。可能是抓取预算临时收紧、服务器响应变慢，或该批页面临时被降级处理。需要结合其他来源的请求记录一起看。
- 站点地图里条目数量不变，不代表这些条目都在被处理。有些条目可能长期处于待处理状态，需要单独检查。
- 外链来源减少时，页面可能仍通过内链被发现。反过来，内链被移除后，外链仍可能维持发现。两个来源的效应会互相掩盖，所以对照组要尽量只变动一个来源。
- HTTPS 与发现、索引之间没有直接保证关系，不必把它当作分组变量。
一个注明假设的短例子
假设某旧内容库有 200 个页面，日志显示其中 80 个有抓取请求、120 个没有，且无法还原具体发现路径。按来源重叠度分组后，单一来源组 90 个、多来源组 110 个。先只对单一来源组里的 45 个页面补内链，另外 45 个保持原样。观察一段时间后，如果补内链的 45 个里抓取请求增加的数量明显多于未补的 45 个，就可以把内链修复扩展到多来源组中内链较弱的部分；如果两组差异不明显，则应先检查服务器响应和抓取预算，而不是继续加内链。这个例子的数字仅用于说明比较方法，不代表任何实际结果。
划分对照组的核心不是把页面分成“被发现”和“未发现”，而是让每一组只对应一条可解释的发现通道，这样处理动作的结果才能指向下一步该改哪里。
