死链检测方法怎样形成可复用检查清单？按交付结果倒推
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /170ead366d0a.html
📄
死链检测方法怎样形成可复用检查清单？按交付结果倒推
把死链检测方法变成可复用检查清单，核心是从最终要交付的“死链处理结果”倒推：先明确要交付什么、谁负责、用什么数据判断、达到什么条件算验收，再把每一步写成可重复执行的条目。这样清单换一个站点、换一个人执行，仍然能得到一致结论，而不是依赖某次临时排查的经验。
先定义交付结果，再决定清单要记录什么
死链检测的交付结果通常不是“发现了一批404”，而是“每个失效URL都有去向或明确保留理由”。据此倒推，清单至少要让执行人留下四类记录：失效URL、发现来源、判断依据、处理结论。发现来源包括站内链接、站点地图、外链、日志中的抓取记录等；判断依据包括HTTP状态码、响应内容、跳转链；处理结论包括改链、删除、保留观察或提交移除。
如果交付结果只写到“已检测”，清单就无法复用，因为下一个人不知道检测范围是否完整、结论是否可追溯。把交付物写清楚，清单的字段自然就出来了。
两种处理方案：批量替换与逐条确认怎么选
形成清单时经常要比较两种处理路径，适用条件不同：
- 批量替换：适合失效URL数量大、目标新地址明确且一一对应、且替换规则可以用字符串或路径模式稳定描述的情况。执行前必须抽样验证规则，确认不会把正常URL误改。验收条件是替换后原失效URL全部返回可访问状态，且没有产生新的404。
- 逐条确认：适合失效URL数量少、目标地址需要人工判断、或一个旧URL对应多个候选新页面的情况。验收条件是每条记录都有处理人和处理时间，且结论可复查。
判断标准可以简化为：规则能否覆盖全部样本且不误伤。假设有100条失效URL，其中90条符合“旧目录整体迁移到新目录”的规律，另外10条是单独删除的页面，那么对90条用批量替换、对10条逐条确认，比全部逐条处理更省成本，也比全部批量替换更安全。这里的数字仅为说明判断方式，不是实际项目数据。
从任务到责任：清单必须写清谁做什么
可复用清单不能只有技术步骤，还要落到责任。建议按角色拆分：
- 检测执行人：运行检测、导出原始结果、标注发现来源。
- 内容或运营负责人：判断失效页面是否还有等价内容，给出改链或删除意见。
- 技术执行人：实施改链、跳转或移除，并记录变更范围。
- 验收人：复核处理后的状态码与跳转链，确认无新增失效。
如果同一人兼任多个角色，清单中仍要保留对应栏目，避免“检测完就算处理完”的遗漏。
验收条件与常见误判
验收要针对可核对的现象，而不是感觉。检查项可以包括：原失效URL是否返回预期状态；跳转是否指向与旧内容相关的页面；站内是否还有指向旧地址的链接；站点地图是否仍包含已删除URL。需要特别区分：robots.txt 的抓取限制不等于可靠的索引移除，被限制抓取不代表页面会从索引中消失；站点地图不保证收录，提交了也不等于问题已解决；HTTPS 不保证安全无漏洞或排名提升，它只是传输层的一项条件。
排查时还要区分“可能原因”和“已经定位的原因”。例如某URL返回404，可能是页面确实被删除，也可能是服务器配置错误、大小写路径不一致或重写规则冲突。只有逐项验证后，才能把原因写进清单结论，不能看到404就断言页面已被删除。
把清单固化为可重复执行的模板
最后一步是把上述内容写成固定模板，每次检测直接填写。模板至少包含：检测日期、检测范围、工具或方法、原始结果存放位置、失效URL列表、发现来源、判断依据、处理方案、责任人、完成时间、验收结果。模板中可加入一条示例条目，例如：旧地址 /old-page 返回404，站内文章仍链接该地址，确认新地址为 /new-page，执行改链，验收返回200。示例仅说明记录格式。
下一步：拿最近一次死链检测结果，按上面的字段补全成一张表。如果某条记录填不出“发现来源”或“验收结果”，说明当前流程还缺少可复用环节，应先补齐这两项再推广使用。
