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

网站死链检查怎样排除缓存造成的假象：先区分真404还是缓存旧响应

网站死链检查时，缓存造成的假象通常表现为：链接实际已经修复或指向新地址，但检查工具、浏览器或中间层仍返回旧的404或旧跳转。排除办法是绕过缓存重新请求，再对比源站返回、CDN缓存状态和页面实际内容。如果绕过缓存后返回200且内容正确，原404就是缓存假象；如果仍然404，则说明死链真实存在。

一个假设例子：修复后仍报404

假设某页面原地址为 /old-page，后来改到 /new-page，并配置了301跳转。站长用检查工具扫描，发现 /old-page 仍返回404。此时有两种可能：一是跳转规则没生效；二是检查请求命中了旧的缓存响应。不能直接判定为死链，需要按下面步骤区分。

1. 用带随机查询参数的地址请求，例如 /old-page?check=20240101，让缓存键发生变化。若返回301或200，说明原请求很可能命中了缓存。
2. 查看响应头中的缓存相关字段，例如 Cache-Control、Age、X-Cache。出现 HIT 或较大的 Age，说明响应来自缓存层。
3. 直接请求源站IP或临时绕过CDN，对比返回状态码和内容。若源站正常、缓存节点异常，问题在缓存刷新。
4. 检查页面内容是否与状态码一致。有些缓存会返回200但内容是旧的404页面，这种“软404”同样属于假象。

两种处理方案怎么选

方案一：先刷新缓存再复检。适用条件是确认源站已修复、跳转规则已生效，且只有部分节点或部分工具仍报错。做法是清除对应URL的CDN缓存和浏览器缓存，等待缓存过期后重新扫描。判断结果是复检返回200或301，且内容为新页面。

方案二：直接以源站响应为准修正检查流程。适用条件是缓存刷新权限有限、缓存周期较长，或检查工具本身缓存了结果。做法是在死链检查任务中关闭工具缓存、附加随机参数，或直接对源站发起请求。判断结果是扫描结果与源站一致，不再受中间层影响。

两种方案的分界在于：问题只出现在访问链路，还是源站本身也没修好。源站没修好时，刷新缓存没有意义；源站已修好而缓存未更新时，只改源站也不够。

检查时容易犯的错误

• 只看状态码，不看响应内容。缓存返回200但内容是旧404页，会被误判为正常。
• 用同一个URL反复请求。缓存命中后结果不变，无法暴露真实状态。
• 把浏览器缓存、CDN缓存和检查工具缓存混为一谈。三者需要分别清理和验证。
• 用robots.txt限制抓取来代替修复死链。robots.txt只控制抓取，不等于可靠的索引移除，也不能让已存在的死链消失。
• 认为提交站点地图就能解决。站点地图不保证收录，也不保证缓存更新。

可执行的复检清单

每次网站死链检查后，按以下顺序确认：

1. 记录原始请求的状态码、响应头和响应时间。
2. 附加随机查询参数重新请求，对比状态码是否变化。
3. 查看缓存命中标识，判断响应是否来自缓存层。
4. 绕过缓存请求源站，确认源站真实返回。
5. 检查返回内容是否为目标页面，排除软404。
6. 清理相关缓存后再次扫描，确认结果稳定。

如果复检后状态码和内容都正确，就可以把该条从死链清单中移除；如果绕过缓存仍然404，就按真实死链处理，检查跳转规则、文件是否存在以及服务器配置。下一步是建立固定复检流程：每次修复后先绕过缓存验证源站，再清理缓存并二次扫描，避免把缓存假象当成真实死链反复处理。