死链查询：怎样安排最小修复试验
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /df61b338fbb0.html
📄
死链查询：怎样安排最小修复试验
最小修复试验的做法是：先选一小批已确认的死链，只修正其中一部分，然后用同一套检查方法对比修复前后的结果，确认修复有效再扩大范围。它的目的不是一次性清空所有死链，而是在交接或验收前，用最小成本证明修复方案能产生可检查、可复现的效果。
准备阶段：先固定样本和检查口径
死链查询的结果必须先落到一份可复核的清单上，否则试验无法对比。清单至少记录四项：出现死链的页面地址、死链目标地址、服务器返回状态、发现方式。状态码用工具或命令行获取，不要只凭页面显示判断。
样本选择有两条原则：一是数量少，建议控制在五到二十条之间；二是类型集中，比如全部是站内链接指向已删除页面，不要混入外链失效、重定向链、服务器超时等不同原因。类型混杂会让修复后的对比失去意义。
检查口径也要提前写死，包括：用哪个工具或命令、在什么网络环境下执行、判断“修复成功”的标准是什么。常见标准是目标地址返回 200 或 301 到有效页面，并且原页面上的链接可点击到达。标准一旦确定，试验过程中不要改。
实施阶段：只改一半，保留对照组
把样本分成两组：试验组执行修复，对照组暂不动。修复方式按死链原因选择，常见对应关系如下：
- 目标页面已删除且无替代内容：返回 410，或从原页面移除该链接。
- 目标页面换了地址：设置 301 指向新地址，并更新原页面链接。
- 链接写错：直接改正链接地址。
- 目标站暂时不可用：先确认是否恢复，不要急于删除链接。
这一步最关键的是保留对照组。只改试验组，才能把“修复带来的变化”和“时间推移、缓存刷新、抓取波动带来的变化”区分开。如果全部一起改，验收时无法说明结果来自修复本身。
修复动作要留记录：改了哪个文件或后台条目、改成什么、什么时间生效。交接场景下，这份记录本身就是验收材料的一部分。
验证阶段：用同一方法复测并对比
修复生效后，用准备阶段确定的同一方法复测两组。对比时看三类结果：
- 试验组死链是否消失或转为有效跳转；
- 对照组是否保持原状，若也发生变化，说明存在修复之外的因素；
- 修复是否引入新问题，比如重定向链过长、跳转到无关页面、返回状态不稳定。
判断标准要区分“可能原因”和“已经定位的原因”。复测后试验组仍返回错误，可能是缓存未刷新、修复未部署、目标地址本身仍不可用，需要逐项排查后再下结论，不要直接认定修复方案无效。
如果试验组按预期改善、对照组基本不变，说明方案可复制，可以扩大修复范围。如果两组都变化，需要先排除环境因素再重做一轮。
维护阶段：把检查固化成例行项
试验通过后，把这次使用的检查方法保留下来，定期对全站执行一次死链查询。重点关注三类位置：导航和页脚等全站链接、近期改版过的栏目、已下线内容的旧入口。
维护时注意两点边界：robots.txt 的抓取限制不等于可靠的索引移除，屏蔽抓取和让死链从索引中消失是两件事；站点地图也不保证收录，提交站点地图不能替代修复死链本身。若死链涉及外部搜索引擎的收录表现，需要分别到对应搜索引擎的站长工具中核查，不同搜索引擎的支持情况要分开确认。
下一步：按上面的准备清单，从最近一次全站死链查询结果中挑出五到十条同类型死链，建立试验组和对照组，执行一轮最小修复试验并记录复测结果。
