同一个页面被搜索引擎用多个地址抓到，是站点运营里很常见、又容易被忽略的问题。它不一定立刻带来麻烦，但会让抓取、去重、统计都变得不确定：流量分散在几个 URL 上，改动某个地址之后效果也难判断。canonical 是处理这类问题的常用手段，但它不是写上就好，写得不对反而会传递错误信号。
先找出站点里有哪些重复地址
- 带参数的地址：utm 系列、排序、筛选、每页条数、会话 ID 等，内容一致也会被当成不同 URL。
- 大小写与尾斜线差异：/Page 与 /page、/a 与 /a/，在多数服务器上会被当作两个地址。
- 协议与主机名差异：http 与 https、带 www 与不带 www 同时可以访问。
- 移动版或独立版本：m 子域、独立移动域名与主站内容一致。
- 功能性副本：打印页、纯文本版、AMP 版、PDF 导出页。
- 跨站同步发布：同一篇内容先在自有站发布，再同步到其它平台，或反过来。
这几类地址如果长期并存，就会形成事实上的重复内容，用户可能从任意一个进去，蜘蛛也可能按不同地址分别抓取。
canonical 常见的几种写错方式
指向了一个打不开的地址
canonical 的目标应当是 200 状态、可以正常访问的规范页。如果它指向的地址会 301、404，或者被 robots.txt 屏蔽，搜索引擎无法确认你指的那个页面，这条 canonical 基本等于没写，副本仍可能按原地址处理。
多个地址互相指
A 页 canonical 指向 B，B 又指向 C，或者 A 和 B 互指，形成链或环。这类情况多出现在改版、迁移没有清理干净的时候。建议把最终规范页定下来，让所有副本都直接指向它，而不是层层转指。
模板里硬编码同一个 canonical
列表页、分页、筛选结果页、详情页如果共用同一个模板，很容易把 canonical 写死成栏目首页或第一页的地址。结果是大量不同内容的页面都在声明自己不是正本。更稳妥的做法是让 canonical 由页面自身地址生成，或按页面类型分别配置。
canonical 与其他设置的冲突
- 同时写 noindex 和 canonical：noindex 通常优先，页面不参与索引，canonical 的作用也就无从体现，两者并用要先想清楚目的。
- 被 robots.txt 屏蔽的页面：屏蔽之后搜索引擎拿不到页面内容，也就读不到 canonical，副本依然存在但不被处理。
- 分页：把第 2 页及以后都 canonical 到第 1 页，需要确认这些内容是否真的可以合并。如果每页是不同的商品或文章列表，直接合并可能损失入口。
- 多语言：各语言版本之间用 hreflang 互指，各自 canonical 到自身；不要把它们互相 canonical，否则语言版本会被合并到一处。
- 协议与主机：先在服务器层面把 http 跳 https、把 www 统一，再用 canonical 兜底，比只依赖 canonical 更稳。
一次可执行的自查流程
- 从服务器日志或抓取记录里按内容聚类，看同一个页面是否对应多个 URL。
- 挑出流量较高、被外链引用较多的页面，逐个查看实际被访问的地址。
- 打开页面源码，确认 canonical 是否存在、是否指向自身或明确的规范页、目标地址是否正常返回。
- 抽查模板生成的页面：列表页、分页、筛选结果页、详情页各取几个。
- 检查 http 与 https、www 与非 www、大小写、尾斜线，确认服务器层面的统一规则已经生效。
- 改完后记下修改时间，隔一段时间回看抓取与索引状态的变化，不要指望当天就见效。
canonical 是一种声明，不是命令。它降低歧义，但不会替你解决服务器配置、内容重复和内部链接混乱的问题。先把地址统一做好，再让它做收尾。
建议的维护节奏
把 canonical 检查放进栏目上线和内容改版的流程里，比事后成批排查省事。新增页面时确认模板输出的地址正确，改版或换域名时整理一份地址对照表，避免新旧地址长期并行。对于带参数的筛选页，可以提前约定哪些参数允许被抓取、哪些在服务器层面直接重定向到干净地址，减少后续的清理成本。