站群死链检测实战：批量扫描到修复闭环，我踩过的坑和跑通的流程

站群管久了，真正让人头疼的不是内容产出跟不上，而是蜘蛛兴致勃勃爬过来，一路撞的全是死链。站群系统里的死链检测，听着像个小活，可真要放任一个子站攒下几百条死链不管，三个月后索引量掉一截是板上钉钉的事。这套流程我实打实跑了两年多，今天把扫描怎么排、批量怎么处理、闭环怎么收尾的细节摊开聊聊，给同样在管多站点的朋友当个参照。

站群里的死链，破坏力比单站更隐蔽

单站要是死链多了，站长通常能察觉到——抓取频次一掉、收录一停，马上就坐不住了。站群麻烦就麻烦在站点太分散，某个子站冒出几十条死链，后台数据面上根本看不出异常。我这套程序把链接状态码、跳转层级、抓取日志三个维度串起来之后，才发现一个跑了半年的子站，栏目页翻页参数失效，三百多条列表页全返回 404，蜘蛛每天照来不误，只是抓取预算全砸在无效地址上，正文页抓取量直接掉到原来的四成。死链检测第一步该干的，不是急着修，而是先把这种“看不见的浪费”揪到明面上来。

全量扫和增量扫，分工得拎清楚

站群做死链检测，最怕一上来就全站开爬。几十个站点同时跑全量扫描，带宽和 CPU 瞬间拉满，前台响应慢得蜘蛛都待不住。我的做法拆成两层：增量扫描每天跑，只盯新增链接和近七天有变动的页面；全量扫描按站点分组，每周轮一批，单批控制在十个站以内，调度时段放在凌晨两点到五点。这套方案的调度模块能按域名分组排队，一批跑完自动释放资源，不用人半夜爬起来盯着。

扫描深度也得卡住。列表页翻页、标签页、站内搜索结果页这类带动态参数的地址，最大抓取层级别超过三层，不然一个站能扫出几万条 URL，大半是参数组合出来的无效地址。扫描前先用规则把这些地址过滤掉，检测结果的信噪比能提不少。

状态码之外，这几类“软死链”更该盯

返回 404、410 的硬死链好认，真正麻烦的是那些状态码 200 但实际已经废掉的链接。常见的有三种：页面内容被清空只剩模板框架，蜘蛛爬进去抓不到有效文本；跳转链设成了 A 跳 B、B 又跳回 A 的循环；域名解析正常但服务器响应超过十秒，蜘蛛等不及直接放弃。这套程序在检测模块里加了响应耗时阈值和正文文本长度校验，超过 8 秒的记为慢链，正文少于 200 字符的标为疑似空页，两类单独出报表。我每周翻一遍这两张表，比光看 404 列表管用得多。

死链清单怎么变成修复动作

检测出死链只是开了个头，真正吃人力的是处理环节。我的流程是先按来源分类：内容页正文里的外链失效、栏目导航链接错误、图片和静态资源 404、分页参数失效。前三类直接进修复队列，第四类统一在模板层加参数校验规则，从源头卡死。

修复动作上，内容页里的失效外链优先做 301 指向同主题的可用页面，实在找不到替代目标的，去掉链接保留文本；导航和栏目链接错误改模板配置，一次改完所有站生效；图片资源 404 就重新上传并走 CDN 刷新。这套方案的批量替换模块支持按 URL 规则匹配，改完自动记操作日志，哪个站哪条链接什么时候改的都能回溯，后面出问题不至于互相扯皮。

修复完的闭环验证，这一步别省

改完不等于收工。我的习惯是修复动作完成后隔 48 小时跑一次定向复检，只扫这批处理过的 URL，确认状态码和内容都正常。复检通过的死链记录从待办清单里划掉，复检失败的标红重新进队列。另外每周从服务器日志里拉一次蜘蛛抓取记录，跟死链清单对一遍，看看还有没有遗漏的抓取失败地址——工具扫描总有覆盖盲区，日志是最后一道兜底。

频率上，增量扫描每天一次、全量轮扫每周一批、定向复检跟着修复节奏走、日志比对每周一次，这套节奏跑了两年，站群整体的抓取频次和索引量都稳得住。死链检测说到底是个运维习惯问题，工具能省掉人工爬站的力气，但分类、修复、复检这条链路还是得自己盯紧，偷懒一步，蜘蛛就用收录量来提醒你。