移動優先索引推行之後，搜尋引擎的蜘蛛在抓取和评估一個站点时，越来越常以移動端 UA 的身份訪問。也就是说，你在电脑上看到的那個排版整齐、内鏈完整的頁面，未必是蜘蛛實际讀到的那一份。很多站点的問题並不出在内容本身，而是移動版少了一块——導航被折進汉堡菜單、正文被塞進标簽頁、内鏈只剩几個图标按钮。
一、先弄清蜘蛛拿到的移動版是什么样
不要凭手机截图判断，截图看到的是渲染後的结果，而抓取的第一步往往是原始 HTML。更可靠的做法是主動复現蜘蛛的视角：
- 用移動端 User-Agent 請求几個代表性 URL，直接查看返回的 HTML 源碼，確認正文、标题、主要連結是否都在里面。
- 再用渲染工具或抓取诊断類功能跑一遍，看渲染後還有没有内容被脚本补進来。
- 样本不要只挑首頁，栏目頁、詳情頁、列表第二頁各取一两個，問题往往藏在模板分支里。
這一步做完，你通常會得到两個版本的對比：桌面版和移動版。接下来要判断的是，差异到底是正常的响應式收缩，還是内容真的少了。
二、移動端最常见的几類問题
1. 正文或内鏈被藏起来
為了移動端好看，有些模板會把次要内容預設折叠，或者用display:none隐藏掉整块区域。如果被隐藏的恰好是正文後半段、相關阅讀、栏目入口，那移動版頁面對蜘蛛来说就是一份残缺文档。判断标准很简單：這段内容對用戶有價值，就不该在移動版里消失；如果它對用戶没價值，桌面版也没必要留着。
2. 獨立移動站與主站脱节
使用獨立 m 域名的站点，容易出現几類割裂：移動站缺少桌面站的 canonical 指向、两邊互相声明 canonical 形成循环、移動站的内鏈只在本域名内打轉。這些都會让蜘蛛在两套 URL 之間来回判断，浪費抓取額度，也让權重分散。現在更推荐的做法是响應式同一套 URL，如果歷史原因必须保留獨立移動站，就要保證两邊的一對一映射關系准确。
3. 移動版本身太重
移動端首屏加载慢，直接影响蜘蛛能拿到多少内容。常见原因是未压缩的大图、首屏就加载的第三方脚本、過多的字体文件。蜘蛛不會無限等待，抓取超时或渲染不完整，頁面就可能只被抓到一半。先把首屏必要的资源压到最小，其余部分延迟加载，收益通常比換模板更直接。
4. 交互遮挡了内容
彈窗、浮层、强制下载提示、插屏广告，如果覆盖面积過大，用戶和蜘蛛都可能拿不到真正的正文。移動端尤其容易踩這個坑，因為屏幕本身就小，一個全屏浮层就等于整頁不可讀。
三、按這個顺序做自查
- 列出站点的主要頁面模板：首頁、栏目頁、詳情頁、列表頁、搜尋结果頁。
- 每個模板挑两到三個 URL，分別用桌面 UA 和移動 UA 抓取源碼，逐項對比正文、标题、主要内鏈數量。
- 打開渲染後的版本，確認懒加载、标簽頁、折叠块里的内容能被正常展開。
- 检查移動版與桌面版之間的 canonical、hreflang 等指向是否一致、是否形成循环。
- 用移動網絡或限速模拟环境跑一次首屏加载，记錄關键资源的体积。
- 把發現的問题按影响面排序，先修涉及主要模板、影响正文抓取的項，再處理体驗類细节。
四、改完之後怎么驗證
調整上线後不要只看首頁。重新用移動 UA 抓取同一批 URL，對比修改前後的源碼差异，確認正文和内鏈确實出現在 HTML 里，而不是靠脚本在客戶端补出来。同时观察一段時間的抓取日誌，看移動 UA 的訪問是否更稳定、是否還大量停留在少數几個頁面上。
移動端自查的目标不是让移動版和桌面版長得一模一样，而是保證两者承载的信息量一致。展示形式可以不同，能被讀到的内容不该少。
這類自查不需要一次做完，把它並進日常的模板改動流程里更實际：任何一次模板調整之後，都用移動 UA 复查一遍主要模板，比等到流量下滑再回头排查省事得多。