如何检查网站死链，修复后怎样验证响应才算通过
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8707ec23df0c.html
📄
如何检查网站死链，修复后怎样验证响应才算通过
验证修复后的响应，核心不是再点一次链接看它能不能打开，而是确认三件事：原链接返回的 HTTP 状态码已经变成可索引状态、页面内容与目标一致、站内指向它的入口不再产生新的死链。只看到浏览器显示正常还不够，必须看服务器返回的状态码和最终跳转地址。
先明确“修复完成”的判定标准
修复死链通常有三种处理方式，每种对应的验收结果不同：
- 恢复原页面：请求原 URL 应返回
200，且返回内容与用户预期主题一致。 - 301 永久跳转：请求原 URL 应返回
301，并跳到最相关的存活页面，不能全部跳到首页。 - 删除并移除入口：原 URL 可以返回
404或410，但站内所有指向它的链接都必须已经清理。
如果修复方式是 301，却把几十个不相关旧链接全部指向首页，搜索引擎可能将其视为软 404 处理。因此验收时要检查跳转目标是否语义相关，而不是只看“有跳转”。
用状态码和跳转链做一次批量验证
最直接的方法是抓取修复后的 URL 列表，观察状态码与跳转链。可以在命令行用 curl 逐个检查：
curl -I -L --max-redirs 5 https://example.com/old-page
输出中重点看三行：第一行原始响应码、Location 头指向哪里、最终响应码是否为 200。如果原始响应是 301，但最终落到 404，说明跳转目标本身也是死链，这次修复没有真正完成。
批量场景下，把待验证 URL 写进一个文本文件，每行一个，用脚本循环请求并记录状态码。检查项包括：
- 原始 URL 的状态码是否符合预期（200 或 301）。
- 跳转链是否超过一跳，是否出现循环跳转。
- 最终落地页状态码是否为 200。
- 最终落地页的标题和主体是否与旧链接主题相关。
适用条件：URL 数量在几十到几百条时，脚本方式效率最高；如果站点有登录限制或按地区返回不同内容，需要在相同条件下测试，否则状态码对比没有意义。
区分“可能原因”与“已经定位的原因”
验证时如果发现状态码仍然异常，不要立刻断定是修复失败。同一现象可能有多种解释：
- 返回 404：可能是修复未部署，也可能是 CDN 或缓存仍在返回旧响应。
- 返回 301 但落地页错误：可能是跳转规则写错，也可能是目标页面后来被再次删除。
- 返回 200 但内容是错误页：可能是服务器把错误页配置成了 200 状态，这属于软 404，需要单独排查。
判断方法是先绕过缓存直接请求源站，再对比 CDN 返回结果。两者不一致时，问题在缓存层；两者一致但仍异常，才回到跳转规则或页面本身排查。只有确认了具体环节，才算“已经定位的原因”。
检查站内入口，避免修好旧链接又产生新死链
修复单个 URL 之后，还要确认站内没有其他页面继续指向已删除的地址。可以用站点爬虫工具抓取全站，筛选出状态码为 4xx 或 5xx 的内链。检查项包括：
- 导航、侧栏、页脚中的固定链接是否还有旧地址。
- 文章正文里的历史内链是否指向已删除页面。
- 站点地图中是否仍包含已删除的 URL。
需要特别说明：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。因此清理入口和提交站点地图只是辅助手段，不能替代状态码验证本身。如果旧 URL 已经返回 301，就应保留跳转，不要同时删除跳转规则。
把验证结果记录下来，方便复查
时间和人手有限时，优先验证流量最高、内链最多的那批 URL。记录表至少包含：原 URL、修复方式、原始状态码、最终状态码、最终落地页、验证时间。这样下次复查时可以对比，判断是稳定通过还是间歇性异常。
下一步可以直接做一件事：把本次修复的 URL 整理成清单，用上面的 curl 命令或脚本跑一遍，把返回 4xx、5xx 以及跳转链异常的条目单独列出来，优先处理这些未通过验收的链接。
