网站死链修复, 怎样排除缓存造成的假象
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e6cdfe54d126.html
📄
网站死链修复, 怎样排除缓存造成的假象
要排除缓存造成的假象，核心做法是让“检测结果”和“实际服务器响应”分离：先用带随机查询参数的 URL 绕过大部分缓存，再直接查看服务器返回的状态码，最后用另一个网络环境或工具复核。只有三次结果一致，才能把某个链接判定为真正的死链，否则它很可能只是缓存层返回的旧页面或旧状态。
先看一个假设例子
假设某站点把 /old-page 从 200 改成了 404，你在浏览器里打开它，仍然看到旧内容。此时有三种可能：浏览器本地缓存、CDN 或反向代理缓存、页面本身并未真正删除。若直接把它记进死链清单去修，就会白做一遍。
正确的顺序是：先在原 URL 后加一个没意义的参数，例如 /old-page?check=20240101，强制绕过以完整 URL 为键的缓存；再用命令行或在线状态码工具请求原始 URL，只看响应头里的状态码；最后换一个网络（例如手机热点）再请求一次。如果带参数返回 404、原始 URL 返回 200、换网络后仍是 200，那么问题在缓存，不在链接本身。
区分几种缓存来源
- 浏览器缓存：只影响你自己的设备。换浏览器或无痕窗口即可排除。
- CDN 与反向代理缓存：影响所有访客，常按 URL 缓存整个响应。加随机参数通常能绕过。
- 搜索引擎结果缓存：搜索结果里显示的标题、摘要和收录状态可能是旧快照，不代表当前页面状态。
- 站点地图与抓取工具缓存：工具上次抓取的结果会保留一段时间，需要重新抓取才更新。
需要提醒的是，robots.txt 的抓取限制不等于可靠的索引移除，它只约束抓取行为，不保证页面从结果中消失；站点地图也不保证收录。判断死链时不要把这些信号混在一起。
可执行的检查清单
- 复制原始 URL，用命令行请求，记录返回的状态码，例如
curl -I https://example.com/old-page。 - 在同一 URL 后追加随机查询参数，再请求一次，对比两次状态码是否一致。
- 换一个网络环境或使用第三方状态码检测服务，做第三次请求。
- 若三次结果一致为 404 或 410，判定为真实死链；若只有原始 URL 返回 200，判定为缓存假象。
- 对判定为缓存的链接，先清理对应缓存层，再重新检测，不要直接改链接或加跳转。
适用条件：这套方法适合页面数量不多、需要人工确认的情况。如果站点有成千上万个链接，应先批量抓取状态码，再对状态码不一致的 URL 做上述三次复核，把人工时间集中在真正可疑的链接上。
常见错误与判断结果
最常见的错误是只用浏览器肉眼判断。浏览器会缓存页面，也会把 404 页面渲染成自定义样式，看起来像正常页面。另一个错误是看到搜索结果里还有旧标题，就认为链接没死，其实那只是快照。
判断结果可以这样归类：带参数请求返回 404、原始 URL 返回 200，说明缓存层仍在提供旧响应；带参数和原始 URL 都返回 404，说明链接确实失效；两次都返回 200 但内容不同，说明可能存在多版本缓存，需要检查缓存键和 Vary 响应头。
下一步：先挑出状态码不一致的 URL，按上面的三次请求法逐个复核，确认是缓存假象后再决定是否清理缓存，而不是急着修改链接。
