用死链工具扫出一批404,并不等于这些地址真的都坏了。缓存造成的假象通常来自三层:浏览器或CDN返回旧页面、工具沿用了上一次的抓取结果、页面对爬虫和真实用户给出不同响应。要排除它,核心做法是绕开缓存做一次独立请求,把工具结果与服务器当前响应逐条对照,再决定哪些链接值得修。
出现下面几种现象时,先怀疑缓存,而不是直接改链接或删页面:
这些现象说明工具拿到的响应可能来自中间缓存层,而不是源站当前状态。此时不要急着把链接标记为死链,先做下面的独立验证。
最直接的一步,是在URL后加一个当次生成的查询参数,让缓存键发生变化,强制回源:
https://example.com/page?cachebust=20240613a
在命令行里可以这样看响应头:
curl -I "https://example.com/page?cachebust=20240613a"
重点看状态码和几个头部:Cache-Control、Age、X-Cache、CF-Cache-Status(如果用了对应CDN)。Age大于0说明这份响应来自缓存;带随机参数后仍返回404,才更可能是源站真实状态。
适用条件:该方法适合静态页和常规动态页。如果站点对查询参数做了特殊路由,随机参数可能改变页面行为,这时改用curl直接请求源站IP并带上Host头,或临时在CDN后台对该URL执行刷新后再测。
时间和人手有限时,不要全量复核,按下面的优先级抽样即可:
验收信号很明确:复扫后同一批URL的报错数量下降,且剩余报错在独立请求下依然成立。如果复扫数量没变,说明问题不在缓存,而在链接本身、路由规则或服务器配置。
缓存之外,还有几类情况会让死链工具的结果看起来像假象,需要分开判断:
选定工具报错最集中的一个小节,按上面的对照表跑一遍:带随机参数请求、记录状态码与缓存头部、复扫同一批URL。把确认属于缓存假象的URL从修复清单里去掉,只对独立请求仍为404的地址安排改链或做301。这样在时间和人手有限的情况下,先处理的是真实死链,而不是缓存留下的旧快照。