几千个页面的死链，我们为什么自己写脚本查

2025 年 12 月我们查一个一万两千页的文档站，历史死链积了两千多条，运维照着工具列表改了一周也没改完。站一旦上万页，查死链这件事工具就不够用了。免费版爬虫有 500 个 URL 的上限，付费版能爬完，但只告诉你哪些链接返回 404，不告诉你先修哪个。我们后来写了个八十行的脚本，解决的是排序问题。

现成工具卡在哪

爬取能力不是问题，判断规则是。工具把死链列成一张表，几千行，按发现顺序排。运维看一眼就头大，最后挑前十条改，剩下的放着。

另一件事是死链的价值不一样。从导航链过去的 404 和内页深处一个没人点的 404，处理优先级差很远。工具不做这个区分，因为它不知道你的业务。

脚本做什么

先读站点地图拿到全量 URL，再爬每个页面的出链，拼成一张内链图。然后并发发 HEAD 请求，记录状态码、跳转链、响应时间。

拿到结果后排序：来源页是不是首页或导航可达、这个 404 被蜘蛛抓过多少次、来源页本身有多少条内链。这几个数据日志里都有，拼起来就是优先级。

输出一张 CSV，前二十行直接进工单。我们处理完一批，脚本再跑一次，看哪些新冒出来。

三个坑

第一，HEAD 请求会被部分防火墙拦，返回 403，看着像坏链其实没错。改用 GET，只读前几 KB 就断开。

第二，不带 UA 的请求会被当成攻击。把 UA 改成带标识的，并且把并发压到 10 以下。

第三，301 可能是一串。从 A 跳到 B 再到 C，脚本要跟到底，只报最终状态。我们见过三跳的跳转链，第一跳修了，第二跳还在。

脚本的价值在排序

发现死链这件事，工具一秒能给你一万条。修哪一千条、按什么顺序修，才需要判断。

和现成监控服务的区别

市面上的死链监控服务是持续跑的，发现新 404 就告警。它解决的是别断，不解决先修哪个。我们两边都用：监控盯线上，脚本每月跑一次做排序。

监控服务还有个副作用，老站本来就有几百条历史死链，一接上就天天告警，最后没人看。先清一轮历史再接监控，告警才有人理。

我们现在的流程是每个月跑一次，按优先级修前 100 条，剩下的记录在案，等下次重建导航时一起处理。用了半年，站内 404 从 2400 多条降到 300 条以内，被抓取浪费掉的频次也明显少了。