移動優先索引已经不是新话题，但不少站点仍在跑两套代碼：一套给桌面浏览器，一套给手机。問题在于，搜尋引擎抓取現在主要使用移動端 UA。如果移動版本里的内容比桌面版少，或者要用戶点一下切換到完整版才看得到正文，那么蜘蛛拿到的就是那個精简版本。

先搞清楚蜘蛛拿到的是哪個版本

• UA 判断跳轉：按 User-Agent 把移動端請求 302 到 M 站，這是常见做法，但跳轉层數不宜太多，也不建议用 JS 跳轉。
• 响應式：同一個 URL 一套 HTML，只用 CSS 控制布局，维護成本最低，两套内容天然同步。
• 獨立域名並存：m.example.com 與 www 同时存在时，要確認两邊互相标注 alternate 與 canonical，並且内容對得上。

這三種做法没有绝對優劣，關键是你得知道目前站点属于哪一種，以及蜘蛛實际落在了哪個 URL 上。

内容一致性：別让移動端少一半

把桌面版和移動版的同一個地址並排打開，逐項比對下面這些内容：

• 正文文字與标题层級，移動版是否把長段落截断成展開阅讀全文。
• TDK、canonical、结构化資料是否两邊都完整。
• 图片 alt、表格、列表、内鏈是否被删掉。
• 分頁、篩選、參數表、评论等模块是否在移動版被整块隐藏。

如果确實因為屏幕尺寸做了取舍，至少保證主体内容、主要内鏈和结构化資料不要丢。這几样丢了，同一個 URL 在两套版本里就相当于两份不同的頁面。

隐藏内容要分清藏和删

折叠面板、Tab 切換、点击加载更多這類交互，在多數情况下内容仍然寫在 HTML 里，可以被抓取到，不必過度紧張。真正要避免的是：關键信息只有点击之後才通過接口异步拉取，而初始 HTML 里什么都没有。判断方法很简單，把頁面源碼抓下来，禁用 JS 再看一遍正文還在不在。

另外要注意，同一段文字不要在两套版本里给出不同的表述。比如移動版為了简短把價格、規格改寫成另一句话，两邊對不上，容易让頁面之間的關系變得模糊。

移動端体驗也會影响抓取表現

• 首屏插屏广告、全屏彈窗盖住内容，用戶要等几秒才能關掉。
• viewport 没設定或寫死宽度，頁面在手机上被缩小成细長一條。
• 正文字号偏小、行高拥挤，点击区域不足。
• 移動端图片没做尺寸适配，一張原图好几 MB，首屏加载很慢。

這些不直接决定是否被索引，但會影响打開速度和用戶停留，進而影响抓取资源的分配和頁面的整体表現。

一次可执行的自查流程

1. 從服務器日誌里筛出移動端蜘蛛的 UA，看它抓的是哪套 URL、有没有發生 302 跳轉。
2. 用移動 UA 訪問 10 到 20 個代表性頁面，把返回的 HTML 存下来。
3. 禁用 JS 再打開一次，對比正文、内鏈、结构化資料的差异。
4. 把差异列成清單，按栏目分派给對應负责人處理。
5. 改完之後隔两三周再看一次日誌，確認跳轉和落点稳定下来。

几個常见誤区

• 只测首頁。首頁通常维護得最好，栏目頁和詳情頁才是重灾区。
• 以為用了响應式就萬事大吉。响應式也可能用 CSS 把某些模块在窄屏下直接 display:none。
• 用 JS 做 UA 跳轉。蜘蛛不一定执行這段脚本，容易出現两邊都抓不到完整内容的情况。
• M 站的 canonical 指向自己。两套内容等價时，應该有一個明确的主版本。

同一份内容，最好只對應一個正式地址。多一套版本，就多一份需要同步维護的成本。

這件事不需要一次性全站推平，先從流量占比高的栏目開始，把两套版本對齐，再逐步扩展到其余頁面，比大改版要稳妥得多。