頁面上寫了 canonical，並不等于那個地址就會被收錄，也不等于目前頁一定會從索引里消失。它更像是告诉搜尋引擎“這几條地址里，我建议你選這一條作為代表”。最终怎么處理，搜尋引擎仍會结合内容相似度、連結關系、抓取情况自己判断。
几個常见的誤解
- 以為加上 canonical 就一定會合並權重。
- 以為 canonical 可以替代 noindex。
- 以為 A 指向 B，B 就一定收錄，A 就一定掉出索引。
- 以為在 A 頁里寫 canonical 指向 B，就能促使 B 被重新抓取。
這些都不是标簽能直接决定的事，把它当成一次建议，预期會合理很多。
地址寫對了，也可能不生效的几種情况
- 目标地址本身不可索引：如果 B 頁被 robots.txt 屏蔽、带有 noindex、或者返回非 200 狀態，A 指向它基本没有意义，搜尋引擎不會拿一個不能索引的頁面当代表。
- 两個頁面内容差异過大：canonical 更接近“同一份内容的不同地址”這種声明。如果 A 和 B 的标题、正文主体、主要板块差得明顯，它可能不被采纳。
- 信号之間互相矛盾：頁面里 canonical 指向 B，但 sitemap 只提交了 A，内鏈和外部連結也都指向 A，几路信号各说各话，采纳结果往往不如预期。
- 目标地址本身還在跳轉：B 又 301 到 C，鏈路拉長，處理優先級會下降，最好直接指向最终地址。
- 标簽由脚本後插入：如果靠 JS 在渲染後才寫入，而抓取时没有执行到那一步，标簽可能根本没被看到。能用服務端輸出就尽量用服務端輸出。
- 相對路径寫错：相對路径的解析依赖目前 URL，在參數頁、深层目錄下容易指向意料之外的地方，建议统一寫绝對地址。
- 多語言版本混用：語言版本之間本该用 hreflang 的地方，改成 canonical 互相指向，容易把一個語言版本整片折叠掉。
一份可以照着做的自检顺序
- 打開 B 頁，確認返回 200、没有 noindex、没有被 robots.txt 挡住，能被正常抓取。
- 確認 B 是最终地址，後面不再有跳轉。
- 確認 A 與 B 的标题、正文主体、主要功能确實一致，差距不要太大。
- 確認 canonical 寫的是绝對地址，大小寫、末尾斜杠、參數與 B 的實际地址完全對得上。
- 查看頁面源代碼（而不是開發者工具渲染後的 DOM），確認标簽出現在 HTML 里。
- 核對 sitemap、導航和内鏈中出現的地址，尽量與 B 保持一致。
- 改動之後按周观察，而不是按天，给抓取和重新评估留出時間。
不是所有看着像的頁面都该用 canonical
有些頁面表面上相似，其實是各自獨立的内容：不同城市的分站、不同型号的产品、内容有實质差异的列表頁。這几類强行 canonical 到同一個地址，用戶搜另一個词时反而找不到入口。它們更适合把差异做足，标题、正文、结构化資料各寫各的。
真正该收敛的是那些“同一份内容換了個地址”的情况：带追踪參數的連結、排序篩選後等價的頁面、http 與 https 並存、大小寫或末尾斜杠造成的重复。
它和另外几個指令的分工
canonical 管“選谁当代表”，noindex 管“這個地址別進索引”，robots.txt 管“別来抓”，nofollow 管“別顺着這個連結走”。四個關口各管一段，混着用容易出現指令打架。比如一個頁面既寫了 noindex，又 canonical 指向另一個正常頁面，搜尋引擎可能哪邊都不采纳。
把 canonical 当成一次建议，而不是一次設定生效。它需要和内容、連結、抓取情况配合，單靠一個标簽很难解决收錄問题。