收錄對不上时，大多數人的第一反應是去查内容质量、重复内容和 URL 規范。這些当然要查，但在此之前有一個更容易被跳過的前提：搜尋引擎主要是用移動端 UA 抓取並评估頁面的。你平时用桌面浏览器打開看到的那個完整版本，未必就是索引里儲存的版本。
所以，核對收錄的顺序應该往前挪一步：先確認蜘蛛拿到的移動端 HTML 和你以為的頁面是不是同一個東西，再去讨论质量、重复和規范化。
一、先用两個 UA 各抓一次
最简單的動作是：拿移動端 UA 抓一次頁面，再拿桌面 UA 抓一次，把两份 HTML 放在一起對比。重点看正文主体、主要導航連結、canonical 标簽和指向的资源文件。
响應式站点两份代碼通常一致，基本能過這一關。真正容易出問题的是獨立移動域名和動態服務這两種方式——移動端返回的 HTML 里正文被砍掉大半，只剩标题、一張图和一句“請在桌面端查看”，而索引里儲存的恰恰就是這一份。
二、三種建站方式各自的核對点
响應式：同一套代碼
- 確認 viewport 設定正常，頁面没有因為宽度判断而隐藏主体内容。
- 確認 CSS、JS 没有被 robots.txt 屏蔽，否則渲染结果會與浏览器不同。
- 用折叠、Tab、轮播藏起来的正文，仍然要保證它在 HTML 源碼里存在。
獨立移動域名：如 m 開头的子域
- 桌面頁要指向移動頁的 alternate，移動頁要指向桌面頁的 alternate，两邊成對出現。
- 移動頁自身的 canonical 應指向自己，不要反過来指向桌面頁，那會让两套頁面互相打架。
- 移動域名如果被 robots.txt 整段屏蔽，桌面頁上的 alternate 就失去了意义，蜘蛛根本進不去。
動態服務：同一 URL 返回不同 HTML
- 這種模式下 canonical 保持自引用即可，不需要額外的 alternate。
- 要注意別让移動端返回的内容明顯少于桌面端，否則索引里就是那個缩水版本。
- 留意 Vary 头與缓存配置，避免把移動端结果错誤地返回给桌面端蜘蛛。
三、三處最容易出問题的差异
正文與主要連結。移動端為了加载速度，常把评论、參數表、部分段落直接不輸出，而不是用 CSS 隐藏。這两者的区別很大：CSS 隐藏的内容還在 HTML 里，直接不輸出的内容對蜘蛛等于不存在。列表頁和栏目頁同理，移動端少輸出了几個入口連結，就等于少了几條爬取路径。
canonical 與 alternate 的成對關系。獨立移動站最容易犯的错是两邊都寫自引用，或者只有一邊寫了 alternate。核對时把两個版本的 head 区域並排看一遍，確認指向關系是閉合的、不是單向的。
可抓取资源。被屏蔽的 CSS 會让渲染後的頁面结构變形，被屏蔽的图片和脚本則可能让蜘蛛判断頁面内容不完整。移動端尤其常见把静態资源放在單獨的 CDN 子域上，却忘了给這個子域放行。
四、一套可执行的核對顺序
- 用移動端 UA 抓取目标 URL，儲存 HTML。
- 用桌面端 UA 抓取同一 URL，儲存 HTML。
- 對比两份源碼中正文文本的長度與主要連結數量。
- 對比两份的 canonical 與 alternate，確認關系閉合。
- 检查 robots.txt 是否放行了 CSS、JS、图片所在路径。
- 確認移動端返回的狀態碼正常，没有把移動 UA 導向登入頁或驗證頁。
- 以上都對齐後，再回到内容质量、重复與 URL 規范层面繼續排查。
移動優先索引不是“只抓移動端”，而是“以移動端版本作為判断依據”。桌面端仍然會被抓取，只是当两個版本不一致时，索引更倾向于采用移動端看到的内容。
五、两個常见誤区
一是以為做了响應式就萬事大吉。响應式只解决了代碼统一的問题，不解决内容輸出被條件判断砍掉、资源被屏蔽的問题，這些仍然要單獨核對。
二是把移動端的加载優化做成内容删减。為了速度刪除正文段落、折叠全部评论、精简列表入口，短期看是加载變快了，長期看是索引里的頁面變薄了。可以優化传輸方式，但正文和入口最好保持完整輸出。