死链检查方法，同一地址因设备或登录状态返回不同内容怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8083f9192160.html
📄
死链检查方法，同一地址因设备或登录状态返回不同内容怎样对照
先给结论：不要用“一个地址一个状态码”的思维去对照，而要把同一URL拆成“设备指纹 + 登录态 + 请求头 + 时间点”四要素分别取样，再判断差异属于内容分流、权限拦截还是真正的死链。只有先确认差异来源，后续的保留、重定向或下线动作才不会误伤仍然有价值的版本。
假设情境：一条旧活动页在三个环境下给出三种结果
假设某站有一批旧活动页准备退出，但其中部分内容仍有引用价值。运维在桌面浏览器登录后台时看到页面正常，退出登录后看到“请先登录”，用手机浏览器访问又跳转到首页。此时若直接把这条URL记为死链并删除，很可能删掉的是仍有流量价值的入口。三种结果并不矛盾，它们只是命中了不同的服务端分支。
对照的第一步不是换工具重测，而是记录每次请求的完整条件：是否携带登录Cookie、User-Agent是桌面还是移动、是否带来源页、请求时间是否落在活动配置的生效区间内。把这些条件写进同一张对照记录，才能让“不同内容”变成可解释的变量，而不是互相矛盾的结论。
用请求头与登录态做变量隔离
实际操作时，用命令行工具固定一个变量、只改另一个变量，比在浏览器里反复切换更可靠。例如先不带任何Cookie请求一次，再带上登录Cookie请求一次，对比状态码、跳转目标和响应体首屏文字：
curl -I -A "Mozilla/5.0 (iPhone...)" https://example.com/old-page
如果匿名请求返回302指向登录页，而带Cookie请求返回200，说明这条URL并未失效，只是被权限策略拦截。若两种请求都返回200但正文不同，则更可能是设备分流或A/B配置在起作用。这个动作的结果直接决定下一步：前者应保留URL并评估是否需要放开匿名访问，后者应去查分流规则而不是查链接本身。
需要提醒的是，robots.txt里的抓取限制只约束爬虫行为，不等于把页面从索引中移除；即使你在robots里屏蔽了这条路径，已经收录的版本仍可能出现在结果里。因此对照登录态差异时，不能把robots当成内容下线的替代手段。
区分三种常见差异来源的证据特征
- 权限拦截：匿名请求被重定向到登录或验证页，登录后内容完整；状态码多为302或401，响应体含登录提示文案。
- 设备分流：桌面与移动端返回不同模板或不同跳转目标，但两者都能拿到主体内容；差异集中在模板层而非数据层。
- 真实死链：所有设备、所有登录态都返回404或410，且响应体不含任何有效内容；这类才适合进入下线流程。
三种来源的处置方向完全不同。把权限拦截误判为死链，会删掉仍有引用的入口；把真实死链误判为分流，会让无效URL长期占用抓取预算。判断依据应落在“是否所有条件都失败”这一条上，而不是某一次请求的结果。
对照之后，旧内容的去留怎么定
确认差异来源后，再决定保留哪一部分。若页面在登录态下仍有价值、匿名态只是被拦截，可以考虑保留URL并调整访问策略；若页面在所有条件下都无有效内容，则进入下线或重定向流程。此时站点地图只能作为发现入口的辅助，不保证收录，也不能替代对每条URL的逐项确认。
一个可执行的顺序是：先按上述方法产出对照记录，标记每条URL的差异类型；再对“仅权限拦截”的条目单独列出，评估是否值得保留；最后才处理确认失效的条目。这个顺序的价值在于，它把“要不要删”建立在可复查的证据上，而不是某一次访问的直观印象。
如果你只做了一件事，那就把每次请求的设备和登录态写进记录，因为缺少这两个字段，后续任何对照都无法复现，也无法向其他人解释为什么同一地址会出现不同结果。
