死链检查工具，怎样安排最小修复试验
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /28bd16d1794b.html
📄
死链检查工具，怎样安排最小修复试验
最小修复试验的目标不是一次清空所有死链，而是用最小改动验证修复链路是否有效。交付结果应是：一份可复现的死链样本、一项修复动作、一份前后对比记录，以及明确的验收判断。做法上，先选少量有代表性的死链，只改一种原因，再用同一工具复查，确认状态变化符合预期，然后才推广到全站。
从交付结果倒推需要准备什么
先明确要交出的东西：修复前后的死链清单、每条死链的原因分类、实际执行的改动、复查结果。对应需要的资料包括：一份由死链检查工具导出的报告、页面与链接的对应关系、可修改的源文件或跳转配置、复查用的同一工具与同一抓取范围。责任上要分清谁改内容、谁改服务器或跳转规则、谁负责复查。验收标准建议写成可判断的条件，例如“样本中指向已删除页面的内链，复查后不再返回 404，且落到内容相关的新页面”。
选样本：让试验能说明问题
从报告里挑 5 到 20 条即可，但要覆盖不同原因，避免只挑最容易的一类。常见原因可以这样分：
- 内链指向已删除页面，返回 404。
- 外链目标消失，页面本身正常。
- 链接拼写或大小写错误，实际页面存在。
- 跳转链经过多级 301 后失效。
- 被 robots.txt 限制抓取，工具误报为不可访问。
最后一类要单独说明：robots.txt 的抓取限制不等于可靠的索引移除，也不等于链接真的坏了。遇到这类报告，先确认是抓取被限制，还是目标确实返回错误状态。样本里保留一两条这类情况，能帮助区分“工具报错”和“真实死链”。
只改一种原因，再复查
假设样本中有 10 条内链 404，其中 6 条指向同一批已下架页面。最小试验可以只做一件事：把这 6 条内链改到内容最接近的现存页面，其余 4 条暂不动。改动后按原抓取范围重新检查，对比三件事：
- 这 6 条是否还出现在死链报告中。
- 目标页面是否返回 200，且内容与链接语境相关。
- 未改动的 4 条是否仍被报告，用来确认复查范围没有变化。
如果 6 条消失、4 条仍在，说明修复动作和复查方法都有效，可以扩大范围。如果 6 条仍被报告，先查目标页面状态码、跳转链和抓取权限，再判断是修复没生效还是工具范围不一致。这里不要断言唯一原因，一项现象可能有多种解释。
用对比依据判断能不能推广
推广前需要两组对比：修复前与修复后的死链数量、样本内与样本外的变化。判断条件可以写成：样本内目标死链全部消失，样本外未修复项保持不变，且没有新增死链。若新增死链，说明改动可能引入了新链接或跳转问题，应暂停推广并回查改动记录。
对于跳转类修复，还要单独核对：跳转目标是否返回 200、是否只跳一次、是否指向内容相关页面。HTTPS 不保证安全无漏洞或排名，所以不要把“改成 HTTPS”当作死链修复的通用答案。站点地图也不保证收录，提交站点地图不能替代逐条修复。
把试验固化成可重复的检查项
试验通过后，把以下检查项写进流程：固定抓取范围与工具设置；每次改动只处理一种原因；保留改动前后的报告；复查时确认未改动项数量一致；对 robots.txt 限制、跳转链、外链失效分别记录判断依据。不同搜索引擎对跳转和抓取限制的支持情况须分别核查，不要把一次工具复查的结果当成所有搜索引擎的最终结论。
下一步，从当前死链报告中选出 10 条同一原因的死链，按上面的步骤做一次修复与复查，把结果记录成模板，再决定是否扩大到全部死链。
