给页面加 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 到自己，而不是互相指。
当这些信号方向不一致时，搜索引擎需要自己判断，结果往往不稳定，收录状态也会来回反复。
一个可执行的核对顺序
- 从站点后台或抓取日志里找出收录异常的页面，确认它当前声明的 canonical 目标。
- 直接抓取这个目标 URL，记录状态码、robots 指令、robots.txt 是否放行。
- 检查目标页正文与源页面是否真的等价，属于同一内容的不同版本。
- 确认目标页没有再指向第三个 URL，不存在链式 canonical。
- 核对内链、Sitemap、hreflang 的方向是否与 canonical 一致。
- 如果目标本身不可索引，二选一：要么修好目标页，要么把 canonical 改指向一个真正可索引的等价页面。
- 改动后重新提交相关 URL，观察抓取与索引状态的变化，不要期待立刻生效。
几个容易忽略的细节
- canonical 用绝对地址更稳妥，相对路径在某些解析场景下容易出错。
- 移动版与桌面版如果各自 canonical 到自己，等于互相否认，应该都指向同一主版本。
- 分页序列里，把第 2 页 canonical 回第 1 页，会让后续内容失去被发现的机会，通常不建议这样做。
- 大量低质页面互相 canonical 并不能提升质量，只能减少重复。
canonical 的可靠性，取决于它指向的那个 URL 是否真的存在、可抓、可索引。指向之前，先确认目标站得住脚，再决定要不要把信号交出去。