网站死链：怎样安排最小修复试验
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /be6e07d29ddf.html
📄
网站死链：怎样安排最小修复试验
最小修复试验的核心是：先选一小批有代表性的死链，只做一轮“发现—改链或重定向—复验—记录”的闭环，用可交付的结果验证流程是否跑得通，再决定是否扩大范围。它不是先修全站，也不是先争论用哪个工具，而是先让团队在最小成本下拿到一份可验收的修复记录。
先确定交付物，再倒推需要谁参与
多人协作最容易返工的地方，是每个人都以为自己在修死链，但交付标准不同。建议先把本轮试验的交付物写清楚，至少包含四项：死链清单、每条的处置结论、修改后的验证结果、未处理项及原因。清单里每条死链应记录来源页面、目标地址、HTTP 状态、发现方式、负责人和复验日期。
倒推下来，参与角色通常只有三类：发现者负责导出和去重，处置者负责改链接或配置重定向，验收者负责复验并确认记录完整。同一人可兼任，但验收最好不交给处置者本人，否则容易把“已改”当成“已生效”。
用一份小样本定义试验边界
样本不要随机抓，按死链成因分层更有判断价值。可以每类选几条：导航或页脚里的站内死链、正文里的站内死链、指向外部站点的死链、带参数的旧地址、返回 404 但仍有流量的旧页面。假设某站共发现 300 条死链，第一轮只取 20 条，其中站内 10 条、站外 5 条、旧地址 5 条。这个数量是示例，不是标准值，实际按团队一天内能完成复验的量来定。
边界要同时写清“本轮不做什么”：不批量改模板、不动 robots.txt、不提交全量站点地图、不处理需要产品决策的页面合并。把这些排除项写进任务说明，能明显减少跨角色返工。
按处置类型分工，而不是按链接条数分工
死链的处置通常只有几种：目标页仍存在则改链；目标页已迁移则做 301 重定向；目标页彻底下线且无替代内容，则保留 404 或改为 410；外部链接失效则删除、替换或标注。按类型分工比按条数分工更清楚，因为同一类处置的验证方法一致。
- 改链任务：交付修改后的页面地址和修改前后的目标地址对照。
- 重定向任务：交付重定向规则、生效范围，以及用
curl -I或浏览器开发者工具看到的最终状态码和最终地址。 - 保留 404 任务：交付判断依据，例如该页面无对应替代内容、无站内入口、无外部引用价值。
- 外链任务：交付替换来源或删除理由，避免只写“已处理”。
这里要区分“可能原因”和“已经定位的原因”。某条链接返回 404，可能是目标页被删、路径拼写错误、大小写不一致，也可能是服务器规则误伤。只有复验到具体状态码和最终地址后，才能写成已定位原因。
验收要看结果，不看“已修改”三个字
验收项建议固定为四条：原地址是否还能复现问题；新地址或重定向是否返回预期状态；来源页面是否已不再指向失效目标；记录是否能让没参与的人独立复现。复验时至少检查一次真实请求结果，而不是只看后台任务状态。
需要提醒的是，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。因此本轮试验的验收标准应落在“链接可用性和记录完整性”上，不要写成“保证被搜索引擎移除”或“保证排名恢复”。如果涉及搜索引擎侧的表现，应把它列为后续观察项，而不是本轮修复的验收条件。
一轮结束后，用三个问题决定是否扩大
- 20 条样本里，能否在不追问原作者的情况下独立复验？能，说明记录格式可用。
- 同类死链的处置结论是否一致？一致，说明规则可以复用。
- 返工主要来自判断分歧还是工具误差？若是判断分歧，先补规则；若是工具误差，先统一发现和复验方法。
三个问题都过关，再把样本量按同一分层比例扩大，并保留每批的复验记录。下一步可以直接做一件事：把本轮 20 条样本的清单另存为模板，补上负责人、复验日期和未处理原因三列，交给下一位执行者按同样格式填写。
