為什么移動端和 PC 端要分開核對
很多站点在核對收錄时，习惯把注意力放在“這個 URL 有没有進索引”上，却忽略了同一個頁面在移動端和 PC 端可能對應两個不同的地址。如果两套地址都被当成獨立頁面收進去，同一份内容就會在索引里出現两遍，既稀释了權重预期，也让後續的收錄統計變得难以解释。
更麻烦的是，這類重复往往不會报错：頁面狀態碼都是 200，内容也都能正常打開，只能通過在索引和日誌里比對地址才能發現。
先確認站点用的是哪種适配方式
自适應（响應式）
一套 URL，靠 CSS 和视口适配不同终端。這種最省事，正常情况下一個地址就是一條记錄，核對时只需抽查少量頁面，確認移動端渲染是否正常。
獨立移動站
常见寫法是 m.example.com 或者 example.com/m/，PC 與移動各有一套完整 URL。這时必须明确哪一套是“主”，並通過 canonical、alternate 之類的标注把两套地址指向同一個實体。核對时要特別留意标注是否双向、有没有寫错域名或路径。
同一 URL 動態适配
地址不變，服務端按 User-Agent 返回不同版本。這種情况下索引里通常只有一條地址，但要確認移動端返回的 HTML 不是空壳，也不是只有一段跳轉脚本。
核對时具体查這几項
- 索引里的地址：按域名分组，看移動站域名或 /m/ 路径下的 URL 占了多少。如果占比異常高，說明很可能被当成獨立頁面收了。
- 标注關系：抽查若干頁面，確認 canonical 指向的是同一套地址，而不是 PC 頁指向自己、移動頁也指向自己。
- 日誌里的抓取：分別看移動 UA 和普通 UA 抓的地址是否一致，有没有出現两套地址都被反复抓取。
- sitemap 提交内容：確認提交的是主地址，還是把两套地址都列了進去。
- 移動端可訪問性：確認移動站没有被 robots.txt 拦掉，也没有出現未登入就 302 回 PC 首頁的情况。
三種常见情况怎么處理
两套都被收錄且内容一致
先定主地址，把另一套通過 canonical 或 301 归並過去，然後观察索引的替換過程。不建议在同一時間既改标注又改 URL 结构，否則很难判断是哪一步起了作用。
只收了 PC 没收移動
多數情况下這不是問题，反而是正常结果。只要主地址進了索引、移動端能正常打開，就不必為了“两邊都要收”額外做工作。
移動端頁面内容明顯更少
如果移動版砍掉了正文，只留标题和引導语，即使地址被收錄，也很难撑住這個位置。核對时把移動端渲染後的正文長度和 PC 端對比一遍，差距過大就先补内容，而不是先纠结收錄數量。
抓取正常、狀態碼正常，都不代表两套地址被正确合並。移動适配的問题通常只在索引层面暴露，所以核對要落到索引里的實际地址上。
一個可执行的顺序
- 列出站内所有可能产生多套地址的入口：移動域名、/m/ 路径、带设备參數的跳轉連結。
- 抽样 20 到 30 個頁面，记錄索引中存在的地址、canonical 指向、移動端正文長度。
- 按模板归類，看重复是集中在某几個栏目，還是全站普遍存在。
- 确定主地址後，分批修改标注或做跳轉，改完留出观察周期再統計。