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

死链检查工具检查前需要准备哪些信息：从交付结果倒推清单

用死链检查工具之前，真正要准备的不是工具本身，而是四类信息：待检查范围、判定标准、处理权限与责任分工、验收方式。时间和人手有限时，先明确最终要交付什么——是一份可逐条处理的死链清单，还是只想知道某个栏目有没有问题——再倒推需要哪些输入。范围越模糊，工具跑出来的结果越难用，返工越多。

先确定检查范围：URL 从哪来

死链检查工具需要一份起点列表，否则它不知道从哪开始爬。常见的起点来源有三种，准备成本和覆盖度不同：

• 站点地图（sitemap）：准备最快，直接提交 sitemap 地址即可。但它只覆盖被列入的文件，遗漏的页面不会被检查到，而且站点地图不保证收录，也不保证其中每个 URL 都真实有效。
• 导航与栏目入口：以首页或栏目页为起点，让工具顺着链接爬取。覆盖度更接近用户实际可达路径，适合人手少、只关心主干的情况。
• 日志或后台导出列表：覆盖最全，但需要先导出、去重、清洗，前期投入最大。

准备时至少记录三件事：起点 URL 清单、是否允许工具跟随站外链接、是否需要登录才能访问的页面。最后一项尤其关键，需要登录的页面如果没准备账号或 Cookie，工具只会返回一堆 401/403，看起来像死链，其实不是。

判定标准：什么算“死链”

同一个工具跑出的结果，判定口径不同，清单长度可能差很多。检查前先定好下面几项，避免处理时反复争论：

1. 状态码范围：通常把 404、410 视为明确失效；301、302 是跳转不算死链，但跳转链路过长或指向失效页时需要单独标记。5xx 属于服务端异常，可能是临时故障，应和 404 分开处理。
2. 是否检查软 404：页面返回 200 但内容是“找不到该页”，属于软 404。是否纳入取决于工具能力，也取决于你是否愿意人工复核。
3. 跳转链深度：例如规定“跳转超过 3 次”或“最终落地页仍返回 4xx”才计入待处理项。
4. robots.txt 限制：被 robots.txt 禁止抓取的路径，工具可能直接跳过，也可能报错。要提前说明这类结果不算死链，因为 robots.txt 的抓取限制不等于可靠的索引移除，也不能据此判断页面失效。

把这几条写成一句话规则，例如“返回 404/410，或跳转后最终页为 4xx 的 URL，计入待处理清单”，后续所有人按同一标准看结果。

权限、责任与工具配置信息

范围和标准定好后，还要准备让检查能真正跑起来、结果能真正被处理的信息：

• 访问权限：如果站点有防爬策略、WAF 或频率限制，需要提前确认工具 IP 是否被允许，或临时调整限流。否则大量请求会被拦截，结果失真。
• 抓取速率设置：人手少时更要控制并发，避免拖慢线上服务。准备一个可接受的速率值，而不是默认拉满。
• 责任人：每条死链最终由谁改？内容编辑改链接、开发改路由、运维查服务，分工不同，清单字段也要跟着设计，比如加上“所属栏目”“负责人”列。
• 排除清单：已知的测试页、临时下线页、第三方统计脚本路径，提前排除，减少无效条目。

验收方式：怎么算检查完成

从交付结果倒推，最后一步是约定验收。可行的做法是：先跑一轮全量，导出清单；修复后只针对清单中的 URL 再跑一轮，确认返回码已变为 200 或合理跳转。验收标准可以是“清单中 4xx 条目清零”，也可以按优先级分批验收，例如先处理导航和首页链接，再处理深层内容页。

如果时间极其有限，建议把范围收窄到首页加主要栏目，先保证用户主路径没有死链，再逐步扩大。这样第一轮就能产出可交付的结果，而不是等全站爬完才发现方向不对。

下一步：按上面的四类信息写一份简短检查说明——范围、判定规则、责任人、验收标准各一行，交给执行人后再启动死链检查工具。