canonical 是页面 head 里的一行声明，作用是告诉搜索引擎：这些地址里，我推荐哪一个作为规范版本。它属于提示性信号，不是强制指令，搜索引擎仍可能根据自己的判断选择别的地址。所以写错的时候，典型后果不是立刻出现明显异常，而是让本来能收口的页面变得更混乱，排查起来也更绕。
先分清 canonical 和 301 各自负责什么
很多错误写法，根源是把这两个工具混着用。可以先按下面的分工来判断：
- 301：旧地址确实不再使用，用户也应该被带到新地址。这是服务器层面的强信号。
- canonical：多个地址都能正常访问，用户访问哪个都不报错，但内容基本一致。这是页面内的建议。
- 如果地址已经彻底不用，优先考虑 301；canonical 更适合处理同时存在、都不该直接下线的地址。
几种常见的写错方式
1. 指向了一个打不开的地址
canonical 写的是一个 404、410 或者需要登录才能访问的 URL。这种写法会让规范版本的指向失效，搜索引擎只能自行判断哪个地址更合适。上线模板改动频繁的站点，尤其容易出现这种拼写或路径残留的问题。
2. 全站所有页面都指向首页
常见于模板误配：每个页面都输出同一个 canonical。结果是把大量内容页的规范版本都指向了首页，这既不符合页面的真实意图，也会让内层页面的正常收录判断变得混乱。通常一个页面应该指向它自己，或者指向它真正的对等版本。
3. 分页页统一指向第一页
第 2 页、第 3 页如果只是同一批内容的重新排序，指向第一页有一定合理性；但如果分页里包含独立的条目，全部指向第一页就等于主动放弃这些内容的独立身份。判断标准很简单：翻到后面几页，上面是否有在前一页没出现过的内容。
4. 两个地址互相指向对方
A 页面 canonical 到 B，B 页面 canonical 到 A。这种闭环让声明互相抵消，等于没有给出明确方向。批量生成 canonical 时，最容易因为规则写得含糊而出现这种情况。
5. 相对路径解析结果和预期不一致
写成相对路径本身没问题，但要看它相对的是哪个地址。带参数、带目录深度的页面里，解析结果可能和手工预期不同。如果不能确定，写完整地址更稳妥。
6. 用 canonical 去指向别人家的页面
把跨站重复的内容通过 canonical 指向来源站，是一种明确表态。这种做法有它的适用场景，但需要谨慎评估：它表达的是“认可对方为规范版本”，而不是一种提权手段。决策前最好先确认双方内容的重合度。
和 noindex、hreflang 放到一起看
- 一个页面同时写了 noindex 和 canonical，信号是矛盾的。如果这个地址本就不该出现在索引里，优先用 noindex，不必再给它指定规范版本。
- 多语言或多地区站点，canonical 通常应该指向同一语言下的对等页面，而不是全部指向主站首页，否则会和 hreflang 的表达冲突。
- canonical 指向的地址本身又被 robots.txt 屏蔽，搜索引擎无法确认目标页面内容，这个声明也很难被采纳。
一份可执行的自查清单
- 抽查页面源码里的 canonical 地址，逐个打开确认返回的是正常页面，状态码为 200。
- 确认 canonical 地址和当前页面是同一套协议、同一套域名，避免 http 与 https、带 www 与不带 www 混用。
- 用抓取工具批量导出页面的 canonical 字段，统计是否出现大量页面指向同一地址的情况。
- 检查分页、筛选参数、排序参数页面，判断是否需要收口，还是应该保留独立身份。
- 对照站点地图和索引报告，看规范版本的选择是否和预期一致。如果报告里提示“用户选择的规范网页与搜索引擎选择的规范网页不同”，说明声明没有被完全采纳，需要回到页面内容层面找原因。
什么时候可以不写
如果一个地址本来就是唯一的，没有参数、没有镜像、没有大小写和斜杠的变体，那不写 canonical 也不会有问题。canonical 的意义在于解决多地址并存，而不是给每个页面都加一行凑数的标签。
canonical 做的是收口，不是提权。它不会让一个本来不适合进入索引的页面变得值得收录，也不会替代内容质量本身的判断。
总结一句：先想清楚页面到底有多少个可访问地址、哪个是你希望被当作规范版本的，再去写这一行声明。顺序反过来，先按模板批量输出，再回头猜哪边写错了，往往要花更多时间排查。