给頁面加 canonical，本意是把重复的 URL 合並到一個主版本上，让搜尋引擎只保留一個。但這個信号有個前提：你指向的那個 URL，本身要能被抓取、能被索引。如果目标頁出了問题，源頁面不但合並不成，還可能跟着一起從索引里消失。

canonical 是轉移信号，不是保留信号

很多人下意识把 canonical 当成“保護主頁面”的工具，實际上它表達的是“這一頁不是主版本，請去看那一頁”。搜尋引擎收到這個信号後，會尝试把源頁面已有的權重與收錄狀態轉移到目标 URL 上。如果目标 URL 不可索引，轉移就落空了，而源頁面因為已经声明“我不是主版本”，反而更容易被剔除。

先查目标 URL 的三個狀態

• 可抓取：目标 URL 是否被 robots.txt 屏蔽，返回的是 200 還是 3xx／4xx／5xx。
• 可索引：目标頁的响應头或頁面里有没有 noindex，meta robots 與 X-Robots-Tag 是否互相冲突。
• 内容等價：目标頁和源頁面的主体内容是否真的接近。如果只是同一套模板、正文完全不同，canonical 属于用错场景。

這三項里任何一項不通過，canonical 就失去了成立的基础。

目标 URL 常见的几種“不可索引”

目标頁自己带了 noindex

有些站点在測試环境或某些列表頁上留了 noindex，後来把這個 URL 当成了 canonical 目标。源頁面把信号全指向一個明确拒绝索引的頁面，两個頁面都可能慢慢登出索引。

目标頁被 robots.txt 屏蔽

robots.txt 阻止抓取，意味着搜尋引擎可能看不到目标頁的 canonical 声明，也無法確認它的内容。這種情况下，源頁面的 canonical 指向等于打空。

目标頁返回 404、410 或跳轉別處

内容重构後，原来的主版本 URL 被删掉了，canonical 却没同步更新。指向一個已下线的 URL，源頁面得不到有效的合並目标。

鏈式 canonical

A 頁 canonical 到 B，B 又 canonical 到 C。如果 C 不可索引，整條鏈上的頁面都可能受影响。核對时要顺着指向一路查到最终的落点。

再核對信号是否互相矛盾

canonical 不是孤立生效的，它要和站点里其他信号對齐：

• 内鏈指向的是源頁面還是目标頁面，權重分配是否和 canonical 方向一致。
• Sitemap 里提交的是哪個版本，是否還在提交已经被 canonical 掉的 URL。
• hreflang 的每個語言版本是否各自 canonical 到自己，而不是互相指。

当這些信号方向不一致时，搜尋引擎需要自己判断，结果往往不稳定，收錄狀態也會来回反复。

一個可执行的核對顺序

1. 從站点後台或抓取日誌里找出收錄異常的頁面，確認它目前声明的 canonical 目标。
2. 直接抓取這個目标 URL，记錄狀態碼、robots 指令、robots.txt 是否放行。
3. 检查目标頁正文與源頁面是否真的等價，属于同一内容的不同版本。
4. 確認目标頁没有再指向第三個 URL，不存在鏈式 canonical。
5. 核對内鏈、Sitemap、hreflang 的方向是否與 canonical 一致。
6. 如果目标本身不可索引，二選一：要么修好目标頁，要么把 canonical 改指向一個真正可索引的等價頁面。
7. 改動後重新提交相關 URL，观察抓取與索引狀態的變化，不要期待立刻生效。

几個容易忽略的细节

• canonical 用绝對地址更稳妥，相對路径在某些解析场景下容易出错。
• 移動版與桌面版如果各自 canonical 到自己，等于互相否認，應该都指向同一主版本。
• 分頁序列里，把第 2 頁 canonical 回第 1 頁，會让後續内容失去被發現的机會，通常不建议這样做。
• 大量低质頁面互相 canonical 並不能提升质量，只能减少重复。

canonical 的可靠性，取决于它指向的那個 URL 是否真的存在、可抓、可索引。指向之前，先確認目标站得住脚，再决定要不要把信号交出去。