搜尋引擎的抓取與索引主体已经轉向移動端 UA。這意味着同一個入口頁，桌面端看起来正常，不代表移動端被抓取时也正常。很多「蜘蛛来過但没被收錄」的情况，問题其實出在移動端返回的内容、跳轉方式或者渲染结果上，而不是入口頁本身不存在。
移動優先索引下的三個基本事實
在讨论具体配置之前，先把這三件事记住，後面所有核對都围绕它們展開。
- 抓取用的 UA 是移動端。如果入口頁對不同 UA 返回不同 HTML，那么真正被看到的是移動端那一份。日誌里区分移動與桌面 UA，是判断入口頁對谁友好的第一步。
- 索引以移動端内容為准。移動端少了标题、正文或主要連結，桌面端补不回来。入口頁如果為了移動端做了大幅精简，被精简掉的部分基本等于不存在。
- 渲染有超时。移動端網絡环境更差，资源体积過大时，渲染可能在中途被放弃，最终只看到一個空壳頁面。
响應式還是獨立移動站
两種做法都能用，但维護成本差別很大。响應式只需要维護一個 URL、一套日誌、一張證书，抓取鏈路最短，出現問题的环节也最少。
獨立移動站通常意味着多一個 m 域名：多一套解析與證书、多一份缓存策略、日誌被拆成两處，還要額外维護移動版與桌面版的對應關系。入口頁數量一多，這套對應關系很容易失效，最後變成两邊内容不一致。
如果确實用了獨立移動站
- 移動版與桌面版需要互相标注對應關系，不能只靠 UA 判断跳轉。
- 两邊的标题、正文主体和主要連結應保持一致，不要把關键内容只放在一端。
- m 域名本身也要能被直接抓取，而不是必须经過一次跳轉才能看到内容。
- 两邊的狀態碼策略保持一致，避免一邊 200、一邊 302 或 404。
移動端最容易出問题的几個细节
viewport 與首屏内容
缺少 viewport 声明时，頁面可能按桌面宽度渲染，移動端首屏往往只剩導航栏或大片空白。抓取拿到的正文位置要么在很靠後，要么根本不完整。核對时重点看：首屏能否看到入口頁的核心連結與一段可讀文字。
自動跳轉與彈窗
打開頁面就唤起 App、全屏遮罩、倒計时跳轉，都會让抓取在拿到内容前就被带走。入口頁上尤其不要做這類操作，因為入口頁的價值就在于把連結稳定地暴露出来。
资源体积與加载顺序
阻塞首屏的 CSS/JS、未压缩的大图、自定义字体、多個統計脚本，都會拉長移動端的渲染時間。比較稳妥的做法是让正文和連結先出現在 HTML 里，脚本尽量延後加载，图片做好尺寸與压缩。
折叠與隐藏内容
移動端為了节省空間，经常把出鏈放進折叠区或标簽頁里，用 display:none 隐藏。隐藏内容被赋予的權重通常低于可见内容，重要連結不要只放在折叠区。
怎么驗證移動端表現
- 用移動端 UA 抓取入口頁，和桌面端返回的 HTML 做逐項比對，重点看标题、正文和連結數量。
- 检查渲染後的结果，確認正文、标题、主要出鏈确實存在，而不是只拿到框架。
- 翻訪問日誌，看移動 UA 的占比、狀態碼分布，以及是否出現大量 5xx 或超时。
- 確認内容不是靠 UA 判断或跳轉才出現，避免改動 UA 就拿到另一份頁面。
- 抽查几次抓取間隔，確認响應時間在合理范围内，没有明顯的延迟尖峰。
落地建议
- 優先選响應式，入口頁越简單越不容易出错。
- 入口頁不做 App 唤起、不做全屏彈窗、不做倒計时跳轉。
- 移動端與桌面端返回同一份 HTML，差异只放在样式层。
- 把移動 UA 的抓取情况纳入日常巡检，而不是只盯桌面端日誌。
- 頁面改動後，重新用移動 UA 抽查一遍鏈路，確認没有引入新的阻塞。
移動端适配解决的是「抓取鏈路能不能走通」，它不保證 URL 一定被發現或收錄。把它当成入口頁的基础卫生，而不是效果手段，预期會更接近實际。