做重复内容收口时，很多站点會在一组相似 URL 上都加上 canonical，指向自己認為的正版頁面。過一段時間查索引，却發現被保留的是原来那一版，canonical 指向的頁面迟迟没進索引，甚至搜尋结果里的展示地址換成了另一個 URL。這不一定是你标簽寫错了，而是要先弄清 canonical 的定位。
canonical 是提示，不是强制指令
canonical 的作用是告诉搜尋引擎：這一组頁面里，我認為哪一個是主版本。它是一個信号，用来帮助合並重复内容、集中站内權重，但最终保留哪個地址進入索引，由搜尋系統综合判断。它多數情况下會被采纳，也可能被忽略。
所以“寫了 canonical，主版本就一定會被收錄”這個前提本身不成立。更現實的目标是：让系統更容易判断哪一版是規范的，减少同一份内容被拆成多個索引項。
索引挑頁面时會參考哪些信号
- 内容完整度：正文、图片、结构化資料更全的那一版，通常更容易被保留。
- URL 结构：简短、层級清晰、參數干净的地址往往更占優势。
- 内鏈與導航：站内連結更集中指向的那一版，被判断為主版本的几率更高。
- 站点地图：sitemap 里只放主版本，属于一致性上的加分項。
- 訪問稳定性：長期可用、响應正常的地址，比时開时關的地址更可靠。
- 歷史信号：已经被抓取、被外部連結過一段時間的地址，往往不容易被替換掉。
声明了却没生效的常见情况
- canonical 指向的頁面本身返回错誤碼，或被 robots.txt 挡住、带有 noindex。
- 一组頁面互相 canonical，或者 A 指向 B、B 又指回 A，信号自相矛盾。
- canonical 用的是相對路径，或带着參數，和實际 URL 對不上。
- 正文靠 JavaScript 渲染，抓取阶段拿到的 HTML 里 canonical 位置是空的。
- 主版本頁面上没有内鏈入口，站内几乎没人指向它。
- 移動版和桌面版分別声明了不同的規范頁。
排查顺序建议
- 先看被抓取的 HTML 源碼，確認 canonical 是否真的出現在里面，而不是渲染之後才出現。
- 確認目标 URL 能正常打開、返回 200，且没有被 robots 規則或 noindex 排除。
- 核對 canonical 的寫法與目标 URL 是否完全一致：协议、域名、大小寫、末尾斜杠、參數。
- 检查這一组頁面之間有没有互相指向、循环指向。
- 看内鏈和 sitemap 的指向是否和 canonical 保持一致。
- 以上都正常时，先观察几周，不要频繁改動标簽。
该做與不该做
该做的是把一套信号统一起来：canonical、内鏈、sitemap、分頁處理都指向同一個地址，並保證這個地址本身内容完整、能稳定訪問。不该做的是把 canonical 当成收錄開關，在几個 URL 之間来回切換，或者每個頁面都寫一句“此頁為主版本”，让信号變得混乱。
判断标准很简單：如果连你自己都说不清哪個地址是主版本，搜尋系統更难替你决定。先把主版本定下来，再让所有信号都指向它。
小结
canonical 能减少重复内容带来的困扰，但它既不保證主版本一定進索引，也不保證索引里只剩一個地址。把它理解為一份一致性声明，而不是收錄開關，排查思路會清晰很多：先確認信号是否真實存在、是否彼此一致，再谈效果。