死链接修复方法：同一地址因设备或登录状态返回不同内容怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3c89c65e68d9.html
📄
死链接修复方法：同一地址因设备或登录状态返回不同内容怎样对照
先给结论：不要急着改规则，而是把“同一地址”拆成可复现的请求条件，分别记录状态码、最终跳转地址和可见正文，再判断差异来自设备识别、登录态还是缓存。对照时以匿名、无 Cookie、固定 User-Agent 的请求为基线，登录态和移动端只作为变量逐项叠加，否则你无法分清是死链接没修好，还是被另一套内容覆盖了。
假设情境：一次改链后出现的两种结果
假设某站点把一批失效旧链统一 301 到新栏目。运营在桌面浏览器登录后台时打开旧链，看到的是正常新页面；用手机匿名访问同一旧链，却停在一个提示页。此时有两种看似合理的做法：一是直接再补一条跳转规则，二是先冻结改动、把差异条件对照清楚。选择条件在于差异是否可稳定复现——如果换设备、退出登录后结果就变，说明问题不在跳转本身，而在内容协商或权限判断。
第一步：固定基线请求，排除登录态干扰
用匿名会话、无 Cookie、固定 User-Agent 请求目标地址，记录三样东西：HTTP 状态码、Location 响应头指向的最终地址、以及渲染后正文里是否出现有效内容。登录态下返回 200 不代表匿名用户也能看到，因为很多站点对未登录访客做了内容降级或重定向。把匿名结果当作基线，登录结果只标注“仅在登录条件下成立”，这一步的结果决定后续是查跳转链还是查权限与内容协商。
第二步：叠加设备与 UA，判断是否内容协商
在基线之上单独改变 User-Agent，分别模拟桌面与移动端，其余条件保持不变。若只有移动端 UA 返回不同状态或不同正文，常见合理解释包括：服务端按 UA 做了跳转、CDN 或反向代理按设备类型分流、页面本身用响应式但服务端另有一套移动判断。此时不要断言“死链已修复”，因为移动端访客实际拿到的仍是另一条路径，需要把该路径也纳入跳转链核对。
对照记录建议保留的字段
- 请求条件：是否登录、User-Agent、是否带 Cookie、是否走缓存。
- 响应结果：状态码、最终地址、正文首段是否与目标页一致。
- 复现性：同一条件重复请求是否稳定，还是时有时无。
第三步：区分缓存、CDN 与源站三层的差异
同一地址在不同条件下返回不同内容，也可能是缓存层分别存了不同版本。判断方法是给请求加一个唯一查询参数绕开缓存，再与正常请求对比：若带参数的结果一致、不带参数的结果分裂，说明差异更可能来自缓存键设计，而不是源站逻辑。需要说明的是，抓取量或某状态码统计归零并不能单独证明处理正确，它也可能是抓取被限制、日志采样或缓存命中造成的假象。
第四步：按代价选择修复动作
如果差异只出现在登录态，通常不必为匿名死链再补规则，因为匿名基线已经正常；如果差异出现在移动端且稳定复现，则要改的是设备分流规则或移动跳转目标，而不是再加一条 301。若差异时有时无，优先排查缓存而非改跳转，否则你会在源站叠加越来越多互相冲突的规则。选择哪种做法，取决于差异是“条件稳定”还是“随机出现”——前者改配置，后者先清缓存并统一缓存键。
最后提醒一个容易踩的边界：用 robots.txt 限制抓取不等于移除索引，站点地图也不保证收录，这两件事都不能替代对实际返回内容的对照。把匿名基线、设备变量、缓存变量分开记录后，你才能确定下一步是修跳转、修权限还是修缓存，而不是凭一次登录访问就宣布死链已处理完毕。
