单文件Python脚本巡检站点死链

网站迁移、改版上线后，sitemap 里可能还留着返回 404 或发生跳转的旧地址。作者做了一个 Hermes skill，用单个 Python 脚本批量检查这些 URL，还能继续检查页面里的出站链接。

它的价值是把链接巡检变成终端和定时任务都能执行的检查，并在发现损坏链接时返回失败状态。不过，它覆盖的是 sitemap 和静态页面能提供的线索，不能据此断言整个网站没有坏链接。

一个 Python 文件能检查到哪一步

作者把工具命名为 sitemap-link-checker，核心脚本只使用 Python 标准库。它能读取普通 sitemap、gzip 压缩的 sitemap，以及列出多个子 sitemap 的索引。

检查时，脚本先向每个 URL 发起 HEAD 请求。HEAD 通常只获取响应头，适合先判断地址是否可访问；服务器拒绝 HEAD 时，再退回 GET。随后，工具列出损坏的 URL 和重定向。

这两类结果需要分开看：404 表示目标不存在，重定向则可能是迁移时有意保留的兼容措施。发现跳转后，还要判断它是否符合预期。

加上 --links，工具会打开页面，检查其中的出站链接，并报告死链出自哪个页面。下面这条命令展示了链接检查和 URL 数量限制的组合：

python3 scripts/sitemap_check.py https://example.com/sitemap.xml --links --max-urls 50

要看的是 --links：它把检查范围从 sitemap 中的页面地址扩展到页面里的链接。原文没有解释 --max-urls 50 是否也限制出站链接数量，不能把它直接理解成「最多发送 50 次请求」。

为什么退出码比一份报告更适合定时巡检

作者选择自己写脚本，是因为一些在线检查工具限制页面数量、要求注册，或者不方便通过脚本调用。他需要的是能在终端或 cron 任务里运行，并明确暴露失败的工具。

原文给出的输出示例如下，既区分错误类型，也保留死链所在页面：

Checked 3 sitemap URLs: 1 broken, 1 redirected
  BROKEN 404 https://example.com/missing
  REDIRECT 301 https://example.com/old -> https://example.com/ok
  DEAD LINK 404 https://example.com/dead-link (on https://example.com/ok)

其中 (on https://example.com/ok) 很实用：修复页面内死链时，你需要知道从哪里改起，而不只是得到一个失效地址。

发现损坏链接时，脚本返回退出码 1。

这样定时任务就能根据进程状态识别异常，不必解析整段文字。不过，原文没有说明「只有重定向、没有损坏链接」时的退出码，也没交代超时、网络错误如何归类。

作者还提供了 --selftest：启动本地服务器，构造 404、重定向和页面内死链，并断言三类情况都能被捕获。这验证的是受控样例下的基本行为，不代表复杂网站上的完整覆盖率。

我的判断

这个方案适合迁移后的第一轮巡检：入口明确、依赖少，结果能定位到具体 URL，也便于接入已有任务。工具以 MIT 许可证收录在 hermes-skills 库中，但原文没有提供运行耗时、检查规模或与在线工具的对照数据。它是否更快、更准确，仍缺乏证据。

覆盖范围是最大的前提。未被 sitemap 收录的页面不在入口范围内；通过 JavaScript 渲染出来的链接也会被忽略。对前端项目尤其如此：路由配置、登录后页面、客户端交互产生的跳转，都可能需要另外验证。

此外，一些网站会对脚本返回 403。遇到这种结果，不能直接认定普通访客也无法访问。原文没有说明工具如何区分访问限制与页面故障。

它适合承担一项边界清楚的巡检工作。涉及客户端渲染和交互的路径，仍需浏览器层面的检查补足。

能拿来做什么

• 网站迁移或改版后，先检查 sitemap 中的地址，再逐项确认 404 和重定向是否符合迁移计划。
• 对自己有权测试的网站启用 --links，利用输出中的来源页面定位并修复静态链接。
• 接入 cron 等定时任务前，先运行 --selftest，再验证任务系统能否识别退出码 1。
• 前端项目应另外检查 JavaScript 渲染的链接，避免把这份巡检结果当成全站可用性的证明。