404页面优化：同一地址因设备或登录状态返回不同内容怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ede089e4ab41.html
📄
404页面优化：同一地址因设备或登录状态返回不同内容怎样对照
先不要急着改404页面。把同一URL在“设备差异”和“登录状态差异”两个维度上分别取样，用原始响应体而不是肉眼观感来对照，才能判断该地址到底是同一份404、被个性化改写的404，还是应当保留的软404。若两种状态的响应体主体一致、仅导航或推荐模块不同，通常属于可保留的模板差异；若登录后返回200且正文为空壳，则要按软404处理，决定改写还是退出。
先固定取样条件，再谈内容差异
对照的前提是请求本身可复现。至少固定四项：请求方法、是否携带Cookie、User-Agent、Accept-Language。移动端与桌面端最容易被混淆，因为很多站点靠User-Agent做跳转或裁剪导航，而不是真的返回不同正文。
建议用curl分别抓取四组：桌面未登录、桌面已登录、移动未登录、移动已登录。每组保存状态码、响应头和响应体。假设某站对未登录桌面返回404，对已登录桌面返回200并附带“内容不存在”提示，这两者就不是同一状态，后续处理方向完全不同。
三类差异，对应三种取舍
保留：仅外围模块不同
如果四组响应的正文主体一致，差异只出现在登录用户名、推荐位、广告位或底部导航，那么这仍是同一个404页面。保留现有模板即可，把精力放在状态码是否稳定为404、正文是否给出返回入口和搜索框。此时不需要为登录态单独做一套404。
改写：正文被个性化替换
常见于登录后把“页面不存在”替换成“你可能想找的内容”，并追加推荐列表。若状态码仍是404、核心提示仍在，只是补充了引导模块，可以改写而非删除，但必须保证未登录状态也能看到明确的404提示，避免爬虫和首次访客拿到一篇像正常内容的页面。
退出：登录态返回200且无有效正文
这是最需要优先处理的软404。判断依据不是“登录后能看到页面”，而是响应码与正文实际信息量是否匹配。若登录后返回200、正文只有一句“内容已删除”或空白容器，应退出这种个性化返回，改回404状态码，再决定是否在404模板内展示推荐内容。动作上先改服务端分支，再回归四组请求，确认状态码一致后才继续做页面视觉优化。
用可核对的证据区分不同解释
同一地址返回不同内容，至少有三种合理解释，不能只凭一次抓取下结论：
- 设备识别导致模板切换，缓存键包含User-Agent或设备类型；
- 登录态触发权限或个性化分支，缓存键包含Cookie或会话；
- CDN或反向代理按地域、语言返回不同缓存副本。
区分方法是看响应头中的缓存标识与Vary字段，再对照响应体差异位置。若差异集中在导航和推荐模块，多半是模板分支；若正文主体也变了，才需要怀疑缓存副本或权限逻辑。请求量或抓取量归零不能单独证明处理正确，也可能是抓取预算转移或临时屏蔽，需结合状态码分布一起看。
一个注明假设的对照例子
假设某站对/old-page在未登录桌面返回404，在已登录桌面返回200并显示“该内容已迁移”。按上面的取样，先保留未登录404模板，再把登录分支改为404，并在404模板内放置迁移提示。改完后重抓四组请求，若四组均为404且正文提示一致，说明处理方向成立；若登录组仍为200，则继续排查会话中间件或缓存层，而不是先改前端样式。
最后提醒一点：robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录。对照差异时以实际响应为准，别用这些外围配置替代状态码判断。
