不少站点會遇到這样一種情况：頁面 A 明明寫了 canonical 指向頁面 B，本意是让 B 代表這组内容，過一段時間却發現索引里出現的是 A，B 反而查不到。這时候再去反复改标簽寫法，往往越改越乱。問题通常不在标簽本身，而在這组 URL 之間的信号是否一致。
先记住：canonical 是提示，不是指令
rel=canonical 表達的是“我認為這几個地址是同一份内容，請以這個為准”，它是一個建议。搜尋引擎會结合内鏈、sitemap、外鏈、内容相似度、抓取歷史等因素自行判断，最後選出的規范版本不一定和你寫的一致。所以排查的重点不该是“标簽有没有寫”，而是“围绕這组 URL 的其他信息有没有互相矛盾”。
当你寫下的 canonical 與實际生效的規范版本不一致时，先怀疑信号冲突，而不是怀疑标簽格式。
核對顺序：從目标頁能不能被收錄開始
建议按下面這個顺序查，前一步不成立时，後面的調整意义不大。
- 目标頁是否可抓取、可索引。用 URL 检查類工具看目标地址返回的狀態碼、robots 元标簽、X-Robots-Tag、是否被 robots.txt 拦截、是否需要登入。目标頁自己進不了索引，canonical 指向它就没有意义。
- 内容是否真的属于同一组。canonical 适合處理“几乎相同”的頁面，比如同一商品的不同排序參數、同一文章的打印版。如果两頁主题相近但内容明顯不同，被当成一组反而會让搜尋引擎忽略你的指定，甚至把不合适的頁面当成代表版本。
- 内鏈和 sitemap 是否也指向目标頁。如果站内導航、面包屑、列表頁、sitemap 全都指向 A，只有一段标簽说“以 B 為准”，這就是典型的方向冲突。搜尋引擎更倾向于跟随被大量連結指向的那個地址。
- 寫法是否前後矛盾或後置。检查是否存在同一頁面既自指又指向別處、http 與 https 混用、带 www 與不带 www 混用、相對路径與绝對路径混用；也要確認服務端返回的 HTML 里就有這個标簽，而不是依赖前端脚本渲染後才出現。
- 是否同时存在 noindex。noindex 與 canonical 同时出現是常见的冲突组合。noindex 一般會先起作用，结果是目标頁或目前頁两邊都進不去索引。
怎么看實际生效的規范化结果
不要只看自己寫的标簽，要看搜尋引擎最後選了谁作為規范版本。通常可以從這几處判断：
- URL 检查工具里的“用戶声明的規范網址”和“搜尋引擎選擇的規范網址”是否一致；
- 搜尋结果里展示的地址是哪一個，点击後是否跳到另一個；
- 抓取日誌里，被抓取更频繁、更新時間更近的是哪個地址；
- 站点後台的索引报告中，同一组 URL 是否反复出現替換、重复、已排除等狀態變化。
這几處指向同一個地址，說明規范化已经稳定；彼此不一致，說明還在摇摆，此时频繁改動只會延長這個阶段。
調整时容易犯的两個错
一是把 canonical 当成“權重轉移按钮”，把一堆不相干的頁面都指向首頁或某個热门頁，结果是這些指定普遍被忽略，首頁也可能被誤判。二是發現目标頁没收錄，就把 canonical 全部去掉，改成自指。自指本身没错，但如果這组 URL 确實高度重复，去掉之後重复問题會重新出現，索引里可能同时留下多個版本。
一個可执行的收口顺序
- 先保證目标頁狀態碼正常、未被 robots.txt 拦截、没有 noindex，能被稳定抓取。
- 把内容真正同组的頁面整理出来，区分“重复”和“只是相似”，只對前者使用 canonical。
- 统一内鏈、面包屑、sitemap 指向的地址，让它們和 canonical 方向一致。
- 把 canonical 寫成绝對地址，服務端輸出，避免大小寫、协议、尾斜杠的混用。
- 提交一次抓取，然後按一個抓取周期观察實际生效结果，不要每天改動。
規范化生效需要時間，也和站点的抓取频率有關。與其反复調整标簽，不如先把目标頁的可索引性、内容分组和站内連結方向這三件事理顺，剩下的交给抓取周期去驗證。