做站点运营时，canonical 标签常被当成“写了就一定生效”的开关。实际它不是强制指令，而是一种明确表态：告诉搜索引擎“这一组页面里，我认为哪个是主版本”。搜索引擎会参考这个表态，但也会结合内链、sitemap、跳转、内容本身等因素综合判断。所以“写了 canonical 却没生效”这件事，更接近一次信号冲突，而不是标签失效。
第一步：先确认标签本身没写错
很多问题卡在最基础的地方，检查一遍成本很低，但能排除掉大半干扰。
- 建议使用绝对 URL，带上协议和域名，路径写完整。相对路径虽然常被识别，但在跨目录、多域名环境下容易出偏差。
- 标签放在 <head> 内，不要写在 body 里。文档中途出现的 canonical 容易被忽略。
- 一个页面只保留一个 canonical。重复输出多个时，常见结果是全部不采纳，或者采纳了和你预期不同的那个。
- 不要把 canonical 指向 404、410、重定向链中间页，或者本身带 noindex 的页面。目标页无效，等于这个表态作废。
- 规范页建议做自引用，即自己 canonical 到自己。这能减少“到底谁才是主版本”的歧义。
第二步：看是不是被其他信号顶掉了
当多个信号指向不同结果时，搜索引擎只能自己选一个。常见冲突有这几类：
hreflang 与 canonical 互相打架
多语言站点里，如果语言版本之间互相 canonical，等于在说“只要一个语言版本就够了”，这通常不是你的本意。语言版本之间应该用 hreflang 关联，canonical 指向各自语言内的规范页。
sitemap 和 canonical 不一致
sitemap 里同时列出了参数页和规范页，内链又大量指向参数页，只有 canonical 一个信号说“去规范页”。这种少数服从多数的局面下，不被采纳很正常。
页面被 noindex 或 robots.txt 屏蔽
如果规范页本身被屏蔽抓取或标记 noindex，canonical 指向它就失去了意义。反过来，重复页被 noindex 时，canonical 通常也不再需要。
第三步：判断内容差异是不是太大了
canonical 适合处理“同一内容的不同 URL 形态”，比如排序参数、跟踪参数、大小写差异、打印页等等。它的前提是主体内容基本一致。
如果两个页面只是套了同一个模板，正文、商品信息、评论完全不同，硬做 canonical 指向其中一个，往往会被判定为建议不合理。这种情况更该考虑的是：它们本来就是两个页面，还是应该合并成一个页面。
第四步：确认搜索引擎实际看到的是哪个版本
页面在浏览器里显示正常，不代表抓取时看到的也是同一份 HTML。
- 如果是 JS 渲染的站点，检查渲染完成后的 DOM 里 canonical 是否被脚本改写或覆盖。
- 检查是否存在 A/B 测试、多套模板、CDN 边缘改写，导致同一 URL 返回不同的 head 内容。
- 移动端与桌面端分别查看，确认两边的 canonical 指向一致，不要各自指回自己。
- 用带 UA 的抓取工具或日志回放，看返回的原始 HTML，而不是渲染后的结果。
一个可执行的排查顺序
- 查看原始 HTML，确认 canonical 存在、唯一、在 head 内、是绝对 URL。
- 确认目标页返回 200，且自身没有 noindex、没有被 robots.txt 屏蔽。
- 对照 sitemap、内链、跳转、hreflang，看是否有信号指向另一个 URL。
- 比较两个页面的主体内容，判断差异是否已经超出“同一内容”的范围。
- 确认抓取时返回的 head 与浏览器所见一致，排除脚本改写和边缘改写。
- 看搜索引擎最终选择的规范 URL 是哪个，再决定是调整信号，还是改用跳转合并。
如果确实不生效，可以怎么兜底
当信号长期无法统一，或者两个 URL 本来就不该同时存在时，可以考虑更直接的手段：
- 用 301 永久跳转把重复 URL 真正合并到一个地址上，这是最强的一种表态。
- 统一站内链接，让导航、面包屑、列表页、相关推荐都指向规范版本。
- sitemap 只保留规范 URL，减少把重复版本送进发现队列。
- 从源头减少重复，比如统一参数规则、统一大小写与末尾斜杠规则。
canonical 解决的是“同一内容有多个入口”这类问题，解决不了“内容本身要不要合并”。把这两件事分开看，排查会清楚很多。
最后提醒一句：规范化的目标是让搜索引擎更容易理解你的站点结构，而不是保证某个 URL 一定会出现在索引里。判断是否生效，重点看结果是否收敛、是否稳定，而不必纠结某一天的查询结果。