canonical 是页面里出现频率很高、也最容易被当成“收录开关”的一个标签。站点遇到重复内容时，常见的处理方式是加一行 canonical，然后期待搜索结果里的地址统一成某一个 URL。实际过程要复杂一些：canonical 参与的是“多个地址指向同一份内容时，系统更倾向保留哪一个”的判断，而它只是一种提示。
canonical 是提示，不是指令
和 301 跳转相比，canonical 的信号强度要弱。301 表示这个地址已经不再使用、页面永久迁移；canonical 表示这几份内容相同，希望以某个地址为准。当系统判断两个地址的内容差异较大，或者站内链接、外链、站点地图都在指向另一个地址时，声明的 canonical 有可能被忽略。
canonical 表达的是“我更希望被当成哪个地址”，而不是“请只收录那个地址”。
三种常见写法
自引用
页面 canonical 指向自己。看起来多余，但它能明确告诉抓取端：这个地址就是正主，不要因为参数、分页或模板拼接改写展示地址。带排序、筛选参数的列表页通常需要自引用，避免同一批内容被拆成很多地址。
多个地址合并到一个
A、B、C 三个地址内容基本相同，都声明 canonical 指向 A。前提是三者确实高度一致：正文、标题、主要模块都要对得上。页脚多了个参数不算差异，正文完全不同就不适用。
指向一个打不开的地址
canonical 指向返回 404、5xx 或需要登录的地址，等于把一个失效的目标交给抓取端。这种情况通常会被忽略，还可能顺带浪费一次抓取机会。
容易踩的几种误用
- 指向被 noindex 的页面。两个信号互相矛盾，结果是页面既可能不被收录，也可能按另一个地址收录。
- canonical 链。A 指向 B，B 又指向 C。链条越长越容易被忽略，最终按内容与链接信号自行判断。
- 指向重定向地址。canonical 应该写最终地址，让它再跳一次没有意义。
- 所有分页都指向第一页。如果第二页之后的内容独立可访问，粗暴合并可能让这些地址失去被发现的机会。
- 用 canonical 处理多语言或多地区版本。这类需求通常交给 hreflang，canonical 会把不同语言版本误判成重复内容。
它和哪些信号一起被判断
canonical 不是单独起作用的。抓取端还会看：站内链接用哪个地址、站点地图里列了哪个、重定向指向哪里、页面自身的内容与标题是否一致。这些信号方向一致时，判断结果比较稳定；互相矛盾时，系统往往按自己的逻辑选一个，未必是你声明的那一个。
- 导航和正文内链指向的地址
- sitemap 中登记的地址
- 301、302 的目标地址
- 页面标题、正文、结构化数据里的 URL
怎么确认声明有没有被采纳
- 在站点管理后台查看系统选择的规范网址，和自己声明的做对比。
- 抽查典型页面，确认抓取时的状态码与最终地址。
- 看服务器日志，重复地址是否还在被频繁抓取。
- 搜索几个页面的标题或片段，观察展示的地址是否向期望方向收敛。
发现不一致时，先别急着改 canonical。优先检查两个地址的内容是否真的等价、内链是否还在指向另一个版本、是否有其他标签在冲突。多数问题出在信号不一致，而不是标签本身写错。
动手之前先确认三件事
- 这些地址是否真的承载同一份内容。
- 哪个地址更适合作为长期入口：稳定、有内链、有外链。
- 这些页面是否需要分别被收录，比如不同规格、不同型号。
变更之后，保留旧地址可访问一段时间，给抓取和索引转换留出余量。canonical 能减少地址层面的重复，但它替代不了内容质量、内链结构和可访问性这些更基础的工作。