不少站長對站点的理解還停留在“有两套頁面”：PC 端一套、移動端一套，蜘蛛各抓各的、各收錄各的。實际情况是，搜尋引擎早已把移動端頁面当作主要的抓取與索引對象，PC 端版本更像是一個對照视图。两端内容不一致时，進入索引的很可能是移動端那句话、那張图、那個标题。
移動優先索引，優先在哪里
所谓移動優先索引，是指搜尋引擎在抓取、渲染、判断頁面内容时，主要采用移動端代理（通常是智能手机的 UA）看到的版本。這個版本會作為主文档進入索引，用来理解頁面主题、抽取标题與正文、识別图片、讀取结构化資料、發現内鏈。PC 端版本仍會被抓取，但更多是作為參考，而不是索引内容的主要来源。
因此，那種“PC 端首頁寫得很全，移動端首頁只放了一個横幅和几行字”的做法，最终留在索引里的往往是那個很空的版本。頁面主题没變，但可用的内容信号少了一大截。
两端不一致时，先看這几處
- 正文：移動端折叠、隐藏、懒加载後没有渲染出来的段落，PC 端有，索引里没有。
- 标题與描述：两端 title、h1 不一致时，移動端那份更容易被采用。
- 内鏈：移動端導航收進汉堡菜單，或由 JS 動態插入，蜘蛛能顺着走的連結會明顯减少。
- 图片與替代文本：移動端用背景图替換掉 img，alt 信息随之丢失。
- 结构化資料：只寫在 PC 模板里，移動端模板没有輸出。
- 指令與限制：移動端模板誤带 noindex，或 robots.txt 里针對移動 UA 有額外限制。
這些問题單看都不致命，叠在一起就會出現“PC 端看着正常、搜尋里的展示却残缺”的情况，而排查时又容易只盯着 PC 端頁面，方向就跑偏了。
獨立移動站：两套 URL，別把關系搞乱
如果使用 m.example.com 這類獨立移動站，两套 URL 的對應關系必须清楚：每一對頁面之間要能互相發現，canonical 指向要保持一致，不能出現 A 指向 B、B 又對蜘蛛说不要收錄這種自相矛盾的组合。早年的常见做法是移動端 canonical 指向 PC 端，現在更普遍的是移動端自指；两種方案本身都可以，前提是同一站点内選一種並贯彻到底。
另一種常见失誤是改版、換域名时只處理了 PC 端的跳轉和标注，移動端還停在舊 URL 上。蜘蛛在移動端抓到的是一份“没人管”的頁面，收錄自然混乱。
响應式站点也不能掉以轻心
响應式布局不等于自動安全。如果内容是通過 JS 按屏幕宽度判断後注入的，移動端很可能拿不到；如果把大段正文用 display:none 藏起来，内容质量评估也會受影响。更常见的是為了移動端速度做“精简版”，把正文砍掉一半、把參數表整段刪除——這是最不划算的一種優化。
一份可以照着做的移動端自查清單
- 用手机 UA 抓取一次 HTML，與 PC 版逐項對比正文、标题、图片、结构化資料。
- 在關閉 JS 的狀態下再看一次，確認核心内容不依赖脚本才出現。
- 核對移動端模板輸出的 meta robots，確認没有被全局誤伤。
- 检查移動端導航里的連結是否為可抓取的 a 标簽，數量是否與 PC 端接近。
- 確認 canonical 與备用标注在两端互相吻合，没有互相打架。
- 用站点工具查看頁面时，注意抓取的到底是哪個版本，別只看 PC 端的渲染结果。
- 選取几個重点栏目頁，人工在手机上打開，看看正文、图文、參數是否完整。
發現問题之後
處理顺序上，優先改模板而不是逐頁修补：移動端缺内容就补齐渲染逻辑，導航恢复成真實連結，canonical 關系統一，確認移動端没有意外的 noindex。改完之後不必反复提交，等蜘蛛按自己的节奏回訪即可。真正要盯的是“下一個新頁面發布时，同样的問题會不會再出現”。
收錄的前提是蜘蛛能看到；在移動優先的语境下，這句话更准确的说法是——蜘蛛在手机上能看到什么，才决定索引里留下什么。