canonical 是建议，不是命令
很多站点在頁面里寫了 canonical，指向自己認為的規范版本，但索引报告里顯示的却是另一個 URL。這不是标簽寫错了，而是搜尋引擎在综合站内信号、外鏈和抓取歷史後，自己選了一個它認為更合适的版本。理解這一点，排查时就不會只盯着那一行代碼。
先確認两件事：你声明了什么，索引實际選了什么
在索引报告或 URL 检查工具里，通常會看到「用戶声明的規范網址」和「Google 選擇的規范網址」两個字段。前者是你通過 canonical、sitemap、hreflang 等给出的信号，後者是索引實际采用的版本。两者不一致时，問题往往出在信号冲突或頁面质量判断上。
常见原因一：站内信号互相打架
同一個内容被多個 URL 承载时，如果各處给出的規范指向不同，索引系統會倾向于忽略你的声明。常见冲突包括：
- 頁面 canonical 指向 A，sitemap 里提交的是 B。
- 内鏈大量指向 B，canonical 却指向 A。
- hreflang 指向 C，canonical 又指向 A。
- 舊 URL 通過 301 跳到新 URL，但新 URL 的 canonical 又指回舊 URL。
站内信号不一致时，先统一再谈收錄。
常见原因二：重复内容太接近，索引自己挑了一個
如果 A、B 两個頁面正文几乎相同，canonical 指向 A，但 B 有更多外鏈、更早被收錄、抓取更频繁，索引可能選擇 B。這不是 canonical 失效，而是重复内容治理没做到位。把两個版本真正合並、只保留一個可訪問 URL，比反复改 canonical 更有效。
常见原因三：canonical 鏈、循环和跨域問题
canonical 可以形成鏈：A 指向 B，B 指向 C。索引通常會跟随到最终頁，但如果鏈條中有頁面不可抓取、返回错誤或被 robots 屏蔽，跟随就會中断。跨域 canonical 也需要目标頁可訪問、内容确實一致，否則索引不會采纳。
常见原因四：技術细节让声明讀不到或失效
- canonical 只寫在 JS 渲染後的 DOM 里，首次 HTML 中没有。
- URL 大小寫、參數顺序、末尾斜杠不一致，被当成不同頁面。
- canonical 目标頁返回 404、301 或 noindex。
- 頁面本身被 robots.txt 屏蔽，抓取不到就無法讀取声明。
按顺序排查的四個步骤
- 抓取實际 HTML：用抓取工具查看服務器返回的原始 HTML，確認 canonical 是否存在、是否被 JS 注入。
- 對比站内信号：把 canonical、sitemap、内鏈、hreflang、301 規則列在一起，看是否指向同一個 URL。
- 检查外鏈與抓取歷史：看被索引選中的版本是否有外部連結或更早的收錄记錄。
- 核對索引报告：查看「用戶声明的規范網址」與「Google 選擇的規范網址」，判断差异是信号問题還是内容問题。
修正後的预期與注意事項
统一站内信号後，索引重新選擇規范版本需要時間，通常要等頁面被重新抓取和重新评估。不要频繁修改 canonical 指向，也不要在多個版本之間反复切換，否則會延長索引稳定的周期。
canonical 更像一次内部投票，站内所有入口投给同一個 URL，比單獨寫一個标簽更有分量。
如果多個版本内容确實不同，先决定保留哪一個，再處理重复版本。收錄和索引選擇受多種因素影响，本文只提供排查顺序，不承诺具体收錄结果或排名變化。