同一個 URL，你用浏览器打開是完整的商品頁，搜尋引擎抓到的却可能是一份占了半屏“請先登入”的残缺 HTML。這種“抓到的和看到的不是一回事”的情况，在排查收錄問题时经常被忽略——它會让後面所有關于收錄狀態的判断都建立在错誤前提上。
第一步：先取證，別凭印象判断
先別急着改頁面。用几種不同的請求方式，各取一次同一 URL 的原始 HTML（不是渲染後的截图），把正文部分截出来對比：
- 普通浏览器 UA 請求一次；
- 移動端 UA 請求一次；
- 搜尋引擎 UA 請求一次；
- 带 Cookie 與不带 Cookie 各請求一次。
如果這几份结果正文長度差距明顯，差异就是真實存在的，接下来才轮到找原因。如果几份结果完全一致，那收錄問题應该往別處查，比如頁面质量、内鏈深度或索引狀態本身。
差异通常来自四個地方
1. UA 與设备判定
自适應站点常用 UA 判断跳轉：移動 UA 被跳到 m 子域，桌面 UA 留在主域。如果跳轉靠 JS 或 302 完成，而目标頁又没有獨立可抓取的正文，搜尋引擎拿到的可能就是跳轉前的空壳。要確認的是：主域和 m 域是否各自返回完整正文，以及是否存在桌面與移動互跳的死循环。
2. 地域與 CDN 回源
带地域分發的站点，不同节点可能返回不同货幣、不同库存，甚至對某些地区直接返回屏蔽頁。搜尋引擎的抓取节点未必和你所在地一致，于是“本地正常、抓取異常”就出現了。核對方法是換出口 IP，或者直接對源站請求一次，看源站輸出是否完整。
3. 登入態與會員墙
價格、联系方式、下载地址藏在登入後，是很多站点的預設设計。如果這些内容恰恰是頁面主体，那么對外部抓取者来说這頁就是低價值甚至空頁面。要么把核心内容放到登入前，要么明确這類頁面不必强求收錄。
4. 缓存與渲染时机
頁面缓存可能還停留在舊版本；前端渲染的站点則可能缓存了“還没注入正文”的那一刻。核對时注意請求头里的缓存标识，並對比直接訪問源站與经過 CDN 的结果是否一致。
推荐的核對顺序
- 用不同 UA、不同 Cookie 狀態各取一次原始 HTML，记錄正文長度；
- 绕過 CDN 直连源站取一次，判断差异是否由缓存或节点造成；
- 检查是否存在 JS 或 302 跳轉，跳轉後的目标頁能否獨立返回正文；
- 確認關键内容是否依赖登入態；
- 以上都排除後，再去核對 robots、canonical、索引狀態這些常規項。
两個容易踩的坑
不要為了“让蜘蛛看到更好的版本”而按 UA 给搜尋引擎單獨輸出一份内容。這類做法属于伪装（cloaking），短期或许看不出問题，長期是站点級風險。
- 只對比渲染後的頁面截图，不對比原始 HTML，會漏掉“正文靠 JS 注入”這一類問题；
- 發現差异後同时改了缓存、跳轉和模板，结果無法判断是哪一項起了作用，建议一次只改一處。
把结论记下来
建议做一張简單對照表：URL、請求方式、返回狀態碼、正文長度、是否有跳轉。同一批頁面跑一遍，規律很快就會顯現。抓取與收錄本来就是两步——先保證抓到的版本是完整的，再去谈它有没有進入索引、以什么形式展示，顺序颠倒了只會白忙一场。