站点刚起步的时候，链接是「活的」——文章不多，改一篇顺手把相关链接都更新了。等到站内文章攒到几百篇、几百个页面，情况就变了：链接开始悄悄烂掉，而且你不会立刻发现。
烂掉的方式比想象中多。老页面改了 slug，原来的链接变 404；合并了栏目，一堆页面变成跳转链；外链的资料来源站关站了，锚文本还挂在那里；新发的文章忘了加内链，成了只有爬虫会去、用户永远到不了的「孤立页」。
这些问题的共同点是：单个都不致命，加起来很伤。用户点进去看到 404 会直接走，爬虫的抓取被浪费在死链上，本该传递的权重在跳转里损耗，孤立页连被收录的机会都很小。
这件事非常适合交给 Agent 定时做——它本质上就是一件「遍历、判断、汇总、出报告」的活。这篇讲 OpenClaw 怎么做全站死链巡检，从扫到修一条线。
先分清四类问题，它们的处理方式完全不同
很多人说「检查死链」，其实混了四件事，混在一起就会乱：
- 硬死链。返回 404 或 410 的页面。用户一点就报废，优先级最高。
- 软死链。状态码是 200，但内容其实已经没了——比如空栏目页、只剩一句「暂无内容」、或者只有导航和页脚的页面。搜索引擎不喜欢，用户也不喜欢。这类问题查状态码查不出来，要看正文长度和关键结构判断。
- 跳转链。返回 301 或 302 的内链。单次跳转还能接受，链式跳转（A 跳到 B 再跳到 C）才是问题，既慢又损耗权重。
- 孤立页。页面本身正常，但除了站点地图，没有任何站内链接指向它。这类页面很难被持续抓取，也拿不到内链传递的权重。
把这四类分开统计、分开处理，是整套方案的地基。混在一起的「死链报告」没法指导修复。
上手：六步跑通一条巡检链
第一步，拿到全站 URL 清单。三路取并集，避免漏：站点地图（覆盖大部分活跃页面）、后台的文章与分类标签列表（包含还没进 sitemap 的新页面）、以及从首页出发的分页和归档页。这一步决定巡检的覆盖度，值得多花十分钟。抓页面这件事，站内 OpenClaw 怎么接浏览器 和 怎么联网搜索 里讲的能力都用得上——前者处理需要渲染的页面，后者用来给死掉的外链找替代来源。
第二步，抽取页面里的所有链接。把每个页面正文中的链接抠出来，同时记四个信息：链接目标、锚文本、所在页面、出现位置（正文内还是导航页脚）。顺便区分内链和外链——它们的修复方式完全不同。
第三步，批量探测状态码。这是工程细节最多的一步：
- 优先用 HEAD 请求，比 GET 快得多，能少下几百兆流量；失败的再用 GET 复测一次。
- 必须限速。同时开几十个连接打自己的站，等于给自己做了一次小规模压测，配置一般的服务器很可能被打到超时，然后你会收到一堆假死链。建议低并发甚至串行，请求之间留间隔，并跑在访问量最低的时段。这既是保护服务器，也是对资源的礼貌——Cloudflare 默认拦截 AI 爬虫 那篇里讲过为什么抓取要有度，对自己站点同理。
- 区分「死了」和「暂时不通」。403、429、超时、连接被重置都不等于死链。这些要单独归类、隔一段时间重试；只有稳定返回 404 或 410 的才算硬死链。
- 记录跳转终点。遇到 3xx 时一直跟到终点，看终点是不是 200，以及中间跳了几次。
第四步，汇总成可执行的三张表。直接甩一份几千行的清单没人看，建议拆开：
- 待修复的死链清单——目标地址、状态码、出现在哪些页面、锚文本。按「出现在多少个页面」降序排，影响面大的先修。
- 跳转链清单——跳转起点、终点、跳数。跳数大于一的直接修。
- 孤立页清单——页面标题、发布时间、当前有没有内链指向。
出报告这一步可以直接接上 OpenClaw 自动做汇报材料 里那套排版流程，让 Agent 每周产一份带数据的巡检报告；想看趋势（死链数是涨还是跌），自动做数据图表 那篇里的图型选型可以直接套——这条趋势线本身就够说明维护做得好不好。
第五步，修复动作分流。这是巡检真正产生价值的环节，四类问题四条路：
- 站内死链：优先找同主题的替代页面把链接改过去；确实没有替代内容时，把旧地址做 301 指向最相关的新页面，而不是放着不管。
- 外链死链：先看对方是不是换域名了（换域名就更新新地址）；彻底没了的，找一篇同主题的可靠来源替换；找不到替代的，把锚文本降级成纯文字说明——一个点不开的链接，比没有链接更伤体验。
- 跳转链：把链接直接换成跳转终点。这一步最省事、收益最直接，建议优先做。
- 孤立页：从内容相关的旧文章里加内链指向它，这是最正当的做法；内容确实没价值的，考虑合并或下线。
修复动作本身也在改站内结构，改完要复核——链接、跳转、收录状态一起验，不能只看「改过了」。这套复核清单，站内 变更后验证清单 写得比较全。
第六步，定时巡检，只报新增。手工方式跑不完第二遍。把整条链挂进定时任务（配置方式见 OpenClaw 定时发日报周报），每周或每两周跑一次，并且和上次结果做对比，只报新增和已修复的。这一步是关键：每次都甩一份全量报告，几周之后你就不看了；只报变化，才会真的去修。这个「只报变化」的思路，和 定时盯网页变化 是同一套做法。
顺带把站点地图和收录也理一遍
死链巡检和站点地图用的是同一批数据，顺手就能做：
- 站点地图只放该被收录的页面：返回 200、有实质内容的才放；不希望被索引的（后台页、搜索结果页、带一串参数的页）一律别放。
- 死链页和跳转页不要出现在 sitemap 里，这是最低要求。反过来，sitemap 里的每一个地址，都应该通过巡检确认它是 200。
- 新页面发布后及时更新 sitemap，并主动提交给搜索引擎。发完就不管，收录会慢很多。
- 修完死链后观察收录变化：修掉一批死链、补上一批内链，通常要过几周才能在收录数据上看出效果，别指望第二天就涨。
如果站内有需要定期核对的结构化清单（比如「文章—发布日期—目标关键词—当前收录状态」这类台账），用表格维护比用文档省事。Agent 读表的能力见 Agent 处理 Excel 表格 和 Agent 怎么读取文件——直接把表格喂给它，比人手抄一遍可靠得多。
四个容易踩的坑
坑一，把 403 和超时当成死链。很多站点对无头浏览器或高频请求会返回 403，这完全不是页面没了。判断死链唯一可靠的标准，是稳定的 404 或 410。误报一多，你会开始不信任这份报告，然后整套机制就废了。
坑二，内链指向跳转、而不是终点。这是最常见也最容易忽略的损耗。站内链一跳转，用户多等一下、爬虫多抓一次，看起来无所谓，几百条加起来就是实打实的浪费。
坑三，一次性修完就不管了。死链是「长」出来的，不是一次长完的。发一篇新文章、改一次栏目、换一次域名，都会产生新的死链。这件事的价值来自定期跑，不是来自跑一次。
坑四，为了消灭死链把链接删干净。删掉一个死掉的外链，页面看起来干净了，但你也丢掉了一条可信来源。能换就换，不能换再降级——写资料引用型内容时尤其要注意这一点。
优缺点与适合人群
优点：一次搭好、长期复用，站点越大收益越明显；把「感觉有问题」变成「清单上有三十七条待修」；修复动作可追踪，能验证有没有效果；顺带把 sitemap 和收录核对一起做了。
缺点：探测状态码要跑不少请求，站点很小时显得杀鸡用牛刀；外链替代来源的判断需要人工介入，纯自动做不好；软死链的判定（200 但没内容）得针对自己站点的结构写规则，没有通用答案。
适合：站内文章超过一百篇的内容站、博客、文档站；改过 slug 或栏目结构的站点（这类站点几乎一定有成堆死链）；正在做收录优化的站点。个人博客跑一次全站扫描也就几百个请求，成本可以忽略。
不太适合：刚上线、页面不到三十个的站——手动点一遍更快。等站点长起来再上这套流程完全不晚。
一句话总结：死链巡检是内容站最划算的一类自动化——它不产生新内容，但它把已经写好的内容重新变得可到达。链接修好、内链补齐、站点地图干净，用户少踩空，爬虫少浪费，这是最朴素也最实在的优化。
