死链检查，异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /605afbe8c68b.html
📄
死链检查，异常恢复后怎样区分缓存过期与真正修复
先给结论：异常恢复后，单看“同一个URL现在返回200”无法区分缓存过期和真正修复。可行的判断是——把“响应层恢复”和“内容层恢复”分开验证，并确认恢复是否在无缓存条件下仍然成立。如果只有带缓存或带旧跳转的请求返回200，而直连源站、清缓存后仍异常，那更可能是缓存过期；如果清缓存、换节点、换UA后都稳定返回正确内容，才接近真正修复。
两种条件下分别怎么选：先看恢复是否可复现
条件一：异常只出现在个别样本，且恢复后立刻稳定。此时优先做“缓存过期”排查，而不是直接宣布修复完成。动作是记录恢复时间点，用同一URL在不同网络、不同入口、无Cookie环境各请求一次，观察状态码和响应体是否一致。若只在部分节点恢复，下一步应检查CDN或反向代理的缓存键，而不是改内容。
条件二：异常在批量样本中都出现，且恢复后仍反复。此时优先怀疑修复不完整或规则冲突。动作是把样本按“原死链类型”分组：404、410、软404、跳转链、参数变体分别统计。若某一组恢复、另一组仍异常，说明修复只覆盖了部分规则；下一步应回到规则层，而不是继续等缓存自然过期。
选择依据可以压缩成一句：恢复是否可复现，决定你先查缓存还是先查修复。不可复现的恢复，通常不是修复完成的证据。
区分缓存过期与真正修复的三个证据
第一个证据是响应头。查看 Age、Cache-Control、Expires、ETag 或 Last-Modified 是否在恢复前后发生变化。若 Age 归零、缓存标识变化，说明你看到的是新缓存对象；若这些头完全没变而状态码变了，更可能是源站行为变化。
第二个证据是内容指纹。不要只看状态码，比较恢复前后的标题、正文摘要、canonical、跳转目标是否一致。假设一个页面原来404，现在返回200但正文是通用错误页或首页模板，这属于“状态码恢复、内容未恢复”，不能算真正修复。
第三个证据是无缓存直连。用带随机查询参数的请求、禁用缓存的请求头，或直接请求源站地址，观察是否仍返回正确内容。若直连异常、经缓存正常，说明恢复来自缓存层；若直连正常、缓存异常，说明还需要处理缓存刷新。
需要提醒的是，请求量或抓取量归零不能单独证明处理正确。它也可能是抓取预算转移、robots限制、站点地图未更新或外部入口减少造成的。把统计变化当因果，容易误判修复状态。
一个可执行的恢复验证顺序
- 锁定异常样本，记录原始状态码、响应头、正文指纹和时间。
- 在无缓存条件下请求同一URL，记录状态码和内容是否与预期一致。
- 若直连正常、缓存异常，执行缓存刷新或等待缓存过期，再复测。
- 若直连异常，回到修复层：检查重定向规则、路由配置、内容模板和权限设置。
- 复测通过后，再观察索引层结果，但不要用索引结果反推修复是否成功。
这个顺序的关键是：先确认响应层，再确认内容层，最后才看索引层。索引层变化通常滞后，且受多种因素影响，不适合作为第一判断依据。
规模化后不能直接照搬的边界
个别样本成立的经验，规模化后经常失效。原因有三类：缓存键设计不同、跳转规则互相覆盖、以及不同目录由不同系统提供响应。假设一个小样本中，清缓存后全部恢复，于是你把“清缓存”当作标准动作；但规模化后，如果部分URL由独立应用返回410，清缓存不会改变源站行为，这时必须回到规则层处理。
还要注意，robots.txt 的抓取限制不等于可靠的索引移除。即使你通过robots阻止抓取，已索引的异常URL仍可能保留一段时间；站点地图也不保证收录。验证恢复时，应分别核查不同搜索引擎的支持情况，不要用单一入口的结果推断全部。
最后，HTTPS 不保证安全无漏洞或排名。恢复验证只回答“这个URL现在是否返回正确内容”，不回答“这个页面是否会被收录或排名”。把这两件事分开，才能避免用错误指标判断修复是否完成。
