本文约 3,527 字，预计阅读 9 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：canonical 写了，Google 却不认
一个站点把带参数的 URL 全部 canonical 到纯净版本，配置看起来毫无问题。但 GSC 的 URL 检查工具里，userCanonical 是纯净版，googleCanonical 却是带参数的版本——Google 明确告诉你：“我不采纳你的声明。”
canonical 的本质是建议（hint），不是指令。Google 会综合 canonical 声明、内部链接指向、sitemap 中的 URL、内容相似度、以及 HTTP/HTTPS 与 www 的一致性来自行选择规范网址。当这些信号互相矛盾时，Google 会忽略你的声明。所以 canonical 出问题，八成不是标签本身写错了，而是站内其他信号在跟它打架。
原理分析：Google 选择规范网址的五个信号
| 信号 | 权重 | 常见冲突 |
|---|---|---|
| rel=canonical 声明 | 高（但可被覆盖） | 声明目标与内容不符 |
| 内部链接主要指向哪个版本 | 高 | 站内链接混用带参数版本 |
| sitemap 中包含哪个版本 | 中 | sitemap 放了非规范 URL |
| 301 重定向 | 最高 | 有 301 时 canonical 无意义 |
| URL 形式一致性（https/www/尾斜杠） | 中 | 站内混用两种形式 |
关于几条常见规则的澄清：
自引用 canonical 是推荐做法。 每个可索引的页面都应该有一个指向自己的 canonical，即使不存在重复问题。这不是废话——它能防止参数污染产生的新 URL 抢走规范化判定。
canonical 不等于 301。 301 是服务器级跳转，会传递信号且只保留一个 URL；canonical 是页面级声明，两个 URL 都仍然存在、都可访问。想真正合并 URL 用 301，只是提示优先级用 canonical。
分页页面的 canonical 应该自引用。 Google 早已不支持“把所有分页 canonical 到第 1 页”的旧做法——那样会导致第 2 页之后的内容无法被发现。正确做法是每页自引用，同时保留真实的分页链接关系。
跨域 canonical 是被支持的，但只在内容确实是完全转载（如授权转载、多站点同步发布）时使用，且要求两个域名间有明确信任关系。滥用会被忽略。
canonical 必须指向返回 200 的页面。 指向 404、重定向链或 robots 屏蔽的 URL，等于没有声明。
保姆级实操
步骤 1：先统一 URL 形式。 确定 https + www（或去 www）+ 是否带尾斜杠，然后在服务器层用 301 强制统一。这一步做完，一半的重复问题自动消失。
步骤 2：确认每个页面都有自引用 canonical。 WordPress 核心会自动输出（由 wp_head 中的 rel_canonical 动作完成），SEO 插件（Yoast、Rank Math）会接管它。不要同时启用多个插件输出，否则页面上会出现两个 canonical 标签，Google 遇到多个冲突声明时会全部忽略。
步骤 3：需要定制时用官方过滤器，而不是再加一个标签。 WordPress 提供了 get_canonical_url 过滤器，这是修改 canonical 唯一正确的入口：
// 正确做法：用 get_canonical_url 过滤器改 canonical，不要自己 echo 一个 <link>
add_filter( 'get_canonical_url', function ( $canonical_url, $post ) {
// 1) 去掉 utm 等追踪参数
$parts = wp_parse_url( $canonical_url );
if ( ! empty( $parts['query'] ) ) {
parse_str( $parts['query'], $args );
$args = array_diff_key( $args, array_flip( [
'utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid',
] ) );
$canonical_url = $parts['scheme'] . '://' . $parts['host'] . ( $parts['path'] ?? '/' );
if ( $args ) {
$canonical_url .= '?' . http_build_query( $args );
}
}
// 2) 特定类型归一：把 /product/xxx/variant/ 归一到 /product/xxx/
if ( $post && 'product' === $post->post_type ) {
$canonical_url = preg_replace( '#/variant/\d+/?$#', '/', $canonical_url );
}
return $canonical_url;
}, 10, 2 );
// 错误示范（不要这样做）：会输出第二个 canonical，导致冲突
// add_action( 'wp_head', function () { echo '<link rel="canonical" href="..." />'; } );
步骤 4：清理内部链接。 用 SQL 或脚本在数据库里查找正文和菜单中使用了非规范形式（带参数、http、非 www）的内部链接，统一替换。这一步最容易被忽略，却直接决定 Google 选择哪个版本。
步骤 5：修正 sitemap。 确保 sitemap 里只有规范 URL。sitemap 中出现非规范 URL，是 Google 忽略 canonical 声明的常见原因。
步骤 6：用 URL 检查工具核对。 输入问题 URL，对比 userCanonical 与 googleCanonical。两者不一致时，按顺序排查：内部链接指向 → sitemap 内容 → 301 配置 → 内容相似度。
步骤 7：处理真正重复的页面。 对内容几乎一致的页面，canonical 只是治标。治本是把它们 301 到规范页或下线，这与 Google 对重复内容的处理机制 讲的是同一件事。
常见踩坑
- 多个插件输出多个 canonical。 Google 遇到冲突会全部忽略，等于没写。
- 分页页 canonical 指向第 1 页。 导致后续页内容无法被发现。
- canonical 指向 404 或被重定向的 URL。 声明无效。
- canonical 指向了内容明显不同的页面。 这种“作弊式归一”会被直接忽略。
- 只写 canonical 不清理内部链接。 Google 通常听链接的，不听标签的。
- 跨域 canonical 滥用。 没有信任关系时一律被忽略。
- 案例： 一个站点用 SEO 插件给全站文章统一设置了 canonical，但站内的“相关文章”模块用的是带
?utm_source=related的链接，导航菜单用的是http://版本。结果 Google 选择的规范网址既不是插件声明的版本，也不是站长期望的版本，而是带 utm 参数的形式。把内部链接全部改为纯净 https 规范 URL 后，两周内googleCanonical与userCanonical达成一致。站内链接信号比 canonical 标签更强势。
总结
canonical 的正确用法可以概括成五条：每个可索引页面自引用、声明目标必须 200、站内链接与 sitemap 必须与声明一致、分页自引用、真正要合并时用 301 而不是 canonical。判断配置是否成功，只看 URL 检查工具里 userCanonical 与 googleCanonical 是否一致——不一致时，不要反复改标签，去查内部链接和 sitemap，那才是真正决定结果的地方。
