网站死链查询 - 修复后如何验证响应是否真正恢复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /648dc187e2f5.html
📄
网站死链查询 - 修复后如何验证响应是否真正恢复
验证修复后的响应，不能只看浏览器能不能打开，而要回到死链查询的原始结果：用同一批URL重新请求，确认返回状态码已从4xx/5xx变为2xx或预期的3xx，并且页面内容、跳转目标和内部链接都指向正确位置。只有请求结果与页面内容同时通过，才算修复完成。
先明确验收对象：哪些URL需要复查
修复前应保存一份死链清单，至少包含三列：原始URL、发现时的状态码、来源页面。修复后逐条复查这份清单，而不是只抽查首页。判断依据是同一URL在相同请求方式下的响应是否改变。如果原URL被301到新地址，要确认跳转链只有一跳，且最终落地页返回200。若跳转链出现多跳或最终仍是404，说明修复没有闭环。
用请求工具核对状态码与跳转链
命令行工具适合批量核对。以curl为例，可用下面的方式查看单条URL的响应头：
curl -I -L https://example.com/old-page
-I只取响应头，-L跟随跳转。观察输出中最后一个HTTP状态码是否为200，以及Location字段指向的地址是否符合预期。如果要看完整跳转链，可加-v。这一步能区分“表面能打开”和“实际返回正确状态”。
注意：不同搜索引擎对跳转的处理并不完全一致，Google、Bing、百度对301和302的继承规则各有差异，验证时应分别用各搜索引擎的抓取工具或站长平台提交复查，不能因为一个渠道正常就认定全部恢复。
检查页面内容是否与目标一致
状态码正确不代表内容正确。常见问题是旧URL跳到了首页或分类页，而不是最相关的替代页面。验收时要打开最终落地页，确认标题、主体内容和原页面主题一致。如果原页面已删除且没有等价内容，应返回410而不是301到无关页面。判断标准是：用户从原链接进入后，能否找到他原本需要的信息。
回到死链查询工具做二次扫描
单条验证通过后，用与首次发现死链相同的查询方式再跑一遍。如果首次用的是站内爬虫，就用同一爬虫重新抓取；如果首次用的是搜索引擎的站点错误报告，就等抓取更新后查看该报告中的错误数是否下降。这里要分清：站点地图提交不保证收录，robots.txt允许抓取也不等于页面会被索引。二次扫描的目标是确认“不再被报告为死链”，而不是保证排名或流量立即恢复。
- 检查项一：原URL返回2xx或单跳3xx，最终页为200。
- 检查项二：最终页内容与原始链接意图匹配。
- 检查项三：站内其他页面不再链接到已失效的旧地址。
- 检查项四：二次扫描结果中该URL不再出现在死链列表。
把验证结果写成可交接的记录
每条URL记录四项：修复方式（改链接、加跳转、删除并返回410）、验证时间、验证时状态码、最终落地页。这样下次复查时能直接对比。如果修复涉及服务器配置，还要确认HTTPS证书和重写规则没有引入新的循环跳转——HTTPS本身不保证安全无漏洞，也不直接保证排名，它只是验证中的一个检查点。
下一步：从死链清单中挑出状态码仍为4xx或5xx的URL，按来源页面分组，优先处理被站内多次链接的地址，再重新执行一次完整扫描。
