死链检查工具怎样验证修复后的响应：交付前用状态码与正文双重复核
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /eaf33f84ba1e.html
📄
死链检查工具怎样验证修复后的响应：交付前用状态码与正文双重复核
修复死链后，不能只看死链检查工具不再报错就结束。可靠做法是：用工具复扫得到状态码清单，再对每个原死链URL单独发一次请求，核对最终状态码、重定向链和页面正文是否与目标内容一致。只有状态码为200或301/302指向有效页，且正文不是404模板、错误页或空白页，才算修复通过。
准备：先固定一份可交接的检查清单
多人协作时，返工往往来自“谁改了、改了什么、验证到哪一步”没有记录。开始验证前，先把待验证对象固定下来：
- 原死链URL清单：来自上一次死链检查工具导出的报告，保留原始状态码和发现时间。
- 修复方式：删除链接、替换链接、配置301、恢复页面，逐条标注。
- 预期结果：每个URL修复后应返回什么状态码、落到哪个目标地址。
- 验证人：谁执行复扫，谁核对正文，谁最终确认。
这份清单是后续判断“通过还是返工”的依据。如果只写“已修复”，没有预期状态码，验证时只能凭感觉，容易漏掉重定向到错误页面这类问题。
实施：用工具复扫，但别把工具结果当结论
把原死链清单导入死链检查工具，或让工具重新抓取相关栏目，得到新一轮状态码。此时要区分三类结果：
- 仍返回4xx或5xx：说明修复未生效，可能是规则未部署、缓存未刷新或目标页本身不可用。
- 返回3xx：说明有重定向，需要继续跟踪最终地址，确认不是跳到首页、错误页或无关栏目。
- 返回200：说明可访问，但仍要核对正文内容，因为404页面有时也会返回200。
工具复扫是批量筛查，不是最终判定。它可能受抓取频率、User-Agent、登录态影响，同一URL在不同条件下结果不同。对清单中的每条URL，至少用一次独立请求复核。
验证：最关键的一步是核对最终响应与正文
验证修复后的响应，核心是看“最终落到哪里、返回什么、内容对不对”。可以按下面步骤执行：
- 对原URL发起请求，记录状态码和重定向链。若有多跳，逐跳记录，确认每一跳都指向预期地址。
- 检查最终URL的状态码。200表示正常返回；301/302需要确认目标页有效；404/410表示仍未修复。
- 查看最终页面正文。搜索原页面应包含的关键词、标题或产品名，确认不是通用404模板、登录页或空白页。
- 检查页面是否被robots.txt限制抓取。robots.txt限制抓取不等于索引移除，也不代表修复成功，它只是阻止爬虫访问，用户和验证请求仍可能看到内容。
- 若站点有站点地图，确认修复后的URL是否已加入。站点地图不保证收录，但可作为交付记录的一部分。
短例子（假设）：原URL /old-page 返回404，修复时配置301到 /new-page。复扫显示301，但最终地址返回200且正文是网站首页。这种情况应判定为未通过，因为重定向目标与预期内容不符。正确做法是把301指向真正替代原内容的页面，或恢复原页面。
判断标准可以统一为：状态码符合预期、重定向链不超过必要跳数、最终正文与原内容主题一致、无robots.txt误拦截。四项都满足才交付。
维护：把验证结果写进交付记录，减少返工
验证完成后，交付记录至少包含：原URL、修复方式、复扫状态码、最终URL、最终状态码、正文核对结果、验证时间、验证人。这样下次有人接手时，不需要重新猜测修复逻辑。
维护阶段建议定期复扫同一批URL，观察是否再次出现4xx或5xx。若使用HTTPS，也要知道HTTPS不保证页面安全无漏洞或排名提升，它只解决传输加密问题，不能替代内容与状态码检查。
下一步：从当前死链清单中挑出仍返回3xx的URL，逐条跟踪重定向链，确认最终地址和正文，再把结果补进交付记录。
