很多站点在發現同一内容有多個 URL 时，第一反應是加 canonical，指向主版本，然後等待收錄归拢。canonical 确實有用，但它只是一個提示，搜尋引擎會结合重定向、内鏈、sitemap、hreflang 等信号一起判断。指定之後不核對，容易出現指定了却不算數的情况。
先分清：哪些頁面适合用 canonical
canonical 主要解决同一份内容出現在多個 URL 的問题，而不是處理内容不同的頁面。常见场景包括：
- 带跟踪參數、排序參數、會话參數的 URL；
- 打印版、纯文本版、AMP 版等同一内容的變体；
- 商品篩選後生成的列表頁，與主列表頁内容高度接近；
- HTTP 與 HTTPS、带 www 與不带 www 同时可訪問；
- 分頁中的單頁被獨立訪問，但内容主体仍属于列表。
如果两個頁面主题不同、正文不同，硬用 canonical 合並，可能让其中一個頁面失去被單獨评估的机會。判断标准不是像不像，而是用戶看到的内容是否基本一致。
指定 canonical 之後，先核對這五處
1. 自引用是否正常
每個規范頁面最好有一條指向自己的 canonical。如果主版本頁面没有自引用，而其他變体都指向它，信号會顯得不完整。自引用地址要和頁面實际訪問地址一致，包括协议和域名。
2. 目标地址是否可達
canonical 指向的頁面如果返回 404、500，或被 robots.txt 屏蔽，或被 noindex 标记，這個提示就难以成立。目标頁面應当是 200 狀態、可抓取、可索引的規范版本。
3. 是否與重定向冲突
如果 A 頁面 canonical 指向 B，同时 A 又 301 到 C，信号就乱了。一般来说，能重定向就重定向，不能重定向再用 canonical。两者同时使用且指向不同地址，容易让收錄归属摇摆。
4. 是否與 hreflang、sitemap 一致
多語言站点要特別注意：canonical 不能跨語言版本乱指。每個語言版本通常應自引用，或用 hreflang 表達對應關系。sitemap 里提交的 URL 也最好與 canonical 保持一致，减少相互矛盾。
5. 是否由 JS 後插入
如果 canonical 由 JavaScript 動態寫入，需要確認搜尋引擎渲染後能否稳定看到。更稳妥的做法是让服務端直接輸出，至少在關键頁面如此。
收錄归属看起来不對，排查顺序
發現搜尋结果顯示的是另一個 URL，或者主版本迟迟没有出現时，可以按這個顺序看：
- 確認是否真的重复。先對比标题、正文、主要模块。如果内容差异明顯，可能不是 canonical 能解决的問题。
- 检查内部連結指向谁。站内連結、導航、面包屑大量指向變体 URL，會削弱 canonical 的效果。
- 检查抓取记錄。看服務器日誌里两個 URL 的抓取频率和响應狀態，判断蜘蛛是否正常拿到頁面。
- 检查其他信号。sitemap、结构化資料、外鏈、分享連結是否指向了非規范版本。
- 小批量調整後观察。不要一次性大改全站 canonical，先處理一個栏目或一组頁面，观察几周再扩大。
canonical 是建议，不是開關。它帮助搜尋引擎理解你的偏好，但最终收錄哪個 URL，仍取决于多重信号和頁面本身的质量。
几個容易踩的坑
- 全站 canonical 统一指向首頁，導致内頁無法被單獨收錄；
- 分頁頁面全部 canonical 到第一頁，用戶翻到第 5 頁却看到第 1 頁的标题；
- canonical 指向的頁面本身被 noindex，形成矛盾；
- 同一頁面在不同模板里輸出不同 canonical，今天指 A 明天指 B；
- 把 canonical 当成去重萬能药，忽略了内容重复的根源。
更實际的做法是：先确定站点希望哪個 URL 作為主版本，然後让内鏈、sitemap、重定向、canonical 尽量指向同一個地址。定期抽查几個重要栏目，看搜尋结果里出現的 URL 是否符合预期，比一次性配置完就放着更有效。