先给结论:不要试图把“所有设备、所有登录状态”下的页面都抓下来求一个统一版本,这既做不到,也不必要。正确做法是先判断差异属于哪一类——是缓存/CDN 导致的同一份 HTML 分发不一致,还是服务端按 UA、Cookie、登录态做了内容分流。前者应当保留并修复分发配置,后者应当改写为对百度可稳定返回同一主内容,只有在无法改写、又确实需要被收录时,才考虑退出这套分流逻辑。判断依据不是“我看到了不同内容”,而是同一 URL 在不同请求条件下返回的 HTML 主体、状态码和关键文本是否出现了实质分歧。
这两类现象看起来都是“同一地址内容不同”,但处理方向完全相反,必须先区分。
分发不一致的特征是:服务端逻辑其实只有一份输出,但中间层(CDN 缓存、反向代理、多机房、AB 机器)让不同请求拿到不同副本。典型证据是同一请求头重复请求多次,返回内容在短时间内跳变;或者带某个特定 Cookie 才命中旧版本。这类问题保留原页面结构即可,动作是清理缓存键、统一回源。
服务端分流的特征是:内容差异由代码主动决定,比如未登录返回一段引导文案、登录后返回完整正文;或移动 UA 返回精简版、桌面 UA 返回完整版。这类差异是设计出来的,不会因为清缓存而消失。是否要改写,取决于百度抓取时默认落在哪一支上。
一个可执行的区分动作:用同一 URL 发起两次请求,只改一个变量(要么只改 UA,要么只改 Cookie,要么都不改只改时间),观察 HTML 主体是否变化。如果只改时间就变,偏向分发问题;如果必须改 UA 或 Cookie 才变,偏向服务端分流。这个结果直接决定你下一步是去查缓存配置,还是去查模板逻辑。
没有日志、没有 CDN 后台、没有服务端权限时,仍然可以做一组可复查的对照,不必等权限齐全。
这里要明确一个限制:你手动构造的请求,和百度实际抓取时使用的 UA、IP、Cookie 策略不一定相同。所以你观察到的差异只能证明“该地址存在按条件返回不同内容的能力”,不能直接推出百度抓到的是哪一支。把这一点写进你的记录里,避免后续把假设当成结论。
如果连手动构造请求的工具都没有,退一步的最小动作是:用浏览器无痕窗口(无登录态)和已登录窗口分别打开同一地址,对比正文区域。这只能作为线索,因为浏览器渲染会掩盖源码差异,也无法排除本地缓存干扰。
三种选择不是并列的优劣,而是对应不同的差异性质。
保留适用于:差异只发生在登录态之后,未登录状态下返回的就是完整主内容。此时分流不影响百度看到的内容,不需要为收录做任何改动。前提是你确认过未登录分支包含正文,而不是只有一句“请登录查看”。
改写适用于:分流由 UA 或轻量 Cookie 触发,且你希望同一 URL 对百度稳定输出同一主内容。常见做法是让百度 UA 或未登录状态直接命中完整版,把个性化部分放到客户端异步加载。前提是这套改写不会破坏真实用户的体验,且你能验证改写后未登录分支仍然完整。改写后要重新做一次上面的对照,确认三组请求的正文文本已经一致,再决定是否需要提交新的站点地图——注意站点地图只是提示,不保证收录。
退出适用于:差异无法消除,且这套分流对业务是刚需,比如强登录墙。此时更现实的选择是让需要被收录的内容单独存在于一个稳定的公开地址上,而不是继续指望这个会分流的 URL 被正常收录。退出不等于用 robots.txt 屏蔽——robots.txt 的抓取限制不等于可靠的索引移除,已收录的 URL 仍可能以其他形式出现。若确实要移除,应使用对应的移除机制而非仅靠 robots.txt。
假设某地址在桌面 UA 下返回含正文的 HTML,在移动 UA 下返回“请在客户端打开”的短页。你做了三组对照,发现只有移动 UA 分支缺正文,桌面分支和未登录桌面分支一致。基于这个结果:
这个例子里的数字和分支都是假设,用于说明比较方法,不代表任何真实站点的表现。关键是把“观察到差异”转成“差异属于哪类、百度可能落在哪支、哪支可以改”这三个判断,而不是停在“内容不一样”这个层面。
即使你完成了对照,也有几件事不能仅凭它下判断。请求量或抓取量下降,不能单独证明是这次内容差异导致的,缓存、外链变化、站点结构调整都可能是合理解释。某次抓取返回了空壳页,也不能直接断定百度收录的就是空壳版本。HTTPS 与内容一致性无关,它既不保证安全无漏洞,也不保证排名。把这些边界写清楚,后续的修复试验才有可复查的基准,而不是在错误前提上继续叠加动作。