死链检查方法，怎样形成可复用检查清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /49ddfc013dd8.html
📄
死链检查方法，怎样形成可复用检查清单
把死链检查做成可复用清单，核心不是记更多工具，而是固定“发现—判断—处理—复查”四步，并为每一步写下可核对的输入、输出和责任人。这样换一个人、换一个站点，也能按同一顺序执行，不必每次重新摸索。
先明确检查对象：哪些链接值得进清单
死链检查方法要落地，第一步是限定范围，否则清单会无限膨胀。建议把链接分成四类，每类单独列项：
- 站内导航与页脚链接：影响全站访问路径，优先处理。
- 正文内链：数量多、变动频繁，按栏目或模板分批检查。
- 外链：指向其他站点的链接，失效判断依赖对方状态，处理优先级可后置。
- 资源链接：图片、脚本、样式、下载文件的路径，常被忽略但同样产生错误响应。
清单里为每类写明“谁负责、多久检查一次、用什么方式获取链接列表”。例如导航链接由模板维护者负责，正文内链由内容编辑在发布前抽查。范围清楚，后续判断才有依据。
观察与判断：区分“可能原因”和“已经定位的原因”
发现一个链接返回错误，不要立刻断定是链接写错。可能原因包括：路径拼写错误、页面已删除、服务器临时故障、权限限制、重定向链过长、对方站点变更。只有实际请求并看到响应状态，才能把“可能”变成“已定位”。
清单中可固定一条判断记录：请求的完整地址、返回状态码、请求时间、是否跟随重定向、最终落地地址。状态码含义可按通用规范理解：404 通常表示资源不存在，410 表示已明确移除，5xx 多为服务端问题，3xx 表示发生了跳转。不同搜索引擎对状态码的处理方式需要分别核查，不能用一个平台的表现推断另一个平台。
还要注意两点边界：robots.txt 的抓取限制不等于可靠的索引移除，链接能访问不代表一定被收录；站点地图也不保证收录。因此死链清单应聚焦“链接是否可达、是否指向预期目标”，不要把它扩展成收录保证清单。
处理：按影响和成本排序，而不是按发现顺序
时间和人手有限时，处理顺序建议用两个维度判断：影响面（是否阻断主要访问路径、是否出现在多个页面）和修复成本（改一处模板还是逐条改内容）。清单可为每条死链标注这两项，再决定动作：
- 链接写错：直接改为正确地址，改完记录修改位置。
- 页面已迁移：设置到新地址的重定向，并更新内链指向新地址，避免长期依赖跳转。
- 页面确实不再需要：返回合适的状态码，并从导航、站点地图和内部推荐位中移除入口。
- 外部链接失效：若无法恢复，替换为可访问的同类来源，或移除该引用。
这里要避免一个常见误区：把所有失效链接都统一跳转到首页。对用户和后续维护都不利，也无法说明原内容去向。重定向应指向内容最接近的页面。
复查：让清单能重复使用
处理完成后，清单必须留下复查项，否则下一次检查仍会从零开始。建议固定三个复查动作：
- 重新请求已修改的链接，确认返回预期状态和最终地址。
- 检查同一模板或同一批内容中是否还有相同模式的链接，避免只修一处。
- 记录本次新增、已修复、待观察的数量，作为下次检查的起点。
复查周期可按站点更新频率设定：更新频繁的栏目缩短周期，长期稳定的页面可延长。周期本身不是重点，重点是每次检查都使用同一份清单结构和同一套判断记录。
可直接套用的一页清单结构
把上述内容压缩成一页，字段包括：链接地址、所在页面、链接类型、请求状态、是否重定向、最终地址、可能原因、已定位原因、影响面、修复动作、负责人、复查日期、复查结果。每次检查复制这份结构，填入新数据即可。
判断结果时遵循一条简单规则：状态异常且影响主要访问路径的，先处理；状态异常但仅出现在低频页面的，排入下一批；状态正常但指向内容已过时的，单独标记为内容更新项，不混入死链修复。
下一步，选一个栏目或模板，用这份清单完整跑一遍，把实际遇到的字段缺口补进去，再固定为团队通用的检查模板。
