先把“對不上”的具体表現说清楚

移動端收錄和 PC 端不一致，常见的有几種：PC 頁面早就進了索引，移動端 URL 一直没動静；两邊都被收錄，但移動端展示的标题、摘要和 PC 差很多；移動端頁面進過索引又消失；以及 m 域名下冒出一批本不该收錄的參數頁。這几種表現背後的原因並不相同，先分清表現，再决定從哪里查。

第一步：確認自己用的是哪種适配方式

适配方式不同，出問题的位置完全不同。

• 响應式（同一套 URL）：理论上只有一份 URL，出現差异多半是渲染或展現层面的問题，而不是两份 URL 争收錄。
• 獨立移動站（m 域名）：存在两套 URL，差异通常来自跳轉、标簽和 sitemap 的配置。
• 動態服務（同一 URL 返回不同 HTML）：取决于识別 User-Agent 是否稳定，容易出現该返回移動版时却返回了 PC 版。

先确定自己属于哪一類，後面的排查才有方向。

响應式站点：重点查渲染與资源屏蔽

响應式站点如果出現移動端表現異常，多數不是“收錄問题”，而是移動端抓取时頁面没被完整渲染。

• robots.txt 是否屏蔽了 CSS、JS 或图片目錄，導致移動端抓取时拿到的是一張“裸 HTML”。
• 正文是否依赖懒加载或滚動触發，首屏 HTML 里其實是空的。
• 是否存在彈窗、浮层、引導下载 App 的遮罩，把主要内容挡在後面。
• viewport 和字体、宽度設定是否让渲染出的内容大量缺失。

這類站点只需要一份 URL，如果 PC 收錄正常而移動端展現異常，優先怀疑渲染，而不是去改收錄相關的配置。

獨立 m 域名：重点查跳轉與标簽

• 移動端抓取时是否被 302 跳到 PC 頁，或反過来形成循环跳轉，最後落在一個非预期的 URL 上。
• m 頁面是否誤加了 noindex，尤其是模板繼承、條件判断寫错的时候。
• canonical 指向是否自洽：是指向 PC 頁，還是自指，還是两種寫法在不同模板里混用。
• 是否有獨立的移動 sitemap，且里面只放移動 URL；PC sitemap 里是否混進了 m 連結。
• 两套 URL 的内鏈是否各自閉环，還是 PC 頁面全部鏈向 PC，移動頁面成了孤岛。

這几項里任何一項出错，都可能让其中一端長期拿不到正常的發現路径。

内容與内鏈的差异往往被忽略

移動端為了阅讀体驗常做裁剪：正文只保留前半段、參數表格折叠起来、评论区去掉、相關推荐換一套。改動幅度小没問题，如果裁得太多，移動端頁面在内容完整度上會明顯弱于 PC 端，被抓取後自然不占優势。

内鏈同理。不少站点移動端導航是 JS 渲染的，或者干脆省略了面包屑和分類入口，结果移動端 URL 的入鏈數量遠少于 PC 端，URL 被發現的速度也就慢了一截。

建议的排查顺序

1. 用移動端 User-Agent 抓一次頁面，確認返回的是移動版還是 PC 版。
2. 看首屏 HTML 里有没有正文，還是必须等 JS 执行完才出現。
3. 检查 robots meta、canonical 等标簽在两邊是否成對、是否自洽。
4. 核對 sitemap，移動 URL 是否在里面，PC sitemap 里是否混了移動 URL。
5. 統計移動端頁面的内鏈入口數量，看是否只藏在某個按钮或提交動作之後。
6. 對比两邊内容差异，判断是轻微裁剪還是整体替換。
7. 最後再看收錄與展現狀態，区分是没被抓、抓了没渲染，還是渲染了但内容判低。

移動端收錄慢或缺失，多數时候不是引擎“更偏向 PC 端”，而是移動端在可抓取性、可渲染性和内容完整度上先輸了一步。

處理原則：先补齐，再谈收敛

确定問题落在哪一层之後再動手：抓取不到就修跳轉和屏蔽規則，渲染不出来就改加载方式，内容被裁得太狠就恢复主体信息，内鏈缺失就补入口。不要一上来就给整個 m 目錄加 noindex，那只是把可见的問题藏起来，移動端的流量入口也會一起丢。