写错<link rel="canonical">比不写更危险，它是给搜索引擎的明确指令而非开关；必须唯一置于<head>中、用绝对URL、过滤干扰参数但保留分页，且严禁与noindex或301混用。
写错 <link rel="canonical"> 比不写更危险——它不是开关，是给搜索引擎的明确指令；信号一错，内页权重可能被清零。
canonical 标签必须放在 <head> 里且只能有一个
搜索引擎只解析 HTML 初始源码的 <head> 区域，不会执行 JS，也不看 <body> 里的内容。你用 document.head.appendChild() 动态插入，或者把标签塞进 <body> 开头，Google 就当它不存在。
- 检查最终 HTML 源码（右键 → “查看网页源代码”），搜索
rel="canonical"，确认它唯一、闭合、且在<head>内 - CMS 或多插件主题容易重复注入——比如 SEO 插件 + 主题模板各写一个，结果页面出现两个
<link rel="canonical">，Google 可能直接忽略整条 - SSR/SSG 场景下，模板中写死了一个 URL，但实际路由变了（如 Next.js 里用了
route.fullPath而不是route.path），也会导致 canonical 指向错误页面
href 必须是绝对 URL，协议/域名/路径缺一不可
相对路径如 /article/123 或协议相对路径如 //example.com/article 都会因上下文不同被解析成错误地址：HTTP 页面里变成 http://，HTTPS 页面里变成 https://，CDN 回源时还可能指向错误源站。
- 正确写法只有这一种：
<link rel="canonical" href="https://www.example.com/article/123"> -
https://不能省，www.和非www.是两个不同规范域，选一个并全站统一 - 路径末尾斜杠必须和目标页面真实返回的 URL 一致：
/article/≠/article，否则返回 404 或跳转都会让 canonical 失效 - PHP 中推荐用
parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH)提取路径，再拼上$_SERVER['HTTP_HOST']
动态页面中怎么安全过滤 query 参数
核心判断标准：参数是否改变页面主体内容？干扰型参数（如 ?utm_source、?ref、?sort）要剔除；语义型参数（如 ?page=2、?q=foo）通常应保留——第 2 页不是第 1 页的副本，它有独立索引价值。
立即学习“前端免费学习笔记（深入）”；
- 电商商品页访问
/product?id=123&utm_source=email，canonical 应指向/product/123（无参标准路径） - 博客列表页访问
/blog?page=2，canonical 必须指向自身https://example.com/blog?page=2，绝不能指向/blog - Next.js 中别直接用
router.asPath，应在自定义 hook 里手动剔除 tracking 类 query 参数 - Nuxt 3 别用
route.fullPath（含 query），改用route.path构造href值
canonical 不是重定向，别和 noindex 或 301 混用
它只是给搜索引擎的建议，不是强制指令，更不改变用户访问行为。混用会直接冲突失效：
- 在已加
noindex的页面上设置 canonical，逻辑矛盾，搜索引擎可能忽略整条 - 对已 301 跳转的页面再设 canonical 指向跳转前的地址，信号混乱，Google 可能拒绝采纳
- 如果两个 URL 完全等价、且长期只需保留一个（比如旧版已下线），优先用 301 重定向，权重传递更完整
- 如果需共存（如 PC 页与 AMP 页），则用 canonical 标明主从关系
最容易被忽略的是：canonical 的值是否随当前请求动态生成，而不是模板里硬编码的静态字符串——哪怕只错一个斜杠或协议，就等于把权重主动交给错误页面。
