网站死链检查工具：同一地址因设备或登录状态返回不同内容怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /21b9131062e9.html
📄
网站死链检查工具：同一地址因设备或登录状态返回不同内容怎样对照
先给结论：不要把这个现象当成工具误报，也不要急着删链接。更常见的真相是，你检查的其实是同一路径下的两套响应：一套给匿名或桌面端，一套给已登录或移动端。要判断该信哪一套，先固定一个变量——登录状态或设备类型，再看状态码、最终地址和正文摘要是否三者一致。只有三者都一致，那个结果才能作为下一步决策的依据。
先分清两种解释：内容协商，还是访问控制
同一地址返回不同内容，通常只有两类解释。
- 内容协商：服务端根据
User-Agent、Accept-Language或 Cookie 返回不同版本，但页面本身对所有人存在，只是呈现不同。 - 访问控制：未登录或非特定设备被重定向到登录页、验证页或首页，目标内容实际上没有对匿名访问者开放。
这两类解释的处置方向完全相反。内容是协商的，链接对搜索引擎和匿名用户仍然有效；是访问控制的，匿名抓取拿到的就是一个空壳，链接价值需要重新评估。
能区分两者的三组证据
不要只看状态码。状态码 200 也可能是一个登录页，状态码 302 也可能是正常的语言跳转。更可靠的判断来自下面三组证据。
第一组：最终地址是否改变
记录请求的原始地址和最终落地的地址。如果匿名访问被送到 /login 或站点首页，而登录后停在原路径，这基本指向访问控制。如果两者最终地址相同、只是正文不同，更可能是内容协商。
第二组：正文摘要是否指向同一实体
分别抓取标题、一级标题和首段前若干字符。两套响应如果描述的是同一个对象（同一商品、同一篇文章），差异只是排版或推荐模块，属于协商；如果匿名版本只有登录提示或通用导航，属于访问控制。
第三组：去掉 Cookie 后是否复现
用无 Cookie 的请求重试一次。若匿名结果稳定复现，说明差异由登录态触发；若去掉 Cookie 后两套结果趋同，说明之前的差异来自会话，而不是设备。
一个假设例子：怎样把对照做成可复查的记录
假设某商品页在桌面匿名访问时返回 200，在移动端已登录时也返回 200，但正文一个是完整规格，一个是“请登录查看”。这时可以按下面的顺序记录，而不是直接判定链接失效。
- 固定设备与登录状态，各抓一次，保存状态码、最终地址、标题、首段。
- 用无 Cookie 请求再抓一次，确认匿名结果是否稳定。
- 若匿名结果始终是登录提示，把该地址标记为“需登录才可见”，而不是“死链”。
- 若匿名结果与登录结果指向同一实体，标记为“内容协商”，链接保留。
这个动作的价值在于：它把“工具报错”转成了可复查的证据。下一步无论是改跳转规则还是保留链接，都有依据，而不是凭一次抓取下结论。
对照之后，什么条件下该改、什么条件下不该改
如果证据指向访问控制，且该内容本来就不该对匿名用户开放，那么链接本身没有错，需要调整的是死链检查工具的判定规则，把这类地址排除或单独归类。如果证据指向访问控制，但该内容本应公开，那问题出在服务端配置，应优先修正跳转或权限，而不是删链接。
如果证据指向内容协商，通常不需要改动链接。但要注意：不同搜索引擎对内容协商的处理并不一致，是否影响抓取需要分别核查，不能用一个引擎的表现推断另一个。
还有一个容易混淆的点：robots.txt 的抓取限制不等于可靠的索引移除。即使你屏蔽了某个设备或路径，也不能据此认为该地址已经从索引中消失。同理，站点地图不保证收录，HTTPS 也不保证安全无漏洞或排名。这些都不能替代上面那三组证据。
把对照固化成流程，而不是一次性排查
设备与登录状态会随业务变化而变，今天成立的对照结论，改版后可能失效。建议在每次抓取时同时记录设备标识、登录状态和请求时间，并把它们和状态码、最终地址、正文摘要放在一起。这样当同一地址再次出现差异时，你能快速判断是新增了访问控制，还是内容协商规则被改动。
如果一次抓取显示请求量或某个统计归零，也不要单独把它当成处理正确的证明。归零还可能来自抓取频率下降、路径被合并或统计口径变化。只有把状态码、最终地址和正文摘要三者放在一起看，才能排除这些合理解释。
对照的目的不是让所有设备返回完全相同的内容，而是让每一次差异都有明确归属：要么是协商，要么是控制。归属清楚了，链接该留还是该改，自然就有答案。
