同一份内容，PC 和移動端各有一套 URL，两套都出現在搜尋结果里，這在獨立移動站上很常见。它不算嚴重错誤，但會让索引里的頁面數虚高，權重被拆到两個地址上，用戶也可能落到体驗不對的版本。處理之前先分清站点用的是哪種适配方式，否則容易改出新的冲突。
先確認站点用的是哪種适配方式
不同适配方式，出問题的位置完全不同：
- 响應式：只有一個 URL，PC 和移動端共用。如果這種站点也出現两套 URL，多半来自參數、追踪連結或歷史版本，和移動适配本身無關。
- 動態服務：同一 URL 按 User-Agent 返回不同 HTML。重点看 Vary 头和缓存是否按 UA 区分。
- 獨立移動站：m.example.com 或 example.com/m/ 單獨一套地址。两套 URL 同时被收錄主要出現在這一類。
獨立移動站的标注關系要成對
移動站和 PC 站之間需要互相声明關系，只寫一邊往往不够：
- PC 頁的 head 里加一條 rel=“alternate”，media 属性寫成 only screen and (max-width: 640px)，指向對應的移動頁 URL。
- 移動頁的 head 里加 rel=“canonical”，指向對應的 PC 頁 URL。這是官方文档里對獨立移動站的推荐做法，目的是把两套地址归並到同一個規范版本上。
- 两條标注必须一一對應、双向可驗證。只寫移動頁的 canonical，不寫 PC 頁的 alternate，容易被当成單向声明處理。
- 移動頁不要加 noindex。屏蔽移動頁會连带影响移動端的展示，也切断了移動頁與 PC 頁的标注通道。
重定向、Vary 與缓存里容易混的地方
- 移動 UA 重定向：如果 PC URL 對移動 UA 做跳轉，用 302，不要用 301。301 會让搜尋引擎把 PC URL 也理解成指向移動版本的永久跳轉，PC 版本可能從索引里消失。
- Vary 头：動態服務模式下應正确設定 Vary: User-Agent，否則 CDN 或反代可能把移動版 HTML 缓存後返回给 PC 用戶，頁面内容和标注關系都會跟着错乱。
- sitemap：只提交 PC URL 是可以的；如果两套都提交，前提是标注關系已经寫全。sitemap 里同时放两套却没有對應声明，等于主動增加两套都被抓取的概率。
- 站内連結：移動頁尽量互鏈在移動站内部，PC 頁互鏈在 PC 站内部。两套地址大量交叉互鏈，會放大“两個版本都是入口頁”的信号。
内容一致性也要顺手看一眼
移動頁正文比 PC 頁少一大截、去掉了關键内容或结构化資料，是另一個常见诱因。搜尋引擎可能判断两者不是同一内容的两個版本，标注就失去作用。可以核對的点包括：标题與主标题是否對應、正文主体是否被大幅裁剪、结构化資料是否只留在 PC 頁、移動頁是否為了轻量而省掉了整段内容。
處理完之後按什么顺序观察
- 看服務器日誌里移動 UA 與 PC UA 分別抓取了哪些 URL，確認标注生效後抓取是否逐渐收敛到規范版本。
- 看索引报告里两套 URL 的归属變化。這一步通常需要几周，不是标注改完就立刻變化。
- 用站内搜尋查一下，只作粗略參考，數量本身並不精确。
标注只是表達你的意图，最终归並仍需要搜尋引擎重新抓取和處理。不要因為短期内没看到變化就反复改動标注，来回改反而让關系更难判断。
如果站点内容量不大、模板也不复杂，直接改成响應式是最省事的做法，能從根上避免两套 URL 的問题；如果短期改不動，就先把双向标注、重定向方式和缓存策略這三處對齐，再等抓取自然收敛。