SEO死链处理:怎样取得可复查的状态证据?先固定请求与响应记录

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

SEO死链处理:怎样取得可复查的状态证据?先固定请求与响应记录

要取得可复查的状态证据,核心是让每一次死链检查都能被第三方按同样的请求重放:记录完整URL、请求时间、请求方法、响应状态码、最终跳转地址、响应头中的关键字段,以及检查所用的工具和网络环境。只截一张“404页面”的图不够,因为无法证明请求的是哪个URL、是否经过跳转、是否被CDN或缓存改写。下面按证据链的构成、采集方法、条件比较和落地步骤展开。

一份可复查的死链证据应包含哪些字段

判断证据是否合格,可以看它能否回答四个问题:请求了什么、服务器回了什么、中间经过了什么、谁在什么条件下测的。建议每条死链至少保留以下内容:

这些字段合在一起,才能让另一个人复现同一请求并得到可对照的结果。缺少时间或网络位置,跨地区CDN差异就无法解释;缺少请求方法,HEAD返回404而GET返回200的情况会被误判。

用命令行采集原始响应,而不是只看页面截图

最直接的方式是用命令行工具保存原始响应。以下命令只作为示例,实际使用时替换为待检查的URL:

curl -sS -o /dev/null -D - -A "Mozilla/5.0" "https://example.com/old-page"

这条命令会输出响应头,包含状态码和跳转信息。若要看完整跳转链,可加 -L 并配合 -w 输出每一跳的地址与状态码。把输出重定向到文本文件,连同执行时间一起保存,就形成了可复查的原始记录。对批量URL,可写一个循环把每个URL的响应头和状态码追加到同一份日志,每行带上时间戳。

需要注意:命令行结果受本机DNS、代理和出口IP影响。如果站点使用CDN,最好再从服务器侧或另一个网络环境重复一次,比较两次结果是否一致。两次不一致时,问题可能出在边缘节点缓存或地域解析,而不是源站本身。

工具检查、日志与搜索引擎报告的证据强度不同

不同来源的证据,可复查程度和适用条件差别很大,选择时要看你要证明什么:

一个常见误区是把 robots.txt 中的禁止抓取当成移除索引的手段。抓取限制不等于可靠的索引移除:被禁止抓取的URL仍可能因外部链接出现在结果中,只是爬虫无法读取页面内容来更新判断。同理,站点地图提交不保证收录,HTTPS也不保证安全无漏洞或排名提升,这些都不能当作死链已处理完毕的证据。

按条件选择采集方式并完成一次可复查检查

可以按下面的顺序执行,并根据站点条件调整:

  1. 先确定检查范围:是单个已知死链,还是全站批量。单条用命令行即可;批量再考虑爬虫工具加日志对照。
  2. 对每条URL同时记录 HEAD 和 GET 的结果。若两者状态码不同,以 GET 为准并注明差异。
  3. 保存原始响应头文件,文件名包含日期和URL特征,避免覆盖历史记录。
  4. 从服务器访问日志中检索同一时间段的同一路径,确认源站实际返回的状态码。
  5. 若两处结果冲突,检查是否存在CDN缓存、重定向规则、大小写或查询参数差异,再重复一次请求。
  6. 把结论写成“现象—证据—可能原因”三列。尚未定位的原因标注为可能,不要写成已确认。

判断结果时,404 和 410 都表示资源不可用,但语义不同;301 与 302 对后续处理的影响也不同。若状态码是 200 却显示错误页,这属于软404,需要单独判断,不能仅凭状态码认定正常。证据保存后,下一步是拿这份记录去核对站内链接和跳转规则,确认死链是内容删除、路径变更还是配置错误造成的,再决定修复、重定向还是保留410。

图1 图2

nginx