死链接检查前需要准备哪些信息_先备齐这五类资料再动手
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a84975e402ca.html
📄
死链接检查前需要准备哪些信息_先备齐这五类资料再动手
死链接检查前需要准备的信息，核心是让执行人不用回头找人就能独立判断“哪些链接算死链接、哪些该修、修完谁验收”。最少要备齐五类：待检查的网址范围、判定标准、历史跳转与删除记录、负责人和修改权限、验收口径。时间和人手有限时，先准备这五类，再决定先查哪一批，比直接打开工具全站扫描更省事。
第一类：待检查的网址范围，决定先查哪一批
范围不清，检查就会变成漫无目的的爬取。开工前至少要明确三点：从哪些入口开始、覆盖到哪一层、哪些目录暂时不查。
- 入口清单：首页、栏目页、站点地图中列出的主要页面，以及近期改版过的栏目。
- 覆盖深度：是只查导航和正文里的链接，还是连分页、标签页、筛选参数一起查。
- 排除项：后台、测试目录、已下线的活动页，避免把本来就不该公开的地址算进来。
如果人手有限，优先把入口清单缩到“导航 + 首页 + 近期改动页”，先拿到一批可修的结果，再决定是否扩大范围。站点地图可以作为入口参考，但它不保证页面已被收录，也不能代表全部有效地址。
第二类：判定标准，先定什么算死链接
“打不开”是笼统说法。检查前要写清判定口径，否则不同人跑出来的结果无法合并。
- HTTP 状态码口径：404、410 属于明确失效；403、429、5xx 可能只是临时拒绝或服务波动，需要复测。
- 跳转口径：301、302 指向的最终地址是否有效，跳转链是否过长。
- 软 404：页面返回 200，但内容是“已删除”“无结果”，这类要靠页面内容判断，不能只看状态码。
- robots.txt 限制：被 robots.txt 禁止抓取不等于链接失效，也不等于页面已从索引移除，两者要分开记录。
建议把判定结果分成三档：确认失效、疑似临时故障、需人工确认。这样安排任务时，确认失效的可以直接派修，疑似项先复测，避免把服务器抖动当成死链接大批量处理。
第三类：历史记录，判断该修还是该删
同一个死链接，处理方式取决于它原本指向什么。检查前尽量收集：
- 改版或迁移记录：哪些旧地址被替换成了新地址，对应关系是什么。
- 已删除内容清单：哪些页面是主动下线的，是否有替代页面。
- 外链情况：如果无法获取外链数据，至少在记录里标注“不确定”，不要默认所有死链接都值得做跳转。
有明确替代页面的，通常做 301 跳转；内容确实不再提供的，返回 410 或保留 404 更合适。没有历史记录时，先按“站内引用优先修、纯外链旧地址先观察”的顺序排任务，能减少无效工作量。
第四类：责任人与权限，决定谁能改
检查结果最终要落到修改动作上。开工前确认：谁负责导出和整理清单，谁有权改导航或模板，谁负责改正文链接，谁处理服务器层面的跳转规则。只有清单没有修改权限，检查做完也推不动。
时间紧时，把任务按“一次改动影响多少页面”排序：模板和导航里的死链接影响面大，优先修；单篇正文里的孤立死链接可以放在第二批。每项任务写清负责人和预期完成时间，避免清单在几个人之间来回传。
第五类：验收口径，修完怎么确认
验收不是“改过了”就算完成。提前约定检查项：
- 原地址返回的状态码是否符合预期，跳转是否指向有效页面。
- 跳转链是否只有一跳，最终页面内容是否与链接语境相关。
- 同一批清单复测后，确认失效项是否清零，疑似项是否给出结论。
- 记录修改时间、修改人和复测结果，便于下一轮检查对比。
举个假设例子：某栏目页导航指向一个已下线活动页，返回 404，同时该活动有新的替代页面。准备信息时若已记录替代地址，执行人可以直接加 301 并复测；若没有记录，就只能先标记待确认，任务会多卡一轮。
下一步建议：按上面五类列一张准备清单，逐项标注“已有 / 缺失 / 谁提供”。缺失项超过两项时，先补齐再开始扫描，通常比边查边找资料更快。
