canonical标签不传递全部权重，仅作为搜索引擎的索引优先建议；它适用于需共存的重复页面（如pc/amp页），而301重定向用于永久废弃旧url；错误实现（如相对路径、分页误指首页）会导致权重流失。
canonical 标签本身不传递全部权重，它只是告诉搜索引擎“该优先索引谁”，但不会像 301 那样近乎完整地转移链接权重。 它是协调重复页面的首选手段，不是权重搬运工。
canonical 标签对 SEO 权重的实际影响
Google 明确表示 canonical 是一个“强烈建议”，不是指令。它主要影响索引选择和排名归属，而非直接、全额传递 PageRank 或链接信号：
- 被 canonical 指向的规范页，更可能获得来自重复页的排名展示权和部分链接权重（但弱于 301）
- 未被 canonical 指向的副本页，仍可能被爬取、缓存甚至偶尔出现在搜索结果中（尤其当内容有微小差异或规范页质量偏低时）
- 如果多个页面互相 canonical（A→B，B→A），或指向 404/重定向链末端以外的 URL，Google 会忽略整个 canonical 信号，退回原始抓取逻辑
什么时候该用 canonical 而不是 301？
关键判断点在于「用户是否需要同时访问这两个 URL」：
- 需要共存 → 用
canonical：比如 PC 页https://example.com/article/123和 AMP 页https://example.com/article/123/amp，两者都应可访问，但主索引归 PC 页 - 永久废弃 → 用
301：比如旧路径http://example.com/blog?id=456已停用，所有流量和权重应彻底迁移到新静态路径https://example.com/posts/456 - 参数干扰但内容一致 → 用
canonical：如/product?ref=fb&sort=price和/product内容完全一样，canonical 指向后者即可
动态页面生成 canonical 的常见坑
服务端模板或框架里拼 href 时，最容易因变量来源或路径处理出错：
- 用
window.location.href或前端路由对象（如 Next.js 的route.fullPath）生成 canonical —— 爬虫看不到 JS 执行结果，且用户端 URL 可能含干扰参数 - 漏协议或域名：写成
/article/123或//example.com/article/123，导致解析为 HTTP 地址或 CDN 域名，违反绝对 URL 要求 - 分页页误指首页：如
/blog?page=3的 canonical 指向/blog，Google 会认为第 3 页无独立价值，降低其索引优先级 - 在
noindex页面上仍加 canonical —— 逻辑冲突，Google 很可能直接忽略 canonical
验证 canonical 是否生效的关键动作
上线后不能只看源码有没有标签，得确认搜索引擎实际怎么理解它：
- 用 Google Search Console 的「URL 检查」工具输入副本页 URL，查看「规范网址」字段是否显示你预期的地址
- 检查规范页是否返回
200状态码，且内容与副本页主体一致（注意：细微差异如广告位、时间戳不影响 canonical 生效） - 避免在 Nginx/Apache 里用 rewrite 替代 canonical —— rewrite 改的是用户看到的 URL，不解决爬虫已抓到多个参数 URL 的问题
真正难的不是加一行 <link rel="canonical">，而是确保全站所有动态出口（CMS、SSG、API 渲染层）输出的 href 值，在任何参数组合、任何设备请求下，都稳定、准确、自洽。稍有松动，就可能让几十个页面的权重悄悄流失到错误地址上。
