死链测试工具_检查前需要准备哪些信息

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

死链测试工具_检查前需要准备哪些信息

用死链测试工具检查前,至少要准备好四类信息:要检查的网址范围、允许抓取与不允许抓取的规则、期望的检查深度与频率、以及结果交给谁和按什么标准验收。缺少其中任何一项,工具跑出来的结果都可能无法直接用于修复。下面从最终要交付的结果倒推,说明每项资料为什么必需、怎么准备、以及缺了会出什么问题。

先明确检查范围:从哪些URL开始,覆盖到哪一层

死链测试工具需要一个或多个起始地址,然后顺着页面里的链接向外扩展。因此第一项要准备的就是起始URL清单。常见做法是列出站点首页、栏目页、以及你确认需要覆盖的重点页面。

还要准备抓取深度。深度设为1只检查起始页的直接链接,深度设为5可能进入大量分页、筛选参数和日历页,导致结果里混入大量无意义的动态URL。第一次接触时,建议先用浅深度跑一遍,确认结果格式符合预期,再决定是否加深。

准备规则文件与访问条件:robots.txt、登录态、限速

工具抓取时会读取站点的 robots.txt。要提前确认其中是否屏蔽了某些目录,因为被屏蔽的路径工具不会访问,也就不会报告其中的死链——这是抓取限制,不是死链不存在。如果确实需要检查被屏蔽区域,要在工具里单独配置,并确认这样做符合你的站点管理意图。

另外三项访问条件也要提前想清楚:

  1. 是否需要登录:会员区、后台页面的死链,匿名抓取看不到。需要准备测试账号,并确认账号权限范围。
  2. 请求频率:抓取过快可能给服务器造成压力,甚至被临时封禁。要准备一个可接受的并发数或间隔。
  3. User-Agent:部分站点对特定 UA 返回不同内容,要确认工具使用的 UA 能拿到真实页面。

确定判定标准:什么算死链,按什么状态码归类

“死链”在工具里通常体现为 HTTP 状态码。检查前要和结果使用方约定归类口径,否则同一份报告会有不同解读。可参考下面的对照,但具体以你的服务器实际返回为准:

这里要特别注意:一项现象可能有多个解释。例如某个 URL 返回 403,可能是页面真的受限,也可能是工具 UA 被拦截。只有复测并更换条件后仍稳定复现,才能把它当成已定位的原因。

准备验收与责任信息:谁修复、多久复测、按什么标准关闭

从交付结果倒推,还需要两类信息。第一是责任人:死链报告出来后,哪一类问题归内容编辑、哪一类归开发、哪一类归运维。第二是验收标准:是要求所有 404 清零,还是只要求重点栏目内的链接有效;复测周期是每周还是每月。

举个假设的例子:某站点第一次检查得到一份包含 200 条 404 的报告。如果事先约定“只处理站内导航和正文链接中的 404,外链和已下线活动页不计入”,实际待修数量可能降到 30 条以内;如果没有这个约定,团队会花费大量时间在无需处理的条目上。这说明验收口径必须在检查前定好,而不是拿到报告后再争论。

把这些信息整理成一份检查前清单

可以按下面的顺序逐项确认,全部有答案再启动工具:

  1. 起始 URL 列表(含子域、移动端域名)。
  2. 抓取深度与是否跟随外链。
  3. robots.txt 中需要避开的路径,以及是否有需要例外处理的区域。
  4. 登录账号与权限范围(如有)。
  5. 并发数、请求间隔、User-Agent。
  6. 状态码归类口径与复测规则。
  7. 报告接收人、修复责任人、验收标准与复测周期。

下一步建议先只填这份清单,不急着跑全站。用最小范围跑一次,核对返回的状态码与预期归类是否一致,确认无误后再扩大范围,这样后续的修复和复测才有稳定的对照基础。

图1 图2

nginx