死链检查方法：怎样验证修复后的响应
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /608449319609.html
📄
死链检查方法：怎样验证修复后的响应
验证修复后的响应，核心是回到原死链的完整 URL，分别检查 HTTP 状态码、重定向终点和页面内容是否与预期一致。只看到浏览器能打开还不够，因为 200 可能来自软 404 页面，301 也可能跳到另一个失效地址。正确的做法是：先记录修复目标，再用可复现的请求逐项核对。
先明确修复目标：删除、跳转还是恢复内容
同一个死链可以有三种修复方向，验证标准完全不同：
- 恢复原内容：原 URL 应返回 200，且页面主题与原来一致。
- 301 跳转到新地址：原 URL 应返回 301 或 308，并最终落到一个 200 的目标页。
- 彻底删除：原 URL 应返回 404 或 410，且不再出现在站内链接中。
如果目标没定清楚，验证时很容易把“跳到了首页”误判为修复成功。跳首页只适合无对应内容的旧链接，不适合原本有明确主题的页面。
用请求头而不是浏览器地址栏看状态码
浏览器地址栏只显示最终页面，看不到中间跳转和原始状态码。推荐用命令行工具检查：
curl -I -L --max-redirs 5 https://example.com/old-page
参数含义：-I 只取响应头，-L 跟随重定向，--max-redirs 5 限制跳转次数，避免循环跳转一直跑下去。输出中要重点看：
- 第一行状态码是 301、308 还是直接 200。
Location头指向哪里，是否为目标页。- 跟随后的最终状态码是否为 200。
- 跳转链是否超过一跳，是否出现 302 临时跳转。
如果第一行就是 200，说明没有配置跳转，需要确认页面内容是否真的恢复，而不是服务器把未知路径统一返回了首页。
识别软 404：状态码对但内容不对
软 404 指服务器返回 200，页面却显示“内容不存在”或空白模板。这种情况对用户和搜索引擎都不友好，但状态码检查会漏掉。判断方法：
- 用
curl取回页面正文，搜索是否存在“未找到”“已删除”等提示文本。 - 对比修复前后页面的标题标签和正文首段，确认主题一致。
- 检查页面是否只剩导航和页脚，没有主体内容。
适用条件：原 URL 计划恢复内容时，必须做这一步。若计划就是删除，返回 404 反而正确，不需要消除软 404 提示。
检查跳转终点是否再次失效
301 跳到另一个 404，是修复后最常见的问题。验证时要单独请求目标地址：
curl -I https://example.com/new-page
确认目标页返回 200，并且内容与旧链接主题相关。如果目标页本身还有跳转，整条链会变长，用户等待增加，也不利于权重传递。一般建议一跳到位，不要 A 跳 B、B 再跳 C。
还要检查跳转是否区分大小写和带斜杠版本。有些服务器对 /Old-Page 和 /old-page 处理不同，修复时只改了一个变体，另一个仍然 404。
站内链接与站点地图同步核对
响应修好了，但站内其他页面仍指向旧地址，用户点击后照样经过跳转，体验没有真正改善。检查项：
- 全站搜索旧 URL 路径，确认内链已改为新地址。
- 站点地图中移除已删除的 URL，替换已跳转的 URL。
- robots.txt 没有误屏蔽修复后的路径；抓取限制不等于索引移除，屏蔽后页面仍可能以其他方式被引用。
站点地图只用于提交发现，不保证收录，因此不能把“已写入 sitemap”当作修复完成的证据。
可执行的最小验证流程
- 列出待验证的旧 URL 清单，标注每个的修复目标。
- 对每个 URL 执行
curl -I -L，记录状态码和跳转终点。 - 对返回 200 的页面，抓取正文确认不是软 404。
- 对跳转的页面，单独验证目标 URL 返回 200。
- 抽查站内链接和站点地图，确认没有残留旧地址。
- 间隔一段时间后复测一次，排除缓存或临时配置造成的假象。
判断结果：全部 URL 的最终状态码为 200，跳转链不超过一跳，内容与目标一致，内链和站点地图无残留，才算修复通过。任何一项不满足，都应回到对应环节重新处理，而不是只看浏览器能否打开。
下一步：把上述命令和检查项整理成一张验证表，对每个修复过的 URL 逐行记录原始状态码、最终状态码、跳转目标和内容核对结果，便于后续复查和交接。
