死链接检测，同一地址因设备或登录状态返回不同内容怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9bb0dd5a56eb.html
📄
死链接检测，同一地址因设备或登录状态返回不同内容怎样对照
先不要把这个地址判定为死链，也不要直接判定为正常。正确做法是把它当作“同一地址、多种返回结果”的对象，把设备、登录状态、请求头和返回内容分别记录下来，再看差异是来自权限、客户端识别还是缓存。只有把返回结果与请求条件绑定，后续修复或移除才有可核对依据。
先固定一个可复查的请求条件
假设你手里有一个商品详情地址，桌面浏览器未登录时返回 200 且能看到正文，手机浏览器未登录时返回 200 但正文为空，登录后又能看到正文。此时“死链检测”的结果不能只写“正常”或“异常”，而应写成三组条件与结果。每组至少记录：请求地址、设备类型或 User-Agent、是否携带登录凭证、响应状态码、最终跳转地址、页面可见正文是否与目标内容一致。若使用命令行工具，可把关键请求写成类似 curl -I -A "移动端UA" 地址 的形式，但状态码只能说明响应层，不能说明正文是否可用。
固定条件的意义在于：后续任何人复查时，不必猜测当时是登录还是未登录、是桌面还是移动端。若只记录“打开是空白”，这个结论无法区分权限不足、客户端被识别为异常、页面脚本未执行或缓存返回旧内容。
把分歧转成三栏对照，而不是争论谁看到的才对
多个角色对同一地址有不同理解时，最有效的动作是建立三栏对照：左栏写请求条件，中栏写实际返回，右栏写该结果对死链接判断的影响。可参考下面的假设例子。
- 未登录桌面端：返回 200，正文可见，链接状态记为“公开可访问”。
- 未登录移动端：返回 200，正文为空，链接状态记为“待确认，不能直接当死链”。
- 登录桌面端：返回 200，正文可见，链接状态记为“登录后可访问”。
- 退出登录后再次请求移动端：仍为空，说明不是登录状态切换造成的偶发现象。
这个对照表的作用不是证明谁对，而是把“同一地址不同内容”拆成可验证的分支。若某个分支返回 404 或 410，才更接近死链判断；若返回 200 但正文为空，需要继续检查是客户端识别、脚本渲染还是权限控制。请求量或抓取量归零也不能单独证明该地址已死，因为可能是抓取预算调整、robots 规则变化或统计口径变化。
区分权限差异、客户端差异与缓存差异
同一地址返回不同内容，常见原因至少有三类，处理动作不同。
- 权限差异：未登录返回登录提示或空正文，登录后返回完整内容。此时链接并未消失，但对外部访问者可能不可用。下一步应确认目标受众是谁，以及是否需要公开可访问的替代地址。
- 客户端差异：服务端根据 User-Agent 或设备能力返回不同模板。若移动端模板缺少正文，而桌面端正常，应检查模板输出和内容注入逻辑，而不是只改状态码。
- 缓存差异：同一地址在不同节点或不同登录状态下命中不同缓存副本。清除缓存后若结果一致，说明此前差异来自缓存；若仍不一致，回到权限或客户端分支继续查。
这三种原因可能同时存在。例如移动端未登录既受客户端识别影响，又受权限控制影响。此时不要合并成一句“移动端有问题”，而应分别改变一个条件再观察：只换设备、不换登录状态；只换登录状态、不换设备。每次只动一个变量，才能知道是哪一个条件改变了返回结果。
把对照结果转成下一步动作
完成对照后，按结果决定动作。若公开访问者看到的是空正文或登录墙，而该地址本应公开，优先修复内容输出或权限配置；若该地址本就只对登录用户开放，则不应把它当作公开死链处理，而应确认内链、站点地图或外部引用是否错误地把它当作公开页面。若返回 404 或 410，且多个条件一致，才进入替换或移除流程。
修复后不要只复查状态码。用同一组条件重新请求：未登录桌面端、未登录移动端、登录桌面端，分别确认正文是否出现、是否与目标内容一致。若状态码从 404 变为 200 但正文仍为空，说明修复未完成。若状态码仍为 200 但正文已恢复，说明此前问题不在响应层。把这个复查结果写回对照表，下一次遇到同类地址时可直接复用判断路径。
需要提前写明的适用条件
这套对照方法适用于你能控制或至少能重复请求的地址。若地址属于第三方且无法改变登录状态或设备条件，只能记录你能观察到的分支，并明确标注未验证的分支。robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录；这些规则不能替代对实际返回内容的核对。若涉及多个搜索引擎或平台，应分别核查其支持情况，不要把某一个来源的结果直接套用到全部渠道。对照记录的目的是让分歧变成可复查的条件与结果，而不是用一个状态码结束讨论。
