做收錄排查时，常會遇到一種情况：搜尋某個關鍵詞，点進去發現落地頁不是自己提交的那條 URL。你提交的是 A，索引里留着的是 B；或者站点地图里寫的是 A，搜尋结果展示的却是带參數的 A?from=xxx。頁面能抓、内容也在，就是地址對不上。
這通常不算收錄故障，而是搜尋引擎在重复内容聚簇里重新選了一次規范版本。它會把一组内容相近的 URL 归到一起，挑一條作為代表留在索引里，其余的当作重复項跟随。你需要判断的是：被挑中的那條，是不是你希望用戶看到的。
它通常會參考哪些信号
- 頁面上的 canonical 声明，以及它是否自指、是否指向一條真正可訪問的 URL
- 站内連結：導航、面包屑、列表模板里指向该内容时用的是哪個版本
- 站点地图中提交的地址
- 重定向鏈的终点
- http 與 https、带 www 與不带 www、结尾带不带斜杠這些歷史形態
- 頁面主体内容的完整度與相似度，正文更完整、位置更靠前的那條往往更占優势
几種高發的改寫场景
參數版本抢走主版本
跟踪參數、排序參數、會话 ID 都會參與進来。搜尋引擎一般倾向于挑不带參數的版本，但這不是必然。如果站内連結大量指向带參數的版本，它也可能反過来被選中。
分頁與篩選列表
第 2 頁、第 3 頁與第 1 頁正文高度相似时，被归並很常见。列表頁上不同篩選组合如果反复呈現同一批條目，也容易在索引里互相替換。
同一内容存在多個入口
比如商品同时挂在 /product/123 和 /category/a/product/123，两條都能打開且内容一致。站内哪個入口被連結得更多，哪條更容易被留下。
打印頁、AMP 頁、移動版
這類次級版本如果没有處理好對應關系，很容易出現索引里留的是体驗較差的那一條，用戶打開後内容和预期不一致。
排查顺序可以這样走
- 用 site: 搜尋頁面标题的完整字符串，看返回的是哪條 URL。
- 拿這條 URL 和预期 URL 做對比，找出差在协议、域名、路径、參數還是斜杠。
- 核對两條 URL 上的 canonical，看是自指、互指，還是指向了站外地址。
- 查服務器日誌，確認搜尋引擎實际抓取的是哪一條，抓取频次是否集中在非预期版本上。
- 检查站内連結，尤其是導航和列表模板，是否把非预期版本当成了主要入口。
排查這類問题的關键，是先確認「哪條被抓、哪條被留下」，而不是先動頁面内容。地址层面的混乱，用内容手段解决不了。
想让它按你的意愿選，能做的是收敛
- 先選定一條規范 URL，全站统一使用，包括導航、面包屑、内鏈和分享按钮。
- canonical 保持自指，指向的地址要能直接打開並返回正常狀態碼。
- 站点地图只放規范地址，不要把同一内容的各種形態都塞進去。
- 對跟踪參數、會话參數做统一處理，减少同一内容产生大量變体。
- 确實多余的入口，用 301 指向規范版本，而不是让它和主版本長期並存。
這些動作不會立刻改變结果。規范版本是搜尋引擎在多次抓取後逐步形成的判断，重新聚簇需要時間，別拿某一天的搜尋结果下结论。
有些情况不必强行纠正
如果被選中的版本同样可正常訪問、内容完整、移動端体驗也没問题，用戶從搜尋结果進来看得到完整信息，那這次改寫對站点並没有實质损失。真正需要處理的是：留下的是空壳頁、纯參數頁、重复目錄，或者用戶落地後看到的内容與标题明顯不符。
與其追求让某一批 URL 嚴格按预期進索引，不如把重心放在减少同一内容的多種可訪問形態上。地址形態收敛了，規范化選擇的结果自然也更容易稳定。