很多站点在发现同一内容有多个 URL 时，第一反应是加 canonical，指向主版本，然后等待收录归拢。canonical 确实有用，但它只是一个提示，搜索引擎会结合重定向、内链、sitemap、hreflang 等信号一起判断。指定之后不核对，容易出现指定了却不算数的情况。
先分清：哪些页面适合用 canonical
canonical 主要解决同一份内容出现在多个 URL 的问题，而不是处理内容不同的页面。常见场景包括：
- 带跟踪参数、排序参数、会话参数的 URL；
- 打印版、纯文本版、AMP 版等同一内容的变体；
- 商品筛选后生成的列表页，与主列表页内容高度接近；
- HTTP 与 HTTPS、带 www 与不带 www 同时可访问；
- 分页中的单页被独立访问，但内容主体仍属于列表。
如果两个页面主题不同、正文不同，硬用 canonical 合并，可能让其中一个页面失去被单独评估的机会。判断标准不是像不像，而是用户看到的内容是否基本一致。
指定 canonical 之后，先核对这五处
1. 自引用是否正常
每个规范页面最好有一条指向自己的 canonical。如果主版本页面没有自引用，而其他变体都指向它，信号会显得不完整。自引用地址要和页面实际访问地址一致，包括协议和域名。
2. 目标地址是否可达
canonical 指向的页面如果返回 404、500，或被 robots.txt 屏蔽，或被 noindex 标记，这个提示就难以成立。目标页面应当是 200 状态、可抓取、可索引的规范版本。
3. 是否与重定向冲突
如果 A 页面 canonical 指向 B，同时 A 又 301 到 C，信号就乱了。一般来说，能重定向就重定向，不能重定向再用 canonical。两者同时使用且指向不同地址，容易让收录归属摇摆。
4. 是否与 hreflang、sitemap 一致
多语言站点要特别注意：canonical 不能跨语言版本乱指。每个语言版本通常应自引用，或用 hreflang 表达对应关系。sitemap 里提交的 URL 也最好与 canonical 保持一致，减少相互矛盾。
5. 是否由 JS 后插入
如果 canonical 由 JavaScript 动态写入，需要确认搜索引擎渲染后能否稳定看到。更稳妥的做法是让服务端直接输出，至少在关键页面如此。
收录归属看起来不对，排查顺序
发现搜索结果显示的是另一个 URL，或者主版本迟迟没有出现时，可以按这个顺序看：
- 确认是否真的重复。先对比标题、正文、主要模块。如果内容差异明显，可能不是 canonical 能解决的问题。
- 检查内部链接指向谁。站内链接、导航、面包屑大量指向变体 URL，会削弱 canonical 的效果。
- 检查抓取记录。看服务器日志里两个 URL 的抓取频率和响应状态，判断蜘蛛是否正常拿到页面。
- 检查其他信号。sitemap、结构化数据、外链、分享链接是否指向了非规范版本。
- 小批量调整后观察。不要一次性大改全站 canonical，先处理一个栏目或一组页面，观察几周再扩大。
canonical 是建议，不是开关。它帮助搜索引擎理解你的偏好，但最终收录哪个 URL，仍取决于多重信号和页面本身的质量。
几个容易踩的坑
- 全站 canonical 统一指向首页，导致内页无法被单独收录；
- 分页页面全部 canonical 到第一页，用户翻到第 5 页却看到第 1 页的标题；
- canonical 指向的页面本身被 noindex，形成矛盾；
- 同一页面在不同模板里输出不同 canonical，今天指 A 明天指 B；
- 把 canonical 当成去重万能药，忽略了内容重复的根源。
更实际的做法是：先确定站点希望哪个 URL 作为主版本，然后让内链、sitemap、重定向、canonical 尽量指向同一个地址。定期抽查几个重要栏目，看搜索结果里出现的 URL 是否符合预期，比一次性配置完就放着更有效。