网站死链修复，批量页面只有一部分被发现时怎样划分对照组
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /54742fec0556.html
📄
网站死链修复，批量页面只有一部分被发现时怎样划分对照组
把已发现和未发现的页面按“是否被内部链接指向”和“是否在站点地图中”两个条件交叉分组，是判断漏抓原因的最直接办法。如果两组在抓取日志中的到达路径不同，就优先修内链；如果路径相同却只有一组被抓，则更可能是页面自身状态或内容质量问题，而不是入口缺失。
先确认“被发现”的口径，再谈分组
“被发现”至少有三种含义：出现在抓取日志里、出现在索引结果里、能被站内搜索或导航触达。三者对应的对照组完全不同。若日志显示某批URL从未被请求，对照组应围绕“链接入口”构建；若日志有请求但索引缺失，对照组应围绕“页面返回状态与内容”构建。把这两种情况混在一组，会得出“内链无效”这类错误结论。
实际操作时，先从服务器日志中导出目标批次的URL请求记录，给每条URL标记“有请求/无请求”。再给每条URL标记“有站内入链/无站内入链”“在站点地图/不在站点地图”。这样每个URL就落入四个格子之一，后续比较才有基准。
两种成立条件下的不同选择
条件一：漏抓集中在无内链的页面
如果未发现组里绝大多数URL没有任何站内入链，而已发现组普遍有入链，那么对照组应设为“有入链 vs 无入链”，而不是“新旧页面”。此时的动作是给未发现组各加至少一条来自已收录页面的正文链接，且链接锚文本与目标页主题相关。加完后观察下一轮日志：如果这些URL开始被请求，说明入口缺失是主因；如果仍无请求，则要检查链接是否被robots.txt拦截、是否落在nofollow区域、或是否位于需要交互才渲染的组件里。
注意，robots.txt 的抓取限制不等于可靠的索引移除。即使某URL被robots.txt禁止抓取，它仍可能因外部链接被索引；反过来，解除禁止也不保证马上被抓。因此这个条件里，robots.txt只作为“是否放行”的检查项，不能当作分组后的唯一解释。
条件二：漏抓页面也有内链，但入口类型不同
如果两组都有内链，区别只在入口位置，比如已发现组来自主导航或面包屑，未发现组只来自页脚或分页深处，那么对照组应设为“高权重入口 vs 低权重入口”。动作是把未发现组中一部分URL的链接从页脚移到正文或分类页主体，另一部分保持原样作为对照。观察两组的抓取变化差异，而不是只看总量。
这里要说明一个例外：站点地图不保证收录。把URL放进站点地图只代表你声明了它，不等于它会因此被请求。所以站点地图适合作为“声明存在”的补充，不能替代内链作为主要分组变量。若发现某组只靠站点地图提交、没有任何内链，应单独归为“仅声明”组，避免污染“有内链”组的结论。
用一组假设例子说明如何比较
假设有200个待修复的旧URL，其中40个出现在日志里，160个没有。按有无内链交叉后得到：有内链且被抓12个，有内链但未抓28个；无内链且被抓28个，无内链且未抓132个。这个分布说明“无内链”与“未抓”同时出现的数量远高于其他格子，优先给无内链组加正文入口是合理的第一步。加完链接后，如果下一轮日志中该组被抓数量上升，而保持原样的对照组变化不明显，就可以把内链缺失视为主要遗漏条件，继续对其他批次做同样处理。如果两组变化接近，则要回到页面状态和内容层面继续分组。
实施动作与下一步判断
- 导出目标批次URL，逐条打上“有请求/无请求”标签，作为因变量。
- 按“有内链/无内链”“在站点地图/不在站点地图”打上自变量标签，形成四格。
- 先只改一个格子里的URL，其余格子保持原样作为对照，避免同时改动多个条件。
- 等下一轮抓取日志更新后，比较改动格与对照格的请求变化，而不是比较全站总量。
- 若改动格无变化，检查链接是否可被抓取、页面是否返回正常状态码、内容是否与入口页主题一致。
需要留意的例外是：请求量、抓取量或某项统计归零，不能单独证明处理正确。它也可能是日志采样、抓取预算调整或服务器临时屏蔽造成的。因此每次只改一个变量，并保留未改动的对照组，才能把“修复动作”和“外部波动”区分开。HTTPS 不保证安全无漏洞或排名，它只是分组时的一个页面状态检查项，不应作为漏抓的主要解释。
