Baiduspider抓取：同一地址因设备或登录状态返回不同内容怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3e9f556b7b68.html
📄
Baiduspider抓取：同一地址因设备或登录状态返回不同内容怎样对照
先给结论：不要试图让 Baiduspider 同时看到“设备版”和“登录版”，而要选定一个可公开访问的基准版本，把其余版本当作差异项逐项对照。对照的核心不是看页面好不好看，而是看同一 URL 在无登录、非个性化条件下返回的主体内容是否一致，以及差异是否会影响抓取判断。
假设情境：同一地址出现三种返回
假设一个内容站有一个栏目页 /list。未登录的桌面浏览器看到十条公开条目，未登录的手机浏览器看到同样的十条但排版不同，登录后的浏览器额外看到“我的收藏”和“继续阅读”。现在需要判断 Baiduspider 抓取时应该以哪个版本为准。
这个情境的关键前提是：站点已有真实业务，登录态和移动适配都在运行，且近期准备调整页面模板。变化前，页面主体是公开条目；变化后，如果登录模块被直接塞进主内容区，就可能让不同访问者看到不同的主体结构。此时应先把三种返回分别保存为可复查的证据，再决定模板怎么改。
对照前先固定三个变量
要让对照有意义，必须固定请求身份、请求头和对照时间。建议至少固定以下三项：
- User-Agent：分别记录桌面浏览器、手机浏览器和 Baiduspider 的 UA，不要用同一个 UA 去推断设备差异。
- 登录状态：明确是未登录、已登录，还是带 Cookie 的登录态；登录态页面通常不应作为公开抓取基准。
- 请求时间：同一地址在不同时间可能因缓存、发布或接口返回而变化，对照应尽量在同一时间窗口内完成。
实际操作时，可以用 curl 分别请求同一 URL，并保存响应头和正文片段。动作的结果会直接影响下一步：如果未登录桌面版和 Baiduspider 返回的主体条目一致，说明公开基准可用；如果 Baiduspider 返回的是登录跳转或空壳，就要先修公开访问，而不是继续调模板。
用“主体内容”而不是“整页 HTML”做对照
设备差异和登录差异经常只体现在导航、推荐位和脚本上，正文主体未必不同。对照时，先把页面拆成三层：
- 主体内容层：标题、正文、列表条目、分页链接。这一层应尽量保持稳定。
- 设备适配层：响应式样式、移动端跳转、图片尺寸。这一层允许不同，但不应改变主体语义。
- 登录与个性化层：用户名、收藏、推荐、历史记录。这一层不应成为 Baiduspider 判断页面的必要前提。
如果主体内容层在三种返回中一致，差异只落在适配层，通常不需要为抓取单独做一套页面。如果主体内容层在登录态下才出现，而公开态是空壳，就要考虑把公开态补成可独立理解的内容，或者把登录内容放到需要登录才能访问的独立 URL 上。
差异出现后，按两种条件分别决策
条件一：公开态和 Baiduspider 返回的主体内容一致，登录态只是额外功能。此时应保留公开态作为抓取基准，登录态继续服务真实用户。下一步检查移动适配是否改变了主体链接，如果移动端把公开条目替换成登录入口，就要调整移动端模板。
条件二：公开态返回空壳或跳转，只有登录态才有主体内容。此时不应指望 Baiduspider 抓取登录后的页面。更稳妥的做法是让公开 URL 直接返回可读的主体内容，把登录功能放在交互层或独立路径。若业务上必须登录才能看，则应接受该 URL 不适合作为公开抓取入口，并把它与公开内容区分开。
这里有一个容易误判的点：robots.txt 的抓取限制不等于可靠的索引移除。即使屏蔽了某个路径，已经存在的索引结果也可能保留一段时间，不能把屏蔽当作删除内容的替代方案。站点地图也不保证收录，它只是发现线索之一。
可复查的对照记录应包含什么
为了让下一次模板调整有依据，建议每次对照留下简短记录：
- URL、请求时间、使用的 UA 和登录状态。
- HTTP 状态码、是否发生跳转、跳转目标是否为公开地址。
- 主体内容层是否一致，差异出现在哪一层。
- 下一步动作：修公开访问、修移动模板，还是保持现状。
假设对照后发现 Baiduspider 返回的正文条目与未登录桌面版一致，但手机浏览器返回的条目少了三条。这时不应直接断定抓取有问题，因为差异可能来自移动端模板的条件渲染、缓存，或接口按设备返回了不同数据。下一步应先复测移动端在无登录条件下的返回，再决定是否调整模板。只有把差异定位到具体层，后续改动才不会把公开基准一起改坏。
