等 Search Console 报出失效链接时，Googlebot 已经在它身上白白浪费了好几周爬取请求。2026 年这件事很少是直接的排名惩罚（Google 把硬 404 当作网络的正常组成部分），但二级伤害是实打实的：失效内链泄漏链接权重；软 404 比干净的 404 更耗 crawl budget，因为 Googlebot 会反复重抓；死掉的外部引用还会悄悄消磨读者信任。解法是一套 30 分钟的月度回路：确定性检查器扫出每一条死链，再由 AI 按根因聚类、给修复排优先级。这篇带你走完整回路，并给出确切命令。
一句话总结
- 每月对着 sitemap 跑一个检查器。
lychee（Rust）最快、外链准度最高；linkinator（Node）是最简单的 npm 配置。 - 把原始发现喂给聊天模型，让它按根因（内 404、重定向链、拼写错、死外链、410 gone）聚类并标 HIGH/MED/LOW。
- 先修内 404（链接权重 + 爬取），缩短重定向链，替换或归档死外链。绝不要默默删掉外部引用。
- 重跑检查器，两次跑的 diff 就是修复证据。用 GitHub Actions 调度，免得有人忘记跑。
这篇讲什么
100+ 文章内容站的月度维护工作流。产出：按根因分组、每个 cluster 附一条修复方案的失效内外链分流清单。检查器是 ground truth，AI 负责分组和优先级。它不会编造 URL，也不会爬站——那是确定性工具的活。
这篇适合谁看
100+ 文章的内容站站长。小公司 SEO 负责人。跑联盟营销或博客站的独立开发者——一条死外链既拖 SEO，也伤可信度。
什么时候适合用
月度维护是基线。此外，在任何大型 SEO 推进前加跑一次（你不想让可修的 404 正好在 Google 注意到新动静时吃掉爬取请求）；域名迁移后、slug 改名后、内容清理后、从其他平台导入内容后，都该跑。
选一个检查器
截至 2026 年 6 月，下面三个是成熟选项。选定一个就一直用，这样每次跑的 diff 才可比。
| 工具 | 引擎 | 默认并发 | 缓存 | 最适合 |
|---|---|---|---|---|
lychee | Rust，异步 | --max-concurrency 128（每 host 10） | .lycheecache，--max-cache-age 1d | 速度 + 外链准度 |
linkinator | Node | 100 连接 | 无内置 | 纯 npm 技术栈、CSS 里的 URL |
broken-link-checker | Node（较老） | 可配置 | 无 | 已经在用的旧项目 |
lychee 几个值得知道的默认值：失败请求重试 3 次（--max-retries），重试间隔 1 秒，默认接受状态码 100..=103,200..=299（用 --accept 改），每个 host 每 50ms 才发一次请求。正是这些默认值让它几乎不会因瞬时抖动报假 404。linkinator 默认是浅扫——只扫顶层页，要爬全站得加 --recurse。
开始前准备
- 装好你选的检查器。
- 备好 sitemap 地址（
/sitemap.xml），检查器以它为爬取入口。 - 如果要查
github.com上的链接，设一个GITHUB_TOKEN环境变量或传--github-token。未认证的 GitHub 请求很快被限流；带 token 的限额是每仓库每小时 1,000 次请求。 - 提前定行动阈值：外链 404 但反向链接小于 10 的可能不值得修；内链 404 永远值得修。
具体步骤
- 对着生产环境跑检查器。缓存会让重跑变得很便宜，第一天就开：
# lychee（最快）：缓存结果，跟随 sitemap
lychee --cache --max-concurrency 64 --include-fragments \
https://yoursite.com/sitemap.xml > broken.txt
# linkinator：递归全站，输出 JSON
npx linkinator https://yoursite.com --recurse \
--format JSON > broken.json把检查器结果和用 Codex 审查 sitemap的结果对照，避免漏掉检查器没爬到的 URL（从 sitemap 起爬时，没有任何入站链接的孤儿页永远进不了这次爬取）。
-
把输出作为上下文喂给聊天模型。100+ 条粘 CSV，少一点粘原始输出。任何当前模型都能胜任（GPT-5.5、Claude Sonnet 4.6 或 Gemini 3.1 Pro）——这是聚类任务，不是重推理任务。
-
Prompt 模型：
这是检查器给的 N 条失效链接发现。
按根因聚类：内 404、内重定向链（>2 跳）、URL 拼写错
（多斜杠 / 大小写错）、外死链（host 不可达）、外 410
（gone）。每类给修复优先级（HIGH/MED/LOW），依据：
源文章引用数、内 vs 外、返回 410 vs 404。
输出一张表，每条发现一行，带修复动作。- 内 404（永远 HIGH）。 grep 源内容里的坏 URL，修到正确 slug。多数是拼写错或改名遗留。这类杠杆最高，因为它恢复内链权重、止住爬取浪费。
- 内重定向链。 在源内容里缩到一跳。超过 2 跳会累积延迟，并在每一跳稀释链接权重。
- 死外链。 有等价来源就替换；没有就归档：把 URL 换成 Wayback Machine 快照，或标
[archived]加一句说明。绝不要默默删引用——别的页可能引用那个源时链回了你。 - 重跑检查器。 用同一组参数，diff 才干净。消失的那批发现就是你的修复证据。
实例：一次改名，三十条死链
一个 1,200 页的双语内容站第一次跑，典型结果长这样：
| Cluster | 数量 | 优先级 | 根因 |
|---|---|---|---|
| 内 404 | 10 | HIGH | 一次 slug 改名，8 条入站链接还指向旧路径 |
| 重定向链 >2 跳 | 15 | MED | 尾斜杠重定向又喂进了旧域名重定向 |
| 死外链 | 18 | LOW–MED | 厂商博客文章在网站改版后 404 |
| URL 拼写错 | 7 | HIGH | 手敲的 href 多了斜杠或大小写错 |
先修内，再缩短重定向链，最后分流外链。重跑后，幸存的通常只剩 2–3 个返回瞬时 5xx、会抖动的外部 host。安排下月再查，然后收工。总时间：第一次约 90 分钟，存好聚类 prompt 后约 30 分钟。把这次扫描当作按技术栈定制的 SEO checklist里的一行，跟 schema、hreflang、render mode 检查放在一起。
信 AI 之前先验证
AI 做的是模式匹配，不是 ground truth。要抽查它：
- cluster 真的有意义吗，还是模型把不相关的问题归成一类？每类手工抽 5 条验。
- 检查器漏了你内容里存在的 URL 吗？跟
grep -roE 'href="[^"]+"' src/对一遍，抓出爬虫没碰到的链接。 - 有没有”死”外链是在坏时段被打的？24 小时后再测——瞬时 5xx 会抖动，单个重试窗口不足以判一个 host 死了。（
lychee --cache在这有用：缓存里的好结果不会被重查。） - 提出的”修复”需要人工判断吗？“换成类似来源”是任务不是修复——模型替你找不到那个替代源。
把节奏自动化
活跃站约 60 天漂移就回来，所以让它自动跑。
- 用 GitHub Actions 按月 cron 调度检查器。官方的
lycheeverse/lychee-action会跑 lychee、写报告，还能用发现创建或更新一个 issue——这样报告主动来找你，而不是等谁记得敲命令。 - 把 AI 聚类 prompt 存成保存的 prompt 或 Custom GPT。Prompt 稳定，每月变的只是输入。
- 跟踪发现随时间变化。反复出现的类别（永远是改名遗留）说明你的 slug 改名流程要内建一个修复步骤，而不只是更勤地修。
容易踩的坑
- 等 Search Console 报错才动。 那时你已经丢了几周爬行效率。
- 默默删外链。 读者和引用页都期望它在。改用 Wayback Machine 归档。
- 没有月度节奏。 活跃站 60 天内漂移就回来。
- 删外 404 时不找替代。 引用价值的一半就在那条链接本身。
- 照搬 AI 的”修复” 而不确认目标页存在。
- 忽略重定向链。 它们不显示为坏，但吃 crawl budget 和 TTFB，还在每一跳稀释链接权重。
- 不开
--cache就跑。 每次重跑都把每个外部 host 重锤一遍，又慢又容易被限流。
FAQ
- 哪个检查器最准？ 截至 2026 年 6 月，外链准度和速度都看
lychee，靠的是它的重试和每 host 限速默认值。已经在 Node 项目里就用linkinator最省事。都能用——跑与跑之间的一致性比选哪个更重要。 - JS 渲染的链接呢？ 多数检查器只看静态 HTML。SPA 重的站要用带 headless 浏览器模式的检查器或基于 Playwright 的工具，否则客户端 JS 注入的链接对这次爬取是不可见的。
- 多快该修？ 内 404：7 天内（链接权重和爬取）。外：30 天。重定向链：60 天。
- AI 会替代链接检查器吗？ 不会。检查器是确定性的、是 ground truth；AI 在它上面一层（聚类 / 优先级 / 修复方案）。靠”推理”来查链接的模型会幻觉出状态码。URL 一律用真检查器查。
- 怎么查 MDX / markdown 源里的链接，而不是部署后的站？ 单独写一个 pre-build 脚本，把内链解析到内容集合——线上检查器只看部署后的 HTML。lychee 也能直接扫本地 Markdown 和 HTML 文件，把它指向一个 glob 而不是 sitemap 即可。
- 404 真的会伤排名吗？ 2026 年不会直接伤——Google 把它当正常现象。代价是间接的：浪费 crawl budget、丢失内链权重，以及软 404（“找不到”页却返回 200 OK）被 Googlebot 反复重抓。修它们是为了爬取效率和链接权重，不是怕惩罚。