canonical（规范标签）经常被当成让页面被收录的工具来用，但它实际做的是另一件事：在多个地址内容相同或高度相似时，告诉搜索引擎这几个地址里，哪个是你希望代表这一套内容的主地址。它影响的是索引如何选版本，既不是收录开关，也不决定抓取频率。
它解决的是版本选择的问题
同一个页面出现多个地址，来源很多：带跟踪参数、大小写不同、结尾斜杠有无、www 与非 www、列表页翻页、筛选条件组合等。这些地址内容基本一致时，搜索引擎需要挑一个放进索引，其余的可能被折叠。canonical 就是在这时候提供一个偏好，把索引位置集中到一版，避免同一套内容在索引里反复出现、彼此稀释。
但它是建议而不是命令。如果你指定的那一版本身质量差、返回错误、被 robots 屏蔽，或者指向关系自相矛盾，搜索引擎仍然可能按自己的判断选另一个版本。
三种常见写法
自引用：指向自己
最稳的写法是在每个页面的 head 里写一个指向当前页面自身的 canonical，地址用绝对地址。它不改变什么，但能减少参数、大小写之类的变体在抓取过程中被误判成另一套页面的机会，也方便统一站内地址格式。做自引用时，地址要和页面实际返回的最终地址一致，不要写成一个还要再跳一次的地址。
跨地址指向：多版指向主版
当确实存在多个变体、且你希望只保留一版时，才用跨地址指向。比如带参数的变体、打印版、按筛选生成的地址，都指回不带参数的主地址。前提是各版本内容确实相同；如果筛选后的内容实质不同，价格、库存、型号都不一样，硬指回主版反而会让这些有独立价值的页面收不进去。
不写
不写也有它的道理。功能页、站内搜索结果页、后台相关页面这类本来就不打算让索引保留的地址，用 noindex 处理更直接，不需要再用 canonical 绕一圈。
几组容易打架的组合
- canonical 与 noindex 同时出现：一个说保留这一版，一个说别收录我。两个信号方向相反，结果通常以 noindex 为准，被指向的地址也可能跟着受影响，这种写法要尽量避免。
- 指向的地址本身不干净：指向一个 404、一个重定向、一个被屏蔽的地址，等于让索引去选一个不存在或进不来的版本，判断只能由系统自己做。
- 一页出现多个 canonical：模板写了一个，CMS 又输出一个，或者 A 指向 B、B 指向 A 互相指，等于没给出明确答案。
- 用 JavaScript 写入：脚本执行不完整时，标签可能根本没出现在最终渲染结果里。能用服务端直接输出的，就别放在 JS 里生成。
- 指向还没收录的地址：以为 canonical 能把收录带过去是常见误区。收录要靠地址被成功抓取并被判断为合格页面，canonical 只是在判断过程中提供一个偏好。
和重定向、参数收敛的分工
页面已经废弃、内容搬到新地址，用 301 更合适，因为它把用户和抓取一起送过去。canonical 更适合两个地址都要保留、都能正常访问的场景，比如同一内容的两个展示路径。至于参数造成的地址扩散，优先在链接层面收敛，内链统一用干净地址，再配合规范参数处理，canonical 是补充手段，不是唯一手段。
上线后的自查清单
- 抽查几类模板页，查看源代码，确认 canonical 出现在 head 中，且写的是绝对地址。
- 把 canonical 指向的地址逐个打开，确认返回 200，不是重定向、不是错误页。
- 检查是否存在多个 canonical、是否存在 A、B 互相指向。
- 对照 robots 屏蔽规则和 noindex，确认没有方向冲突。
- 关掉脚本再看一次，或用抓取工具查看原始 HTML，确认标签不是靠 JS 才出现的。
- 记录修改时间，之后在服务器日志和索引状态里观察这批地址的变化，不要只看一两天。
把 canonical 当成整理地址顺序的建议书来用，比当成收录开关更容易得到预期结果。它做的是多个版本之间的取舍，取舍之外的事，还是得靠页面本身和地址规范来解决。
实际排查中，经常不是标签写错了，而是站点同时存在好几套地址、内链又不统一。先把地址收敛做干净，再回头看 canonical，往往能少绕不少弯。