网站死链检查工具：异常恢复后怎样区分缓存过期与真正修复

📍 WDQWDWQD987AAAAA:216.73.217.9
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1d151ddb255a.html
📄

网站死链检查工具：异常恢复后怎样区分缓存过期与真正修复

先给结论：异常恢复后，如果同一批链接在短时间窗口内由失败转为成功，但响应头、重定向终点和内容指纹没有同步变化，更可能是缓存过期；只有当修复动作落到了源站或规则层，并且不同网络位置、不同请求头下都能稳定复现成功，才算真正修复。判断的关键不是“现在通了”，而是“为什么通、能通多久、换条件还通不通”。

先看一个矛盾现象：样本通了，批量却继续报错

假设你用网站死链检查工具跑了 500 条站内链接，第一次结果里有 37 条返回 404 或 5xx。你修了其中几条，重新跑一遍，发现这 37 条里有 12 条变成 200，于是判断“已经恢复”。但把范围扩大到全站 2 万条链接时，同样的路径又出现失败，或者同一 URL 在不同时间点结果来回跳。这个矛盾说明：小样本的成功可能来自缓存层，而不是源站修复。

缓存过期和真正修复都会让状态码从失败变成成功，所以只看一次结果无法区分。需要把“状态码变化”拆成可验证的证据链，而不是把一次 200 当成结论。

两种解释分别成立的条件

解释一：缓存过期造成的假恢复

当失败页面之前被 CDN、反向代理或浏览器缓存过，缓存 TTL 到期后回源，源站可能已经返回正常内容，也可能只是这次回源命中了临时可用节点。它的特征是：

这类恢复不能直接判定为修复完成，因为下一次缓存回源或节点切换后可能再次失败。

解释二：真正修复

真正修复意味着失败原因在源站、规则层或内容层被处理，例如补回被删除的页面、修正错误的重定向规则、恢复被误配的模板。它的特征是：

只有同时满足“稳定”和“可归因”，才适合把这条链接从待修列表移到已修复列表。

用一组可区分证据做交叉验证

不要只依赖网站死链检查工具的单次状态码。下面这组动作可以在不增加复杂工具的前提下完成区分：

  1. 换网络位置复测。用不同出口 IP 或不同地区节点请求同一 URL。如果只有部分位置成功，优先怀疑缓存或节点差异。
  2. 带不同请求头复测。分别用普通浏览器 UA 和爬虫 UA 请求。如果结果不同，说明存在规则层分流，不是单纯缓存过期。
  3. 看重定向终点。记录 301/302 的最终落地 URL。如果终点仍是错误页或首页，状态码 200 只是表面成功。
  4. 比对内容指纹。对页面正文做哈希或抽取关键段落。修复后指纹应变化；若指纹不变却状态码变好，更可能是缓存。
  5. 等待一个缓存周期再跑。在 TTL 之后、回源压力变化之后再复跑。若结果再次波动，说明之前只是缓存过期。

这些动作的结果会直接决定下一步：稳定且可归因的，进入关闭流程；仍波动的，回到源站和规则层继续排查，而不是反复重跑工具。

一个注明假设的短例子

假设某分类页因模板误删返回 404，你在 10:00 恢复模板并发布。10:05 用网站死链检查工具跑 50 条样本，其中 8 条变 200，你准备关闭任务。此时更稳妥的做法是：先记录这 8 条的响应头和重定向终点，再在 11:00 和 14:00 各复跑一次，并换一个网络位置。如果三次都稳定成功、终点正确、内容指纹与恢复后的模板一致，才可以判定修复；如果只有 10:05 那次成功，之后又出现 404，说明之前命中的是缓存，修复并未真正生效。

这个例子的数字仅用于说明比较方法，不代表任何真实项目结果。

边界：哪些情况不能照搬这套判断

如果失败来自 robots.txt 限制、站点地图未更新或索引层未刷新，那么状态码恢复并不等于索引恢复。robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。此时需要分别核查抓取、索引和展示三个环节，而不是把网站死链检查工具的成功响应直接当成收录恢复。

另外，HTTPS 不保证安全无漏洞或排名，证书正常也不代表内容层修复完成。不同搜索引擎对重定向、缓存和索引的处理存在差异，涉及具体搜索引擎时应分别核查，不能用一个平台的结果推断另一个平台。

最后，请求量或抓取量归零不能单独证明处理正确。它可能是缓存命中、规则拦截、统计口径变化或真实修复共同作用的结果。只有把状态码、响应头、重定向终点、内容指纹和变更记录放在一起看，才能把“现在通了”和“真正修好了”区分开。

图1 图2
nginx