网站死链检查：页面内容相同但响应头不同会影响哪些判断
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /9d59b74493d9.html
📄
网站死链检查：页面内容相同但响应头不同会影响哪些判断
在网站死链检查里，页面正文看起来完全一样，但响应头不同，往往意味着这不是同一个结果：状态码、重定向、缓存与内容协商都会改变“这个地址是否还有效”的结论。先看响应头再决定是否把它算作死链，比只看页面内容更可靠。
先分清“内容相同”和“结果相同”
假设一个场景：某站有一批旧链接，打开后都能看到同一篇介绍页。抽查其中一条时，正文与目标页一致，但响应头显示的是 301 跳转；再抽查另一条，正文也一致，响应头却是 200。两条链接在人工浏览时几乎无差别，但在死链检查里应被分成两类：前者是重定向，后者是直接可访问。若站点后续把重定向规则移除，前者会立刻失效，而后者不会。这个差异决定了修复优先级，也决定了你要不要继续追这条链接的来源。
判断时先固定一个前提：以最终返回的响应头为准，而不是以浏览器渲染出的页面为准。浏览器会跟随跳转、使用缓存、按 Accept-Language 返回不同版本，这些都会让“看起来一样”变得不可靠。
响应头里最影响死链判断的几组信号
状态码与重定向链
200、301、302、404、410、403、5xx 对死链检查的含义不同。301 和 302 表示地址仍可用但目标已变，不应直接记为死链；404 和 410 表示资源不可用，其中 410 更明确地表达“已移除”。如果一条链接经过多次跳转才到达 200，要记录跳转次数和最终地址，因为链路过长本身可能被判定为异常，且中间任一跳失效都会让整条链接变成死链。
实际操作：对每条疑似死链请求一次并禁止自动跟随跳转，记录首个响应码、Location 头和最终响应码。这个动作的结果会直接决定下一步：若首个响应码是 3xx 且最终是 200，应归入“待替换链接”而不是“已失效链接”；若首个响应码就是 404，才进入删除或改链流程。
缓存头与内容协商
Cache-Control、Expires、ETag、Vary 会影响你看到的是实时结果还是旧结果。Vary 尤其关键：当它包含 Accept-Language 或 User-Agent 时，同一地址可能对不同请求返回不同内容，甚至不同状态码。此时“内容相同”只代表你这次请求命中了某个版本，不能代表所有访问者都得到同样结果。
假设例：某地址对中文请求返回 200 和完整页面，对英文请求返回 404 和空白页。若只以中文环境抽查，会误判为正常链接；规模化检查时若请求头不统一，就会出现大量互相矛盾的记录。解决办法是先统一请求头，再对关键地址做多语言、多设备维度的抽样复核。这个动作会增加检查时间，但能避免把“部分可用”当成“全部可用”。
内容类型与长度
Content-Type 和 Content-Length 能暴露“页面看起来一样但实际不同”的情况。例如返回 text/html 但长度为 0，或返回 application/json 却带着错误信息，正文渲染后可能仍显示一个空壳页面。死链检查若只看渲染结果，会漏掉这类软 404。把内容类型和长度纳入判断，可以区分“真页面”和“伪装成页面的错误响应”。
规模化后为什么不能照搬单条样本的结论
单条样本成立，不代表整站规则成立。常见例外有三类：
- 同一路径在带与不带尾斜杠时返回不同状态码，样本只覆盖了其中一种写法。
- 部分旧链接依赖服务端重定向规则，规则按目录或参数匹配，换一个参数就失效。
- CDN 或反向代理对部分路径缓存了旧响应，导致同一地址在不同节点返回不同结果。
因此，规模化检查要记录的不只是“是否可访问”，还要记录响应码、跳转链、缓存命中和请求头。若某项统计突然归零，不能单独证明处理正确：可能是检查脚本改了请求方式，可能是缓存全部命中，也可能是目标站临时不可达。需要换一个请求头或换一个网络位置复核，再决定是否调整规则。
一个可落地的判断顺序
- 对每个地址发起不带自动跳转的请求，记录首个状态码与 Location。
- 若为 3xx，继续跟到最终地址，记录跳转次数与最终状态码。
- 若最终为 200，再核对 Content-Type 与内容长度，排除空壳页。
- 若涉及多语言或多设备，用统一请求头抽样复核，确认 Vary 是否造成差异。
- 把结果分为“直接可用”“重定向可用”“明确失效”“疑似软 404”四类，再决定改链、保留或删除。
这个顺序的价值在于：它把“内容相同”拆成可验证的响应事实。下一步该做什么，取决于首个响应码和最终响应码的组合，而不是取决于页面看起来是否正常。
边界与常见误判
robots.txt 的抓取限制不等于可靠的索引移除，被限制抓取不代表链接已从结果中消失；站点地图也不保证收录。HTTPS 不保证安全无漏洞或排名，它只说明传输层有加密，与死链判断无关。不同搜索引擎对状态码和重定向的处理须分别核查，不能拿一个引擎的表现直接推断另一个。把这些边界写进检查记录，能减少“看起来修好了”的误判。
回到开头的假设情境：如果两条内容相同的链接分别返回 301 和 200，正确做法不是统一标记为正常，而是把 301 那条列入待替换清单，并在替换后重新请求一次确认最终响应。只有响应头与内容同时符合预期，才算完成一次可靠的死链处理。
