canonical 标签的作用是告诉搜索引擎：这一组内容相近的 URL 里，哪一个是你认定的主版本。它是提示而不是强制指令，但会被认真参考。麻烦在于，canonical 通常由模板自动生成，规则一旦写错，就会在整站范围扩散，等到发现问题时，往往已经积累了大量被错误处理的地址。
常见的 canonical 错误
指向了会 301 跳转的旧地址
站点改版后，页面模板里的 canonical 还写着旧域名或旧路径，是很常见的情况。蜘蛛抓到新页面，看到 canonical 指向一个会跳转的地址，就得额外走一跳；有时它干脆按旧地址来理解，新 URL 迟迟得不到采纳。这类问题通常发生在迁移收尾阶段，迁移清单做完就没人再回头看模板。
分页页面全部指向第一页
关于分页的 canonical 写法，行业建议经历过调整。目前更稳妥的做法是让每个分页的 canonical 指向自身。如果整站的分页都指向第一页，第二页、第三页上的内容就很难被单独发现，尤其是那些只在分页里出现的条目。
模板批量输出错误
典型表现是所有页面的 canonical 都指向首页，或者所有文章页都指向所属栏目页。这类错误多半来自主题、插件或 CMS 的配置疏漏，肉眼看两三个页面不容易察觉，需要批量抓取后才能暴露出来。
canonical 与 hreflang 互相冲突
多语言站点里，canonical 应当指向同一语言版本的自身 URL，而不是把所有语言版本都指向英文主站。两个信号指向不同目标，搜索引擎需要自己判断，结果常常不是你预期的那个版本被保留。
指向被屏蔽或不存在的 URL
如果 canonical 的目标地址被 robots.txt 禁止抓取，或者本身已经返回 404，主版本信号就落空了。蜘蛛看不到目标页面，只能退回自行判断。写 canonical 之前，先确认目标能正常访问，是个容易忽略但很基本的前提。
一套可执行的自查流程
- 用爬虫工具批量抓一遍全站，导出所有 URL 及其 canonical 值，逐行与实际地址对比。
- 筛出 canonical 不等于自身 URL 的记录，按类型归类：大小写差异、末尾斜杠、http 与 https、带 www 与不带 www、参数差异。
- 抽查这些 canonical 目标的可访问性：是否返回 200，是否被 robots.txt 拦住，是否会再次跳转。
- 重点检查分页、筛选、排序、追踪参数这几类页面，看它们各自的规范处理是否符合预期。
- 回到模板层，确认主题、插件、CDN 的边缘规则里有没有二次改写 canonical 的逻辑。
几个容易被跳过的细节
- canonical 写成相对路径时，要注意基准地址。页面里的 base 标签会改变解析结果。
- 协议和主机名建议写完整，不要为了省字符而省略。
- 在大小写敏感的服务器上，/Page 和 /page 是两个不同的地址。
- 如果页面本身已经做了 301，canonical 的意义就不大，把 301 指对更重要。
- canonical 的目标页面最好能正常返回，并且内容确实是你想作为主版本的那一版。
把它变成维护习惯
把 canonical 的生成规则写进模板说明里，改动路由或 URL 结构时同步检查。每次站点改版、栏目调整、CMS 升级之后跑一遍对比，比事后从访问日志里倒推要省事得多。对中小站点来说，这一步花不了多少时间，却能避免大量重复地址长期堆积。
canonical 只是提示。如果它与页面内容、内部链接、Sitemap 中的地址互相矛盾，搜索引擎会自己选一个，而那个未必是你想要的。让这几处保持一致，往往比反复微调 canonical 更有效。
自查的目标不是追求某种完美格式，而是让站点对外表达的信号前后一致。一处写对不难，难的是几百上千个页面都写对，并且在下一次改版后依然写对。