canonical 标簽的作用是告诉搜尋引擎：這一组相似頁面里，我認為哪個是主版本。它是一個建议，不是强制指令。搜尋引擎會把它当作重要參考，但最终哪個 URL 進索引、哪個被折叠，還要结合内容相似度、内鏈结构、外鏈分布和站点歷史一起判断。所以出現“canonical 寫了却不管用”並不奇怪，關键是判断問题卡在哪一步。
搜尋引擎挑規范頁时會看什么
在决定两個高度相似的 URL 谁進索引时，通常會综合以下几類信号：
- 内容相似度：两頁正文是否几乎一致。如果差异超過一定比例，就不會被当成同一组處理。
- 站内連結：哪個 URL 拿到的内鏈更多、出現在更重要的導航位置。
- 站点层面的信号：sitemap 里提交的是哪個、协议和域名寫法是否统一、是否有重定向轉發。
- 外鏈與歷史：外部連結指向谁、這個 URL 被收錄的時間和稳定性如何。
- URL 本身：层級是否清晰、參數是否過多、是否带有會话 ID 之類的临时字段。
canonical 只是這些信号中的一個。当它和其他信号一致时，效果最好；当它和其他信号相反时，往往會被忽略。
canonical 失效的几個典型场景
两個頁面互相指
A 頁寫 canonical 指向 B，B 頁同时寫 canonical 指向 A。這種寫法等于互相抵消，搜尋引擎只能自己判断，结果经常和预期不一致。規范頁的關系應该是單向的。
指向了一個不能当主版本的 URL
常见的是 canonical 指向的頁面返回 404、被 noindex 标记，或者本身是 301 跳轉鏈中的一环。目标頁自己都不想被收錄，這個声明自然不會生效。指向带參數的 URL、指向尚未上线的頁面，也是同類問题。
canonical 由 JavaScript 渲染
如果 canonical 只寫在客戶端渲染的代碼里，抓取端未必能稳定拿到。想让它生效，最好在服務端返回的 HTML 里就直接輸出，不要依赖脚本执行。
内容差异太大，算不上同一组頁面
列表頁和詳情頁、不同城市的服務頁，如果正文主体内容差別明顯，即便地址相似，也不该用 canonical 互相指向。這種情况更适合各自獨立成頁，或者做真實的合並與去重。
分頁頁面全部指向第一頁
把所有分頁都用 canonical 指回列表第一頁，會導致後續分頁上的條目失去被抓取的入口。分頁是獨立存在的頁面序列，通常不需要這样處理。
跨域 canonical，但目标頁自己做了 noindex
站群或内容分發场景里，B 站用自己的頁面 canonical 指向 A 站，而 A 站對應頁面寫了 noindex。這时两邊都可能進不了索引，属于声明冲突。
自查顺序
- 用抓取工具查看原始 HTML，確認 canonical 是服務端輸出，地址拼寫正确，没有相對路径寫错的情况。
- 訪問 canonical 指向的 URL，確認它返回 200、没有被 noindex、不是重定向鏈的中間节点。
- 检查是否出現双向互指，一组頁面里應该只有一個最终規范頁。
- 對比 sitemap、内鏈和導航，看這些信号是否和 canonical 的指向一致。
- 在搜尋後台查看實际被選為規范頁的 URL，判断是偶發還是持續如此。
- 如果長期不一致，先解决内容重复本身，而不是反复調整标簽寫法。
几点實践建议
- 让 canonical、sitemap、内鏈、重定向四者指向同一個 URL，冲突越少，生效越快。
- URL 尽量只保留一種寫法，带 www 與不带 www、http 與 https 之間用 301 统一。
- 參數頁、篩選頁優先考虑用 robots.txt 或内部連結策略控制，而不是只依赖 canonical。
- 修改後需要给搜尋引擎重新抓取和重新判断的時間，短期内看不到變化属正常。
canonical 是减少重复版本的沟通方式，不是消除重复内容的工具。真正决定索引结果的是頁面之間的實际關系。