网站死链检查，异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8cbf12579343.html
📄
网站死链检查，异常恢复后怎样区分缓存过期与真正修复
先看恢复的是哪一层：如果修复动作只改了源站，而CDN、反向代理或浏览器仍返回旧的404，那是缓存过期；只有当源站响应、缓存层响应和实际抓取路径都返回200或预期状态码，并且旧的错误响应不再被任何中间层复用，才算真正修复。判断顺序应是先确认源站，再确认缓存层，最后确认外部抓取结果，而不是看到一次200就收工。
先分清两种恢复：缓存过期与源站修复
缓存过期是指源站早已恢复正常，但CDN边缘节点、反向代理或浏览器本地仍保存着旧的404响应。它的典型特征是：同一URL在不同网络、不同IP或不同地区得到不同结果，或者带随机查询参数访问时立刻返回200，而原URL仍返回404。真正修复则是源站本身已经不再返回404，无论缓存是否刷新，回源请求都能得到正确状态码。
这两种情况的处理代价完全不同。缓存过期只需要等待TTL到期或主动刷新缓存，通常不涉及内容改动；真正修复则意味着源站配置、重定向规则或文件本身已经改对，后续重点是防止再次出现死链。如果把缓存过期误判为真正修复，下一次缓存失效后旧404会重新暴露；如果把真正修复误判为缓存过期，就会反复刷新缓存却找不到根因。
条件一：源站仍返回404时，先处理源站而不是刷缓存
当直接回源请求仍然返回404，说明问题不在缓存层。此时应检查三类原因：目标文件是否真的被删除或改名；重定向规则是否写错目标地址；服务器路由或伪静态配置是否把该路径指向了不存在的处理程序。动作上，先用带Host头的回源请求确认状态码，再检查服务器访问日志中该URL的记录，看请求是否到达了正确的处理位置。
这个动作的结果会直接决定下一步：如果回源返回404且日志显示请求已到达服务器，说明是内容或规则问题，应修改源站而不是刷新缓存；如果回源返回200但外部仍看到404，才进入缓存层排查。注意，robots.txt的抓取限制不等于可靠的索引移除，即使源站恢复，被限制抓取的URL也不会因此自动从索引中消失，这属于另一个问题，不能和缓存过期混为一谈。
条件二：源站已返回200时，用分层验证确认缓存是否还在复用旧响应
源站恢复后，仍需确认中间层是否还在返回旧404。可用的判断依据包括：响应头中的缓存年龄、缓存命中标识、以及同一URL在不同节点上的状态码差异。假设某个URL源站已返回200，但CDN边缘仍返回404且响应头显示缓存命中，那么这属于缓存未过期，应等待TTL或按缓存规则主动清除，而不是继续改源站。
实施动作上，可以先用带缓存绕过参数的请求对比回源结果，再观察清除缓存后原URL的状态码变化。如果清除后原URL稳定返回200，说明是缓存过期问题；如果清除后仍返回404，说明还有未覆盖的缓存层或源站规则未生效。这里要说明一个例外：如果站点同时使用多个CDN或多个反向代理，只清除其中一层，其他层仍可能返回旧响应，所以需要逐层确认，而不是清一次就认为结束。
用一组可区分的证据避免误判
- 回源请求返回404，外部也返回404：优先查源站内容和规则。
- 回源请求返回200，外部返回404且带缓存命中标识：优先查缓存层。
- 带随机参数返回200，原URL返回404：强烈指向缓存复用旧响应。
- 清除缓存后原URL仍返回404：说明还有未处理的层或源站规则未真正生效。
- 源站和缓存都返回200，但外部抓取仍显示旧状态：需要分别核查搜索引擎、平台推荐和广告渠道的抓取与展示逻辑，不能只用一次请求下结论。
这些证据只能说明某一层的行为，不能单独证明整个链路已经修复。请求量或抓取量归零也不能单独证明处理正确，它可能只是抓取频率下降、日志采样或渠道调整的结果。
真正修复的确认标准与后续动作
真正修复至少满足三个条件：源站对目标URL返回预期状态码；缓存层不再复用旧的404响应；外部抓取路径在合理时间窗口内不再返回旧状态。满足后，下一步应把该URL加入持续监控，观察它是否再次返回404，而不是立刻移除检查项。站点地图不保证收录，提交修复后的URL也不等于索引会立即更新，所以确认修复和确认索引结果是两个阶段。
如果修复涉及HTTPS配置变更，也要注意HTTPS不保证安全无漏洞或排名提升，它只解决传输层的问题，和死链是否真正修复没有直接关系。不同搜索引擎对缓存和索引的处理节奏不同，需要分别核查，不能用一个渠道的恢复结果推断所有渠道都已正常。
