两套地址，两個索引入口
有些站点把移動端和 PC 端拆成两個域名，例如 m.example.com 和 www.example.com。從搜尋引擎的角度看，這是两條獨立可抓取的 URL，各自都能被抓取，也各自可能進入索引。所以当你核對“這個頁面收錄了吗”，先要回答的是：是哪一端被收錄，另一端現在是什么狀態。只说“收錄了”或“没收錄”，往往會掩盖真正的問题。
三種常见部署方式
响應式或動態适配
同一個 URL 返回适配不同设备的同一份内容，收錄只有一條地址，维護成本最低，也最不容易出現两端不一致的情况。
獨立移動站加适配声明
两端各自返回頁面，需要在 PC 頁與移動頁之間互相标注對應關系。两端都允许抓取，索引通常會收敛到其中一端，但收敛過程需要時間，中間狀態可能是两端都在索引里。
移動端被整体屏蔽
如果 robots.txt 或 noindex 把移動端全部挡住，移動端不會進索引，PC 端仍可能被收錄。移動用戶点進来看到的頁面，與索引里那一版的体驗並不一致，這是一類容易被忽略的错配。
核對收錄时的顺序
- 先用 URL 检查工具分別查 PC 端和移動端的地址，看各自處于什么狀態。
- 確認两端的适配声明是否成對、是否指向真實存在的地址。
- 检查移動端能否正常抓取：狀態碼、robots 規則、跳轉鏈是否過長。
- 最後再確認索引里實际留下的是哪一條，以及另一條是否還在索引中。
几個容易踩的坑
- 只在一端寫适配声明，另一端漏掉，形成單向關系。
- 移動端用脚本跳到 PC 端，PC 端又跳回移動端，形成循环。
- 移動頁面内容明顯少于 PC 端，正文缺失大半。
- 用临时跳轉把移動端全量指向 PC 端，却没有声明适配，两套 URL 频繁進出于索引。
适配声明是给搜尋引擎的參考，不是强制指令。它帮助系統判断两套地址是不是同一份内容，但最终選擇哪一條，還取决于两端的内容、可抓取性和連結指向。
如果只想保留一套地址
最省事的做法是不拆站，让同一 URL 适配所有设备。如果出于歷史原因必须拆，至少保證两端都能抓取、正文内容基本一致、互相声明對應關系，並让跳轉保持單向、可预期。不要一邊屏蔽移動端，一邊期待移動端有正常的搜尋表現。
自查清單
- 两端是否都返回正常狀態碼，而不是一端 200、另一端 404 或 302。
- 适配声明是否成對出現，且指向目前真實存在的地址。
- 移動端正文是否與 PC 端大体一致，而不是只剩标题和導航。
- robots.txt 是否意外挡住了其中某一端。
- 两端的自指声明是否自相冲突，導致系統無法判断主版本。
把两端当成一组来處理，收錄核對时的很多“莫名其妙”就會變成有迹可循的排查步骤。