网站死链检查，怎样安排最小修复试验
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0d61e2d1c565.html
📄
网站死链检查，怎样安排最小修复试验
最小修复试验的做法是：先选一小批有代表性的死链，只改一个变量，再用可复核的抓取结果判断修复是否生效。它的目的不是立刻清空全部死链，而是用最低成本验证“原因判断是否正确、修复方式是否可行”。如果试验组修复后仍然返回错误状态，就不应把同一方案直接铺到全站。
先确定交付结果，再倒推资料
试验开始前要明确交付物：一份修复前后对照表。表中至少包含原始URL、链接所在页面、HTTP状态码、发现方式、拟采用的处理方式、修复后状态码、复测日期。没有这份对照表，修复就只是“改过了”，无法判断是否真的解决。
倒推需要的资料包括：一份近期抓取得到的死链清单、服务器访问日志或状态码记录、页面模板与链接来源、可发布修改的权限。若死链来自站内导航或模板，修复一处可能影响大量页面；若来自正文中的外部链接，处理方式则完全不同。资料不足时，试验范围应缩得更小。
按死链来源分组，而不是按数量平均抽样
死链的成因不同，修复动作也不同。建议先分组，再从每组中各取少量样本：
- 站内链接指向已删除页面：可能原因是URL变更、目录调整或内容下线。
- 站内链接拼写或大小写错误：通常集中在手工添加的正文链接。
- 外部链接目标失效：对方页面迁移、关闭或拒绝访问。
- 服务器配置或重定向链问题：如http与https混用、尾斜杠处理不一致、重定向成环。
分组后再抽样，可以避免把“模板问题”和“单条外链问题”混在一起，导致修复效果无法解释。每组样本不必多，够覆盖一种成因即可。
一次只改一个变量，并写清验收标准
最小试验的关键是控制变量。假设某组死链的原因是旧URL没有做重定向，那么试验组只加重定向，不同时修改站点地图、robots.txt或页面模板。验收标准可以写成：
- 访问试验组每个原始URL，最终落到状态码200的目标页。
- 重定向链不超过一跳，且不出现循环。
- 目标页内容与原始链接的预期主题一致，而不是统一跳转到首页。
- 复测时使用同一抓取工具或同一命令行方法，避免工具差异干扰判断。
如果试验组通过，再按同一规则处理同组其余死链；如果不通过，先回到原因判断，而不是扩大修复范围。这里要注意，robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录，因此不能用“已提交站点地图”当作死链已修复的证据。
用可复核的检查项确认结果
复测时至少核对以下项目：原始URL返回的状态码、最终URL、重定向次数、目标页是否可访问、链接所在页面是否已更新。可以用命令行工具查看响应头，例如：
curl -I -L https://example.com/old-page
输出中关注第一行状态码和后续跳转位置。若第一行是301或302，最终返回200，说明跳转生效；若最终仍是404，说明目标地址或服务器规则仍有问题。对于外链失效，若对方页面确实不存在，可考虑替换为同类可访问资源或移除链接，而不是强行重定向到无关页面。
明确责任与适用条件
试验需要有人负责修改、有人负责复测，最好不是同一人，以减少“改完即认为成功”的偏差。适用条件是：死链数量较多、成因不完全清楚、全量修复风险较高。若只有一两条死链且原因明确，可以直接修复，不必专门设计试验。
下一步是选定一个成因分组，建立修复前后对照表，完成一轮最小修复与复测，再决定是否扩大到同组其余URL。
