现场是这样的。自建巡检脚本只判断状态码是否小于 400，302 被当成正常页面，八百多条跳转到错误地址的链接半年没被发现，等人工抽查时已经掉了不少流量。
中间走过弯路，把「跳转目标返回 404，但脚本没有做二次校验」当成主因，改完现象没变。
这类报错背后常见的原因有几处，逐个排除就行。脚本把 3xx 全部归为可访问，没有继续跟跳转；curl 默认不跟随跳转，脚本读到 302 就结束了；巡检样本只取 sitemap，站内链接根本没有覆盖。
动手时先用不跟随跳转的方式看原始状态码
curl -s -o NUL -w "%{http_code} %{redirect_url}\n" https://www.example.com/post-1024/跟随跳转后再看最终状态
curl -sL -o NUL -w "%{http_code} %{url_effective}\n" https://www.example.com/post-1024/批量导出 3xx 清单
findstr /c:" 302 " access.log | measure -Line等前面都确认过，再把跳转终点也纳入巡检
curl -sL -o NUL -w "%{http_code}\n" https://www.example.com/old-post/恢复的判定其实很直接。脚本补上跳转跟随与终点校验后，八百多条问题链接被清出，站内 404 数量回到两位数。
提醒一点。巡检只看第一跳的状态码没有意义，302 后面可能是 404，也可能是另一个 302。报错文案容易误导，真正的原因往往在相邻那一层的日志里。