死链检查：同一地址因设备或登录状态返回不同内容怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /52a316385fdd.html
📄
死链检查：同一地址因设备或登录状态返回不同内容怎样对照
先不要急着判定哪一方“看错了”。同一地址在不同设备或登录状态下返回不同内容，通常意味着它命中了不同的响应分支：设备识别、登录态、缓存键或地区路由都有可能。对照时把“谁在看”和“看到什么”拆成可核对的字段，比争论截图更有效。
先固定对照维度，再谈保留还是改写
对照的目标不是证明某个结果“正确”，而是找出差异由哪一层造成。建议固定以下字段：请求地址（含查询串）、请求方法、请求头中的 User-Agent 与 Cookie 是否存在、响应状态码、最终响应体中的关键标识、以及响应头里与缓存和跳转有关的字段。把这些字段记录在同一行里，差异才会变成可比较的对象。
如果同一地址在未登录状态下返回 200 并带完整内容，登录后返回 200 但内容被替换或收窄，这属于登录态分支，不是死链。如果未登录返回 200、登录后返回 404，则要区分是权限导致的内容不可见，还是资源确实已移除。前者通常应保留地址并改写可见性说明，后者才需要考虑退出或替换。
设备差异要落到具体证据上
设备差异最常见的来源是 User-Agent 判断、响应式资源的条件加载，以及 CDN 或反向代理按设备类型缓存不同版本。核对时不要只看渲染后的页面，还要看原始响应。可以在同一网络下用不同 User-Agent 发起请求，比较状态码和响应体首部；如果状态码相同而内容不同，问题多半在模板或缓存键，而不是链接本身失效。
假设某商品地址在桌面端返回 200 并包含购买入口，在移动端返回 200 但购买入口被替换为“请在桌面端打开”。这属于功能分支差异，链接没有死。此时保留地址、改写提示文案是合理选择；若移动端返回 404 且无任何替代内容，才进入退出或替换流程。
登录状态差异的三种处理前提
- 保留：未登录可见、登录后仍返回 200，只是内容按权限收窄。前提是地址本身有效，且未登录用户也能获得有意义的页面。下一步应检查该页是否被错误地当作死链提交移除。
- 改写：登录后返回 200，但内容变成登录引导或权限说明，且未登录版本才是主要入口。前提是地址承担了公开入口职责。下一步是把权限说明写清楚，并确认未登录版本仍可被抓取和索引。
- 退出：登录与未登录都返回 404 或 410，或登录后返回 404 且无替代内容。前提是资源确实不再提供。下一步才是从站点地图和内部链接中移除，并配置合适的跳转或保留 410。
这里有一个容易忽略的边界：robots.txt 的抓取限制不等于可靠的索引移除。即使某条规则挡住了抓取，地址仍可能因外部链接出现在结果中。对照时若发现登录态差异由 robots.txt 引起，应把它当作抓取控制问题，而不是死链处理问题。
把分歧转成可核对的项目
当多个角色对同一地址的状态有不同理解时，最有效的动作是建立一张对照记录，而不是继续在聊天里争论。记录至少包含：请求地址、设备或登录状态标记、状态码、关键响应片段、以及“下一步动作”一栏。下一步动作可以是“保留并观察”“改写提示”“退出并替换”，但必须写明触发条件。
例如，运营看到移动端 404 就认为链接已死，技术看到桌面端 200 就认为链接正常。对照记录会显示两者请求的 User-Agent 不同，且移动端 404 来自一个过期的设备路由规则。此时正确的下一步不是删除地址，而是修复路由规则并重新核对。这个例子是假设的，用于说明如何用字段区分原因，而不是断言某种设备一定会返回 404。
核对之后，动作如何影响下一步
如果核对结论是“保留”，下一步应检查该地址是否被误列入待移除清单，并确认未登录版本仍可访问。如果结论是“改写”，下一步应确认改写后的提示对未登录用户和已登录用户都成立，且不会把有效地址变成软 404。如果结论是“退出”，下一步才涉及跳转目标、站点地图更新和内部链接清理。
站点地图不保证收录，HTTPS 也不保证安全无漏洞或排名。这些事实不影响对照方法本身，但会影响你对“已经处理好了”的判断。请求量或抓取量归零同样不能单独证明处理正确，它也可能来自统计口径变化、缓存命中或抓取预算转移。把对照记录和后续动作绑定，才能让同一地址在不同设备或登录状态下的差异变成可复查的项目。
