做站点运营时，canonical 标簽常被当成“寫了就一定生效”的開關。實际它不是强制指令，而是一種明确表態：告诉搜尋引擎“這一组頁面里，我認為哪個是主版本”。搜尋引擎會參考這個表態，但也會结合内鏈、sitemap、跳轉、内容本身等因素综合判断。所以“寫了 canonical 却没生效”這件事，更接近一次信号冲突，而不是标簽失效。
第一步：先確認标簽本身没寫错
很多問题卡在最基础的地方，检查一遍成本很低，但能排除掉大半干扰。
- 建议使用绝對 URL，带上协议和域名，路径寫完整。相對路径虽然常被识別，但在跨目錄、多域名环境下容易出偏差。
- 标簽放在 <head> 内，不要寫在 body 里。文档中途出現的 canonical 容易被忽略。
- 一個頁面只保留一個 canonical。重复輸出多個时，常见结果是全部不采纳，或者采纳了和你预期不同的那個。
- 不要把 canonical 指向 404、410、重定向鏈中間頁，或者本身带 noindex 的頁面。目标頁無效，等于這個表態作废。
- 規范頁建议做自引用，即自己 canonical 到自己。這能减少“到底谁才是主版本”的歧义。
第二步：看是不是被其他信号顶掉了
当多個信号指向不同结果时，搜尋引擎只能自己選一個。常见冲突有這几類：
hreflang 與 canonical 互相打架
多語言站点里，如果語言版本之間互相 canonical，等于在说“只要一個語言版本就够了”，這通常不是你的本意。語言版本之間應该用 hreflang 關联，canonical 指向各自語言内的規范頁。
sitemap 和 canonical 不一致
sitemap 里同时列出了參數頁和規范頁，内鏈又大量指向參數頁，只有 canonical 一個信号说“去規范頁”。這種少數服從多數的局面下，不被采纳很正常。
頁面被 noindex 或 robots.txt 屏蔽
如果規范頁本身被屏蔽抓取或标记 noindex，canonical 指向它就失去了意义。反過来，重复頁被 noindex 时，canonical 通常也不再需要。
第三步：判断内容差异是不是太大了
canonical 适合處理“同一内容的不同 URL 形態”，比如排序參數、跟踪參數、大小寫差异、打印頁等等。它的前提是主体内容基本一致。
如果两個頁面只是套了同一個模板，正文、商品信息、评论完全不同，硬做 canonical 指向其中一個，往往會被判定為建议不合理。這種情况更该考虑的是：它們本来就是两個頁面，還是應该合並成一個頁面。
第四步：確認搜尋引擎實际看到的是哪個版本
頁面在浏览器里顯示正常，不代表抓取时看到的也是同一份 HTML。
- 如果是 JS 渲染的站点，检查渲染完成後的 DOM 里 canonical 是否被脚本改寫或覆盖。
- 检查是否存在 A/B 測試、多套模板、CDN 邊缘改寫，導致同一 URL 返回不同的 head 内容。
- 移動端與桌面端分別查看，確認两邊的 canonical 指向一致，不要各自指回自己。
- 用带 UA 的抓取工具或日誌回放，看返回的原始 HTML，而不是渲染後的结果。
一個可执行的排查顺序
- 查看原始 HTML，確認 canonical 存在、唯一、在 head 内、是绝對 URL。
- 確認目标頁返回 200，且自身没有 noindex、没有被 robots.txt 屏蔽。
- 對照 sitemap、内鏈、跳轉、hreflang，看是否有信号指向另一個 URL。
- 比較两個頁面的主体内容，判断差异是否已经超出“同一内容”的范围。
- 確認抓取时返回的 head 與浏览器所见一致，排除脚本改寫和邊缘改寫。
- 看搜尋引擎最终選擇的規范 URL 是哪個，再决定是調整信号，還是改用跳轉合並。
如果确實不生效，可以怎么兜底
当信号長期無法统一，或者两個 URL 本来就不该同时存在时，可以考虑更直接的手段：
- 用 301 永久跳轉把重复 URL 真正合並到一個地址上，這是最强的一種表態。
- 统一站内連結，让導航、面包屑、列表頁、相關推荐都指向規范版本。
- sitemap 只保留規范 URL，减少把重复版本送進發現队列。
- 從源头减少重复，比如统一參數規則、统一大小寫與末尾斜杠規則。
canonical 解决的是“同一内容有多個入口”這類問题，解决不了“内容本身要不要合並”。把這两件事分開看，排查會清楚很多。
最後提醒一句：規范化的目标是让搜尋引擎更容易理解你的站点结构，而不是保證某個 URL 一定會出現在索引里。判断是否生效，重点看结果是否收敛、是否稳定，而不必纠结某一天的查询结果。