网站死链检查，同一地址因设备或登录状态返回不同内容怎样对照

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

网站死链检查，同一地址因设备或登录状态返回不同内容怎样对照

先给出结论：不要试图找到一个“唯一正确”的返回结果，而要把同一地址在不同设备、登录状态下的响应拆成可对照的记录，再判断哪一份才是死链检查应该依据的版本。设备差异通常来自User-Agent分流、缓存或地域节点，登录差异通常来自会话、权限或个性化渲染。两者混在一起看，会把正常的差异化响应误判成死链，也可能把真正的404掩盖掉。

先固定对照对象，而不是固定结论

选一个你手上正在排查的URL，把它当作唯一对象。先记录三件事：完整地址（含协议和查询参数）、请求时是否携带Cookie或登录令牌、请求头里的User-Agent。这三项不固定，后面的对照就没有意义。

常见误区是拿桌面浏览器登录后的页面，去和手机未登录的抓取结果比。这两者从请求发起那一刻就不是同一个输入，结果不同是必然的，不能直接当作死链证据。真正需要对照的是：同一地址、同一组请求头、仅改变设备标识或仅改变登录状态，观察响应差异。

设备差异与登录差异要分开验证

把变量拆开，才能定位差异来源。可以用下面的顺序做一轮对照：

  1. 用桌面UA、未登录状态请求一次，记录状态码、最终URL、页面标题和首屏可见文本。
  2. 只把UA换成移动端，其他不变，再请求一次，记录同样四项。
  3. 保持桌面UA，改为携带登录Cookie，再请求一次，记录同样四项。
  4. 如果站点有地域分流，再固定一个出口节点重复以上步骤。

如果第1步和第2步返回不同内容但状态码都是200，说明站点在做设备适配，这本身不是死链。如果第1步返回200、第3步返回404或跳转到登录页，说明登录状态改变了资源可见性，死链检查必须明确以哪个状态为准。

这里有一个实际动作：把每次请求的最终URL单独记下来。很多“同一地址不同内容”其实是发生了重定向。未登录时跳转到登录页，登录后跳回原页，两个最终URL不同，状态码也可能不同。只看初始地址会得出错误结论。记录最终URL之后，下一步就能判断该地址是内容页、跳转链还是被拦截的入口。

用一份可复查的记录表代替印象判断

对照结果要能复查，不能只靠“我这边打开是好的”。可以按下面的字段建一张简单记录表，每行对应一次请求：

记录完成后，先看状态码分布。如果同一地址在多数组合下返回200，只有个别组合返回404，优先怀疑该组合对应的资源或权限有问题，而不是整条地址已死。如果多数组合返回404，只有登录后返回200，说明这个地址对外不可见，死链检查应按未登录状态判定。

需要提醒的是，抓取量或请求量归零不能单独证明某个状态就是正确的。缓存过期、节点切换、限流、临时故障都可能造成同样的现象。判断依据应落在可重复的请求结果上，而不是某一次统计曲线的变化。

假设例子：一个只在登录后可见的页面

假设某地址在未登录时返回302到登录页，登录后返回200并显示正文。此时有两种处理选择：

选择一：按未登录状态判定为不可公开访问。适用于该页面本就不打算对搜索引擎或未登录用户开放。代价是，如果它被内部链接或站点地图引用，未登录抓取会持续看到跳转，死链检查会把它标记为异常入口。

选择二：按登录后状态判定为有效页面。适用于该页面确实需要登录才能查看，且你只关心登录用户能否正常访问。代价是，这种判定不能代表公开抓取结果，若把它当作公开可访问地址处理，后续外部检查仍会报错。

两种选择都成立，区别在于你检查的目标是“公开可达”还是“登录后可达”。选定之后，动作也随之确定：选前者就清理指向它的公开链接或调整入口；选后者就在记录中标注登录前提，避免和公开地址混在同一份死链清单里。

把差异结论写回检查流程

对照完成后，不要只留下一个“正常”或“异常”的标签。至少写清三件事：该地址在哪种设备与登录组合下返回什么、你以哪种组合作为判定基准、其他组合的差异属于预期适配还是待处理问题。

如果差异来自登录状态，后续检查应固定使用同一登录态，否则每次结果都会漂移。如果差异来自设备适配，后续应把桌面和移动两组结果都保留，而不是二选一。这样处理之后，下一次遇到同一地址返回不同内容时，你手里有可比对的基线，而不是重新从头猜。

图1 图2
nginx