站内出現重复内容时，canonical 是最常用的收口手段：把几個相似的 URL 都指向同一個主版本，让搜尋引擎知道该保留哪一個。但很多人只检查了「指向對不對」，忽略了另一半——被指向的那個 URL 本身能不能被抓取、能不能進索引。如果目标頁自己就進不去，收口鏈條其實是断的。
canonical 是提示，不是指令
先建立合理预期：canonical 属于建议性信号，搜尋引擎會參考，也可能忽略，它會结合内鏈、站点地图、内容相似度、外部連結等一起判断。所以寫對了不保證一定按你的设想收口；但如果寫错了，或者指向的目标頁存在硬性障碍，那基本不會按你的设想收口。
几個常见的断点
目标 URL 被 robots.txt 屏蔽或自带 noindex
這是最典型的一種。頁面 A 的 canonical 指向頁面 B，而 B 恰好被 robots.txt 禁止抓取，或者 B 自己带了 noindex。结果是 B 不會被索引，A 又明确声明自己不是主版本，两邊信号互相抵消，最後可能两個 URL 都不出現在索引里。要作為收口目标的頁面，首先得是「允许被抓取、允许被索引」的頁面。
目标 URL 不可訪問或已经跳轉
canonical 指向一個 404、410 或返回 200 但内容為空的頁面，信号都會被削弱。指向一個會 301 的中間地址也容易出错：你以為最终會落在 C，但 canonical 寫的是 B，等于多绕了一层，還可能在後續改版中再次断掉。規范做法是直接指向最终可訪問、長期稳定的那個 URL。
鏈式與环状 canonical
A 指向 B，B 指向 C，C 又指回 A，這類鏈條會让判断變得混乱。原則上應该是「多對一」：所有變体直接指向同一個主版本，而不是一個指一個。鏈式 canonical 在批量改版、模板层层套用的站点里很常见，值得专门抽查一遍。
跨域 canonical 指向自己控制不了的頁面
把站内頁面 canonical 到另一個域名，相当于主動把收錄让出去。如果目标站之後改版、下线或给頁面加了 noindex，你這邊没有任何控制權。除非确實存在轉载授權關系，並且能長期协調，否則不建议這么做。
canonical 與内鏈、站点地图、hreflang 说法不一致
内鏈大量指向變体 URL、站点地图里同时提交了變体和主版本、hreflang 又把某個變体当成獨立語言版本——這些信号會和 canonical 打架。收口不只是加一個标簽，還要让站内其他地方的表述统一起来，否則每個信号都在往不同方向拉。
一條可执行的排查顺序
- 取出頁面上寫死的 canonical，確認是绝對 URL，且指向的是最终版本而不是中間版本。
- 打開目标 URL，確認返回 200，内容與来源頁属于同一主题或本身就是同一内容。
- 检查目标 URL 是否被 robots.txt 屏蔽、是否带 noindex、是否存在 meta refresh 或纯 JS 跳轉。
- 查看目标 URL 自己的 canonical 指向哪里，顺着鏈條一直走到头，確認没有环。
- 對照站点地图、内鏈、hreflang 的寫法，看是否與 canonical 保持一致。
日常维護的几個习惯
- 主版本 URL 一旦确定，尽量長期不換；确實要換时，同步修改所有指向它的 canonical。
- 模板层慎用「自動取目前 URL」的 canonical 寫法，容易把带參數的變体也当主版本。
- 栏目合並或改版之後，抽查几條收口鏈條是否還能走通。
- 關注服務器日誌和覆盖率报告，看被 canonical 收掉的 URL 是否出現異常堆积。
收口的目标不是「少几個 URL」，而是让该被索引的那個版本稳定地被索引。指向的目标頁自己進不去索引，收口就等于没做。
如果排查收錄时發現某個變体長期不消失，或者主版本反而没進索引，先別急着改内容，從 canonical 指向的目标頁開始往下查，通常能更快定位問题。