收录提交：同一地址因设备或登录状态返回不同内容怎样对照

📍 WDQWDWQD987AAAAA:216.73.217.89
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /26c515305543.html
📄

收录提交：同一地址因设备或登录状态返回不同内容怎样对照

先把“同一地址”拆成两条可复现的访问记录，再决定提交哪一个版本。假设一个场景：某旧产品线已停止维护，但页面仍保留部分可下载文档。你用桌面浏览器未登录访问时看到完整文档列表，用手机浏览器或已登录账号访问时却只看到一句“内容已迁移”。此时不能凭印象选一个版本提交，而要先判断差异来自哪一层，再决定提交对象和退出动作。

先判断差异发生在服务端还是客户端

差异原因不同，处理动作完全不同。可用一个最小对照来区分：

这一步的产出不是结论，而是一条可复核的记录：请求地址、请求头中的 User-Agent 与 Cookie 有无、返回 HTML 主体是否一致、渲染后可见文本是否一致。只有记录到“HTML 主体不同”时，才需要进一步判断是否要按不同版本分别提交；若只是渲染差异，提交时通常以服务端返回的 HTML 主体为准。

用假设情境走一遍取舍

继续上面的假设：旧产品线要退出，但文档仍有价值。你打算保留文档页，撤掉旧产品介绍页。此时出现三种访问结果：

  1. 桌面未登录：显示文档列表和旧产品介绍入口。
  2. 移动未登录：只显示文档列表，旧产品介绍入口被折叠隐藏。
  3. 已登录：显示文档列表，但旧产品介绍入口指向一个需要权限的页面。

这时要先决定“退出”的对象是哪一个。若旧产品介绍入口只是被隐藏，实际 URL 仍可访问，那么退出动作应落在该 URL 本身，而不是落在文档列表页。若该入口在已登录状态下指向权限页，则要确认权限页是否返回了可被索引的内容。一个实际动作是：对旧产品介绍 URL 单独发起一次未登录请求，记录返回状态码和 HTML 主体。若返回 200 且主体仍包含旧产品介绍文字，说明它还没有真正退出；下一步应处理该 URL 本身，而不是继续调整文档列表页的提交。

这个动作的结果会直接影响下一步：如果旧产品介绍 URL 返回 404 或 410，且文档列表页在未登录状态下仍返回完整文档，那么提交对象就只剩文档列表页。若旧产品介绍 URL 返回 200，则先处理它，再考虑提交文档列表页。

对照时不要混淆抓取限制与索引移除

有人会用 robots.txt 挡住旧 URL，认为这样就能让它退出。robots.txt 限制的是抓取，不等于可靠的索引移除；已有索引的 URL 仍可能因外部链接或历史信号出现在结果中。若目标是让旧内容退出，更稳妥的动作是让该 URL 返回明确的移除状态，或在确实需要保留页面但撤下内容时，确认页面主体已不再包含旧内容。站点地图也不保证收录，它只是提交候选地址的一种方式，不能替代对页面状态的判断。

同理，HTTPS 不保证安全无漏洞或排名，它只说明传输层加密。对照设备或登录状态差异时，不要因为地址是 HTTPS 就跳过对返回主体的检查。

保留有价值部分时的提交边界

假设文档列表页在未登录和已登录状态下返回的 HTML 主体一致，只有移动端渲染后少了一个侧栏。此时可保留文档列表页，提交对象就是该地址本身。若已登录状态返回的 HTML 主体中混入了账号相关文字，而该文字对未登录访客不可见，则要确认这部分文字是否出现在服务端返回的 HTML 中。若出现，应考虑是否让该地址对未登录访客返回不含账号文字的版本；若无法做到，则不宜把该地址作为公开提交对象，而应把真正公开的文档入口单独列出。

不同搜索引擎对同一地址多版本的处理方式需要分别核查，不能用一个平台的结果推断另一个平台。对照时至少记录：请求时的设备类型、登录状态、返回状态码、HTML 主体中是否包含目标文字、渲染后可见文字是否与主体一致。这些记录能帮你决定是提交原地址、提交另一个公开地址，还是先处理旧 URL 的退出状态。最后一步始终是复核：用未登录、非移动的请求再取一次，确认你打算提交的版本确实包含仍然有价值的部分，并且不再包含已经决定退出的内容。

图1 图2
nginx