网站死链检测，异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /cdbefc3a0b08.html
📄
网站死链检测，异常恢复后怎样区分缓存过期与真正修复
先给结论：异常恢复后不要只看一次返回码。缓存过期只会让某个响应在短时间内改变，真正修复则要求同一 URL 在不同请求路径、不同来源和不同时间点都稳定返回正常结果。区分二者的核心动作是：把“响应结果”和“响应来源”分开记录，再对同一批 URL 做第二次、换路径的复核。下面用一个假设情境串联整个判断过程。
假设情境：一次批量恢复为什么让人误判
假设某站做过一轮链接清理，把一批旧路径做了跳转。第二天用检测工具跑全站，发现之前报 404 的 URL 全部变成 200。团队准备收工。但第三天再跑，其中一部分又回到 404，另一部分保持 200。这个反复不是工具坏了，而是两类原因混在一起：一类是缓存层在旧响应过期后重新回源，恰好命中了一个临时可用的状态；另一类是源站真的改了规则。
要做的第一件事，是把恢复结果按 URL 分组，而不是按“总数下降”下结论。总数下降可能只是缓存集体过期，也可能是修复生效，两者在没有分组前无法区分。
看响应头，而不是只看状态码
状态码是最容易被缓存欺骗的信号。同样返回 200，可能来自 CDN 边缘节点、代理缓存或源站。判断时优先看这几类头部线索：
Age：数值较大说明响应来自缓存，不能代表源站当前状态。Cache-Control与Expires：决定这个响应还能被复用多久，也决定你下次复核的时间点。X-Cache、CF-Cache-Status一类自定义头：能提示命中还是回源，但字段名因服务商而异，需要按实际环境确认。Last-Modified与ETag：如果修复后这些值没变，说明源站内容或规则可能并未真正更新。
一个可执行动作是：对同一 URL 先正常请求一次，再带一个能绕过缓存的查询参数请求一次，比较两次的状态码和头部。如果只有带参数的请求正常，说明你看到的很可能是缓存过期，而不是源站修复。这个结果会直接决定下一步——继续查源站规则，而不是宣布完成。
换请求路径复核，排除单点假象
缓存通常按节点、按地区、按路径分布。一次请求正常，不能证明所有节点都正常。建议用两种路径交叉验证：
- 用检测工具从不同出口 IP 或不同地区节点请求同一 URL，记录每个节点的状态码。
- 直接请求源站（绕过 CDN 或代理）对比结果，确认源站本身是否已经返回正常。
如果只有部分节点正常，而源站仍异常，那基本可以判定为缓存过期造成的局部假象。如果源站和所有节点都稳定正常，才更接近真正修复。这里要注意：不同搜索引擎对同一 URL 的处理节奏不同，抓取正常不等于索引已更新，这两件事要分开记录。
用时间窗口做二次确认
缓存过期有明确的时间边界。真正修复没有“过期后回退”的现象。因此二次确认要卡在缓存有效期之后：
- 记录第一次看到恢复的时间，以及响应头里标注的缓存有效期。
- 在有效期过后，对同一批 URL 再跑一次检测，重点看之前恢复的那部分是否仍然正常。
- 如果有效期后重新出现异常，说明之前的恢复是缓存造成的，需要回到源站规则继续排查。
这一步的假设是：缓存有效期可以从响应头读取。如果环境里读不到明确的有效期，就改用固定间隔的多次抽样，观察结果是否稳定，而不是依赖单次判断。
把结论落到下一步动作
区分清楚之后，处理方向会完全不同。若是缓存过期，下一步是检查缓存策略和刷新机制，确认源站规则是否真的生效；若是真正修复，下一步才是更新站点地图、提交复核并观察索引变化。需要提醒的是：站点地图不保证收录，robots.txt 的抓取限制也不等于可靠的索引移除，这些都不能替代对源站响应本身的确认。
最后给一个可操作的判断标准：同一 URL 在缓存有效期后、换节点、绕过缓存三种条件下都返回正常，并且源站头部内容有对应更新，才可以按真正修复处理；否则先按缓存过期继续验证。这个标准不承诺任何收录或排名结果，只用于决定你下一步该查缓存还是查源站。
