canonical 是建议，不是命令
很多站点在页面里写了 canonical，指向自己认为的规范版本，但索引报告里显示的却是另一个 URL。这不是标签写错了，而是搜索引擎在综合站内信号、外链和抓取历史后，自己选了一个它认为更合适的版本。理解这一点，排查时就不会只盯着那一行代码。
先确认两件事：你声明了什么，索引实际选了什么
在索引报告或 URL 检查工具里，通常会看到「用户声明的规范网址」和「Google 选择的规范网址」两个字段。前者是你通过 canonical、sitemap、hreflang 等给出的信号，后者是索引实际采用的版本。两者不一致时，问题往往出在信号冲突或页面质量判断上。
常见原因一：站内信号互相打架
同一个内容被多个 URL 承载时，如果各处给出的规范指向不同，索引系统会倾向于忽略你的声明。常见冲突包括：
- 页面 canonical 指向 A，sitemap 里提交的是 B。
- 内链大量指向 B，canonical 却指向 A。
- hreflang 指向 C，canonical 又指向 A。
- 旧 URL 通过 301 跳到新 URL，但新 URL 的 canonical 又指回旧 URL。
站内信号不一致时，先统一再谈收录。
常见原因二：重复内容太接近，索引自己挑了一个
如果 A、B 两个页面正文几乎相同，canonical 指向 A，但 B 有更多外链、更早被收录、抓取更频繁，索引可能选择 B。这不是 canonical 失效，而是重复内容治理没做到位。把两个版本真正合并、只保留一个可访问 URL，比反复改 canonical 更有效。
常见原因三：canonical 链、循环和跨域问题
canonical 可以形成链：A 指向 B，B 指向 C。索引通常会跟随到最终页，但如果链条中有页面不可抓取、返回错误或被 robots 屏蔽，跟随就会中断。跨域 canonical 也需要目标页可访问、内容确实一致，否则索引不会采纳。
常见原因四：技术细节让声明读不到或失效
- canonical 只写在 JS 渲染后的 DOM 里，首次 HTML 中没有。
- URL 大小写、参数顺序、末尾斜杠不一致，被当成不同页面。
- canonical 目标页返回 404、301 或 noindex。
- 页面本身被 robots.txt 屏蔽，抓取不到就无法读取声明。
按顺序排查的四个步骤
- 抓取实际 HTML：用抓取工具查看服务器返回的原始 HTML，确认 canonical 是否存在、是否被 JS 注入。
- 对比站内信号：把 canonical、sitemap、内链、hreflang、301 规则列在一起，看是否指向同一个 URL。
- 检查外链与抓取历史：看被索引选中的版本是否有外部链接或更早的收录记录。
- 核对索引报告：查看「用户声明的规范网址」与「Google 选择的规范网址」，判断差异是信号问题还是内容问题。
修正后的预期与注意事项
统一站内信号后，索引重新选择规范版本需要时间，通常要等页面被重新抓取和重新评估。不要频繁修改 canonical 指向，也不要在多个版本之间反复切换，否则会延长索引稳定的周期。
canonical 更像一次内部投票，站内所有入口投给同一个 URL，比单独写一个标签更有分量。
如果多个版本内容确实不同，先决定保留哪一个，再处理重复版本。收录和索引选择受多种因素影响，本文只提供排查顺序，不承诺具体收录结果或排名变化。