📍 WDQWDWQD987AAAAA:216.73.216.116
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2d162bbf3adb.html
📄

死链工具，检查前需要准备哪些信息

用死链工具检查前，至少需要准备四类信息：待检查的网址范围、允许抓取与访问的权限、判断死链的标准，以及结果交付给谁、按什么格式验收。准备得越具体，多人协作时越不容易返工。下面按交付结果倒推，逐项说明。

先明确检查范围：哪些网址要进工具，哪些不进

死链工具只能对给定范围内的链接给出结果，范围模糊会导致漏检或重复劳动。开工前先确定以下内容：

• 起始地址清单：首页、栏目页、站点地图中的主要入口，或某次改版涉及的旧路径。
• 层级与数量上限：抓取到第几层、最多检查多少个页面，避免工具跑出预期之外的数据量。
• 是否包含子域、参数页、分页、多语言目录。这些边界不写清，不同人跑出的结果会对不上。
• 排除项：登录后页面、后台、测试环境、第三方跳转链接等，明确哪些不纳入本轮检查。

判断依据是：如果两个人用同一份范围跑出的链接总数差异明显，说明范围描述还不够具体，应先补齐再开始。

确认访问权限与抓取条件

权限问题会让死链工具的结果失真，甚至把“无法访问”误判成“链接已失效”。需要提前准备：

• 目标站点是否允许抓取。查看 robots.txt 中的限制规则，但要注意，robots.txt 的抓取限制不等于可靠的索引移除，它只影响抓取行为，不能替代对具体链接状态的核查。
• 是否需要登录、验证码或特定请求头。若需要，应提供测试账号或说明工具无法覆盖这部分页面。
• 访问频率与并发限制，避免对生产环境造成压力。多人协作时应约定由谁统一执行，而不是各自重复跑。
• 是否有站点地图可用。站点地图能帮助发现入口，但不保证页面被收录，也不能替代对链接返回状态的实测。

如果站点使用 HTTPS，也不要默认它“安全无问题”。HTTPS 不保证安全无漏洞或排名，死链检查关注的是链接可达性与返回状态，证书与安全问题应另行核查。

统一死链判定标准与数据字段

多人协作最常见的返工来源，是不同人对“死链”的理解不一致。检查前应约定：

1. 哪些状态码计入死链：常见做法是 404、410 归为失效；403、401 归为权限问题；5xx 归为服务端异常，需复测后再定性。
2. 软 404 是否纳入：页面返回 200 但内容为空或提示不存在，这类情况需要单独标注，不能直接等同于 404。
3. 重定向如何处理：301、302 是否算问题，跳转链过长或跳转到无关页面是否单独列出。
4. 输出字段：链接地址、来源页面、状态码、发现时间、责任人、处理状态。字段统一，后续分派和验收才顺畅。

需要区分“可能原因”和“已经定位的原因”。同一现象可能有多种解释，例如某个链接返回 404，可能是页面确实被删除，也可能是路径大小写不一致、服务器规则误配或抓取时网络波动。没有复测前，不要断言唯一原因。

落实责任分工与验收方式

从交付结果倒推，检查前就要确定谁负责什么、结果交给谁：

• 执行人：负责配置范围、运行死链工具、导出原始结果。
• 复核人：负责抽样复测状态码，剔除误报，确认哪些是真实死链。
• 处理人：负责修复、替换或移除链接，并记录处理方式。
• 验收人：按约定字段和标准检查结果是否完整，确认无遗漏后关闭任务。

验收时可以直接核对：链接总数是否与范围描述一致，状态码分类是否符合约定，误报是否已标注原因。若结果缺少来源页面或责任人字段，通常需要退回补充，而不是直接进入修复环节。

可以直接执行的准备清单

假设一次改版后需要检查旧路径是否失效，可以按下面步骤准备，再交给死链工具：

1. 列出旧路径清单和新路径对照表，标明哪些应保留、哪些应重定向、哪些可删除。
2. 确认 robots.txt 是否允许抓取这些路径，并记录不允许抓取的部分，说明其不在本轮检查范围内。
3. 约定状态码分类规则和输出字段，写成一份简短的检查说明。
4. 指定执行人、复核人和验收人，约定结果提交格式与截止时间。

适用条件是：范围明确、权限可获取、判定标准已统一。如果缺少其中任何一项，先补齐再运行工具，否则结果很难直接用于修复和验收。下一步，把这份清单与实际链接范围对照一遍，确认无误后再开始检查。