canonical 是頁面 head 里的一行声明，作用是告诉搜尋引擎：這些地址里，我推荐哪一個作為規范版本。它属于提示性信号，不是强制指令，搜尋引擎仍可能根據自己的判断選擇別的地址。所以寫错的时候，典型後果不是立刻出現明顯異常，而是让本来能收口的頁面變得更混乱，排查起来也更绕。
先分清 canonical 和 301 各自负责什么
很多错誤寫法，根源是把這两個工具混着用。可以先按下面的分工来判断：
- 301：舊地址确實不再使用，用戶也應该被带到新地址。這是服務器层面的强信号。
- canonical：多個地址都能正常訪問，用戶訪問哪個都不报错，但内容基本一致。這是頁面内的建议。
- 如果地址已经彻底不用，優先考虑 301；canonical 更适合處理同时存在、都不该直接下线的地址。
几種常见的寫错方式
1. 指向了一個打不開的地址
canonical 寫的是一個 404、410 或者需要登入才能訪問的 URL。這種寫法會让規范版本的指向失效，搜尋引擎只能自行判断哪個地址更合适。上线模板改動频繁的站点，尤其容易出現這種拼寫或路径残留的問题。
2. 全站所有頁面都指向首頁
常见于模板誤配：每個頁面都輸出同一個 canonical。结果是把大量内容頁的規范版本都指向了首頁，這既不符合頁面的真實意图，也會让内层頁面的正常收錄判断變得混乱。通常一個頁面應该指向它自己，或者指向它真正的對等版本。
3. 分頁頁统一指向第一頁
第 2 頁、第 3 頁如果只是同一批内容的重新排序，指向第一頁有一定合理性；但如果分頁里包含獨立的條目，全部指向第一頁就等于主動放弃這些内容的獨立身份。判断标准很简單：翻到後面几頁，上面是否有在前一頁没出現過的内容。
4. 两個地址互相指向對方
A 頁面 canonical 到 B，B 頁面 canonical 到 A。這種閉环让声明互相抵消，等于没有给出明确方向。批量生成 canonical 时，最容易因為規則寫得含糊而出現這種情况。
5. 相對路径解析结果和预期不一致
寫成相對路径本身没問题，但要看它相對的是哪個地址。带參數、带目錄深度的頁面里，解析结果可能和手工预期不同。如果不能确定，寫完整地址更稳妥。
6. 用 canonical 去指向別人家的頁面
把跨站重复的内容通過 canonical 指向来源站，是一種明确表態。這種做法有它的适用场景，但需要谨慎评估：它表達的是“認可對方為規范版本”，而不是一種提權手段。决策前最好先確認双方内容的重合度。
和 noindex、hreflang 放到一起看
- 一個頁面同时寫了 noindex 和 canonical，信号是矛盾的。如果這個地址本就不该出現在索引里，優先用 noindex，不必再给它指定規范版本。
- 多語言或多地区站点，canonical 通常應该指向同一語言下的對等頁面，而不是全部指向主站首頁，否則會和 hreflang 的表達冲突。
- canonical 指向的地址本身又被 robots.txt 屏蔽，搜尋引擎無法確認目标頁面内容，這個声明也很难被采纳。
一份可执行的自查清單
- 抽查頁面源碼里的 canonical 地址，逐個打開確認返回的是正常頁面，狀態碼為 200。
- 確認 canonical 地址和目前頁面是同一套协议、同一套域名，避免 http 與 https、带 www 與不带 www 混用。
- 用抓取工具批量導出頁面的 canonical 字段，統計是否出現大量頁面指向同一地址的情况。
- 检查分頁、篩選參數、排序參數頁面，判断是否需要收口，還是應该保留獨立身份。
- 對照站点地图和索引报告，看規范版本的選擇是否和预期一致。如果报告里提示“用戶選擇的規范網頁與搜尋引擎選擇的規范網頁不同”，說明声明没有被完全采纳，需要回到頁面内容层面找原因。
什么时候可以不寫
如果一個地址本来就是唯一的，没有參數、没有镜像、没有大小寫和斜杠的變体，那不寫 canonical 也不會有問题。canonical 的意义在于解决多地址並存，而不是给每個頁面都加一行凑數的标簽。
canonical 做的是收口，不是提權。它不會让一個本来不适合進入索引的頁面變得值得收錄，也不會替代内容质量本身的判断。
總结一句：先想清楚頁面到底有多少個可訪問地址、哪個是你希望被当作規范版本的，再去寫這一行声明。顺序反過来，先按模板批量輸出，再回头猜哪邊寫错了，往往要花更多時間排查。