先把当时的情况摆出来。巡检脚本看到 301 就记成正常，半年后才发现有两百多条旧地址 301 到了一个已经下线的栏目页，落地页返回 404，蜘蛛早就放弃了。
这类报错背后常见的原因有几处，逐个排除就行。脚本只判断首跳状态码，没有跟随到最终地址。另一种情况是重定向目标没有纳入巡检范围。
另外，报告里 301 和 200 记成同一类正常。
先让脚本跟随跳转并记录最终状态
curl -sL -o /dev/null -w '%{http_code} %{url_effective}\n' https://www.example.com/old/1只允许最多三跳
curl -sL --max-redirs 3 -o /dev/null -w '%{num_redirects}\n' https://www.example.com/old/1随后把落地页地址也加入巡检清单
curl -sL -o /dev/null -w '%{url_effective}\n' https://www.example.com/old/1 >> targets.txt等前面都确认过，再统计多跳与断链数量
grep -c '^404' check.log这台环境是别人交接的，不少默认值被动过，只能一项项核。
别只看报错消失，验证要多做一步。改完后查出 214 条断在第二跳的地址，修正映射后这批旧链接重新指到有效页面。
301 只说明有人接，不说明接得住，巡检要一路跟到最终状态码才算数。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。