死链工具：怎样验证修复后的响应
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /51b30ea879f7.html
📄
死链工具：怎样验证修复后的响应
验证死链修复后的响应，核心不是看死链工具里“错误数是否归零”，而是对每个已修复 URL 重新发起一次真实请求，确认返回状态码、跳转终点和页面内容三者一致。只改链接不验证响应，等于没有闭环。
先分清三种“修好了”
死链工具通常把问题标记为 404、410、超时或跳转异常。修复动作不同，验证对象也不同：
- 改链修复：把页面里指向死链的
<a href>改成有效地址。要验证的是新地址返回 200，且落地内容与原链接意图一致。 - 重定向修复：给旧 URL 配置 301 或 308，指向新 URL。要验证的是旧 URL 返回 3xx、
Location指向正确，并且不形成跳转链。 - 恢复内容：把误删页面重新发布。要验证的是原 URL 直接返回 200，而不是先跳转到别的地址。
这三种情况混在一起看“死链数量下降”，会漏掉跳转链、软 404 和内容错位。验证时按类型分组，比按工具报表排序更可靠。
用一次请求拿到可判断的证据
最直接的办法是对每个修复 URL 执行一次带跳转跟踪的请求。以命令行工具为例：
curl -sIL -o /dev/null -w "%{http_code} %{url_effective} %{num_redirects}\n" https://example.com/old-page
这条命令输出三样东西：最终状态码、跳转终点、跳转次数。判断条件如下：
- 状态码为 200，说明终点可访问；若为 404 或 410，说明修复未生效或指向了新的死链。
url_effective应与预期的新地址一致。若指向首页，属于典型的“用首页兜底”，对用户和抓取都不算真正修复。num_redirects最好为 1。若大于 1，说明存在跳转链，应逐跳检查中间环节。
如果站点有几百个修复项，逐条手敲不现实。可以先把死链工具导出的 URL 列表整理成一行一个地址的文件，再用脚本批量请求并记录状态码、终点和跳转次数。批量结果里，优先看状态码非 200 和跳转次数大于 1 的行。
状态码正确，内容仍可能不对
返回 200 只说明服务器愿意响应，不说明响应的是正确页面。常见偏差有三类：
- 软 404：HTTP 状态是 200，但页面正文写着“内容不存在”或只剩模板框架。判断方法是抓取页面标题和首段文字，与预期内容做关键词比对。
- 内容错位：旧链接指向了主题无关的新页面。比如旧的产品页跳到公司简介，状态码没问题，但用户意图落空。
- 规范化冲突：页面能打开，但
<link rel="canonical">指向另一个地址，等于告诉搜索引擎“别把这个 URL 当正主”。修复后应检查 canonical 是否指向自身或预期的规范地址。
这三类问题不会出现在死链工具的错误计数里。验证时至少抽查标题、canonical 和首屏正文，不能只看状态码。
时间和人手有限时的处理顺序
如果只能先做一部分，按下面顺序安排，代价从低到高：
- 先批量验证所有配置了重定向的 URL，因为脚本一次跑完，成本最低，且跳转链和错误终点最容易批量暴露。
- 再验证死链工具中访问量或内链数量最高的 URL。这些页面被用户和抓取触达的概率更大，修错的代价更高。
- 最后人工抽查改链修复和内容恢复的页面，重点看标题、canonical 和正文是否匹配。
判断标准可以简化为一句话：状态码 200、跳转次数不超过 1、终点内容与预期主题一致，三项同时满足才算通过。任何一项不满足，回到修复环节重做，而不是在工具里标记为已解决。
下一步，把死链工具导出的已修复 URL 列表按“重定向、改链、恢复”分成三组，先跑重定向组的批量请求，把非 200 和多次跳转的行单独列出来处理。
