死链检测方法批量页面只有一部分被发现时怎样划分对照组
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9a2035a17256.html
📄
死链检测方法批量页面只有一部分被发现时怎样划分对照组
把页面分成“被发现”和“未被发现”两组直接比较，是最容易做错的一步。正确做法是先按可观测的差异维度分层，再在每层内部划分对照组；如果差异维度本身与抓取路径高度相关，直接分组会把路径差异误判成页面质量差异。下面用一个假设情境说明判断过程。
先确认“被发现”指的是哪一层
死链检测方法里，“被发现”至少可能指三种不同状态：链接被爬虫请求过、请求返回了非 200 状态、以及该状态被记录进报告。三者不是一回事。假设某站有 5000 个商品页，其中 800 个出现在站内列表页，4200 个只靠站内搜索或参数拼接到达。若只统计“报告里出现的死链”，那么未被列表页覆盖的 4200 个页面天然缺少被请求机会，此时把它们和 800 个列表页页面放进同一对照组，比较结果反映的是入口差异，而不是页面本身的链接健康度。
因此第一步是给每个页面标注它实际可被发现的路径：站内链接、站点地图、历史外链、参数生成。只有路径信息齐全，后面的分组才有意义。缺少路径标注时，任何“发现率差异”都无法归因。
按入口路径分层，而不是按结果分组
分层的关键是选一个在检测开始前就存在、且不依赖检测结果的维度。入口路径符合这个条件：它由站点结构决定，不受本次检测影响。可以这样操作：
- 把页面按主要入口来源分成若干层，例如“列表页可达”“仅站点地图可达”“仅外链可达”“仅参数可达”。
- 在每一层内部，再随机抽取等量页面作为对照组和观察组，两组在层级、模板、发布时间上尽量接近。
- 对两组施加相同的检测动作，例如相同的请求频率、相同的超时阈值、相同的重定向跟随规则。
这样做的结果是：如果某一层内部两组表现接近，说明差异更可能来自入口路径；如果同一层内部两组出现明显分化，才值得继续追查页面级因素。这个动作直接影响下一步——它决定了你是去修入口覆盖，还是去查单页配置。
哪些差异不能拿来分组
有几类维度看似合理，实际会把因果关系颠倒：
- 是否已被报告标记为死链：这是检测结果，用它分组等于用结果解释结果。
- 是否在站点地图中：站点地图只表示你声明了它，不保证被抓取，用它分组会把声明差异当成抓取差异。
- 是否被 robots.txt 限制：抓取限制不等于索引移除，也不等于页面失效；把它当作“已处理”会掩盖真实死链。
- 页面是否有 HTTPS：HTTPS 不保证页面可访问或链接有效，用它分组对死链判断没有区分力。
如果确实需要按上述维度观察，应把它们作为分层内的记录项，而不是分组依据。
一个假设情境的完整推演
假设某站改版后，旧栏目页批量 301 到新栏目，检测报告显示 1200 个旧链接里只有 300 个被请求到。团队最初按“已请求/未请求”分成两组，发现未请求组的页面平均字数更少，于是判断“内容单薄导致不被抓取”。
换一种做法：先按入口路径分层。结果发现未请求的 900 个页面几乎全部只存在于旧版站点地图，而新版列表页已不再链接它们。在“仅站点地图可达”这一层内部，随机取 100 个页面作为观察组，另取 100 个来自同一模板、同一发布批次的页面作为对照组，两组都通过相同方式提交检测。观察组和对照组的请求结果接近，说明字数差异不是主因，入口缺失才是。
据此，下一步动作从“改写页面内容”改为“修复入口覆盖”：在相关列表页或导航中恢复必要链接，或确认这些页面是否应整体下线。动作改变后，再重新分层检测，才能判断修复是否有效。这个例子是假设的，数字仅用于说明比较方法。
对照组成立需要满足的条件
要让分组结论站得住，至少满足三点：
- 分组维度在检测前已确定，且不来自检测输出。
- 两组除目标变量外，在模板、入口层、发布时间上尽量可比。
- 检测动作对两组一致，包括请求方式、阈值和记录口径。
如果某层样本量太小，无法形成有效对照，就不要强行分组，而应把它标为“证据不足”，单独列出待确认。请求量、抓取量或某项统计归零，也不能单独证明处理正确——它也可能来自入口被移除、检测未覆盖该路径、或记录环节遗漏。把这几类解释分别列出并逐一排除，比直接下结论更可靠。
对跨搜索引擎的场景，还需分别核查各引擎对站点地图、参数页和重定向的处理差异，不能用一个引擎的观察结果直接套用到另一个。对照组划分完成后，先在小范围内验证分层是否稳定，再决定是否扩大到全量检测，这一步能避免把入口问题误修成内容问题。
