先分清 canonical 能做什么
canonical 标签是给搜索引擎的一个合并提示，不是一条强制指令。搜索引擎在决定哪一版 URL 进入索引时，会综合内链、sitemap、外链、内容相似度等信息，canonical 只是其中一项信号。所以“写了 canonical，收录的却是另一版”并不算异常，多数情况下是这套信号之间互相打架。
它主要解决的是：同一份内容可以通过多个地址访问（带参数、大小写不同、带不带 www、打印版等），你希望哪一版承担权重。
常见的不生效写法
1. 自引用 canonical 缺失或写得不一致
每个可索引页面最好写一条指向自身的 canonical，并且这个地址要和页面真实地址完全一致——协议、主机名、路径、末尾斜杠、大小写都算。如果主版本页面自己写了一条指向别处的 canonical，它就会被系统当成副本看待。
2. 指向了一个不可索引的 URL
- 指向的地址返回 301、302 或 404；
- 指向的地址本身带 noindex；
- 指向的地址被 robots.txt 屏蔽。
这几种情况下合并信号基本会被忽略，搜索引擎只能按自己的判断挑一版。
3. 由脚本注入或位置异常
canonical 放在 head 里最稳妥。如果是脚本动态插入，要确认渲染完成后确实存在，并且不要出现多条互相冲突的 canonical。页面里出现两个不同的 canonical 地址，等于没写。
4. 跨域 canonical 需要更多佐证
把 A 站页面 canonical 到 B 站，处理会比较谨慎。两站内容高度一致、又有互相指向的内链时收敛会快一些；否则很可能被直接忽略。
5. 和其他信号自相矛盾
canonical 说 A 是主版本，但 sitemap 里只提交了 B，站内链接也大量指向 B，这就是自己给自己制造矛盾。信号越统一，收敛越快。
一份可执行的自查顺序
- 先确定你真正想保留的主版本 URL，把完整地址记下来，包括协议和末尾斜杠。
- 查看源代码，确认页面上 canonical 的实际取值；如果是 JS 页面，对比渲染前后是否一致。
- 访问 canonical 指向的地址，确认它返回 200、可以被索引、没有 noindex，也没有被 robots.txt 拦住。
- 检查 sitemap、内链、面包屑、结构化数据里的 URL 是否都指向同一个版本。
- 排查参数、大小写、斜杠造成的多种变体，逐一收敛到主版本。
- 在 Search Console 的 URL 检查里查看 Google 选定的规范网址，和自己的预期做对照。
几个容易忽略的细节
- 分页不要全部 canonical 到第一页，那样会抹掉后续页面的入口价值，一般让每页自引用更合适。
- 移动版和桌面版互相标注时，canonical 与 alternate 别写反。
- HTTP 与 HTTPS、带 www 与不带 www，只保留一套，其余用 301 统一。
- canonical 管的是合并，不管发现。指望它加快收录，方向就错了。
canonical 的作用是把信号摆清楚，而不是替你决定结果。真正进索引的是哪一版，仍取决于这套信号加上抓取和内容判断的综合结果。
调整之后不建议频繁改动，给系统一点重新评估的时间，再回看选定规范网址是否已经收敛。如果长期不一致，优先检查第 2、3 步，多数问题出在 canonical 指向的地址本身不可索引。