canonical 是页面自己声明“哪个 URL 才是我希望被收录的版本”。它是一条建议，不是命令。很多站点把 canonical 当成重定向来用，结果就出现“声明指向 A，索引里却是 B”的情况。下面按声明、自选、冲突三个层面，把常见情形和排查方法理一遍。
canonical 能做什么，不能做什么
- 能表达偏好：告诉搜索引擎多个相似 URL 里你更希望哪一个被索引。
- 不是重定向：用户和爬虫仍然会访问原 URL，你只是希望索引归到另一个地址。
- 不是 noindex：它不阻止抓取，也不保证某个 URL 从索引里消失。
- 不等于必然生效：搜索引擎会结合内链、站点地图、内容相似度自己判断，与声明冲突时可能直接忽略。
最容易写错的几处
指向一个本身不能被收录的地址
例如 canonical 指向的页面被 noindex、返回 404 或 410，或者被 robots.txt 挡住。这种情况下声明基本无法执行，搜索引擎会自己挑一个版本。
目标页自己也 canonical 到别处
A 指向 B，B 又指向 C，或者 B 指回 A 形成环。链条越长越绕，越容易被判定为不可信。
分页、筛选、排序参数互相指
列表页第 2、3 页都 canonical 到第 1 页，可能连带把后续页上独有的内容一起忽略。带筛选参数的页面如果不是同一批内容，硬指到无参数版本，往往是白指。
模板复制后忘了改
批量生成页面时，canonical 里写死了某个固定 URL，或者相对路径拼接出错，最后全站都指向首页。抓几个 URL 的源码就能发现这类问题。
冲突时怎么排查
- 抓取原页面的 HTML，先看服务端返回的内容，确认 canonical 的实际值，注意协议、域名、结尾斜杠是否与你以为的一致。
- 访问目标 URL，确认它返回 200，没有被 robots.txt 挡住，也没有 noindex。
- 看目标页自己的 canonical 指向哪，避免出现环或断点。
- 在索引数据或搜索结果中，看实际被选中的是哪一个版本。
- 把内链、站点地图、canonical 三处统一指向同一个首选 URL，信号一致比单点声明更有用。
什么时候不该用 canonical
如果两个页面的主体内容确实不同，比如不同商品、不同城市的服务页，硬把它们指到同一个 URL，不会帮你集中权重，反而可能让其中一个长期进不了索引。canonical 适合处理同一份内容的不同 URL 版本，不适合用来合并内容不同的页面。
改完之后怎么观察
调整不会立刻反映在索引里，通常要等下一轮抓取。可以观察抓取日志里首选 URL 的访问是否增加、原 URL 的出现是否减少，以及索引中保留的版本是否与预期一致。如果几周后还是相反，优先回头检查上面那几处冲突，而不是反复修改声明。
把 canonical 当成一种一致的表达，而不是开关。它起作用的前提是，你的内链、站点地图和其他信号说的是同一件事。