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

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

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

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

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

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

原始URL与规范化后的URL，包含协议、主机名、路径、查询字符串，大小写和末尾斜杠保持原样。
请求方法，通常是 GET 或 HEAD；两者结果可能不同，需注明。
响应状态码，如 404、410、301、302、200。
响应头中的 Location、Content-Type、Cache-Control、X-Robots-Tag 等字段。
请求时间与时区，以及发起请求的工具名称和版本。
发起请求的网络位置，例如本机、服务器、不同地区的节点。

这些字段合在一起，才能让另一个人复现同一请求并得到可对照的结果。缺少时间或网络位置，跨地区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，最好再从服务器侧或另一个网络环境重复一次，比较两次结果是否一致。两次不一致时，问题可能出在边缘节点缓存或地域解析，而不是源站本身。

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

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

命令行原始响应：可复现性最高，适合定位状态码和跳转链，但只代表发起请求的那个网络位置。
服务器访问日志：能证明某个时间点确有请求到达源站及其状态码，适合与命令行结果对照；若请求被CDN拦截未回源，日志里可能没有记录。
第三方爬虫工具报告：适合批量发现，但结果依赖其抓取频率、UA和节点，只能作为线索，不能单独作为最终结论。
搜索引擎后台的抓取或索引报告：反映的是该搜索引擎的观察，存在延迟，且不同搜索引擎分别统计，不能互相替代。

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

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

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

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

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