你在搜索结果里点开自己的页面，结果落地到了另一个 URL；或者在后台看到，自己指定的 A 版本做 canonical，Google 却把 B 版本收进了索引。这类情况在收录核对里很容易被当成“收录出错”，但多数时候，是索引在你给出的多个信号之间做了它自己的选择。
先分清：是收录的 URL 变了，还是只换了展示 URL
这两个问题处理方式完全不同，核对前先确认属于哪一种。
- 收录版本变化：索引里存的就是另一个 URL，原页面可能整个被合并过去。
- 展示 URL 变化：索引版本没变，只是结果页显示的链接换了一个，通常和地区、设备或查询词有关。
判断方法很简单：在站点的抓取日志里看 Googlebot 主要抓的是哪个版本，再对比索引报表里的状态。如果日志里目标版本一直在被抓，索引里却是另一个，那才是真正的 canonical 选择问题。
核对顺序：从页面内信号到站内信号
1. 页面上的 canonical 本身是否有效
- 同一个页面是否出现了多个 canonical 标签，互相打架。
- 写法是否稳定，是绝对地址还是相对地址，有没有在模板里被拼错成固定值。
- 指向的目标是否返回 200，而不是 301 链、404 或需要登录才能访问。
- 是否和 noindex 同时出现。两者共存时，信号是矛盾的，Google 往往按自己的判断走。
- 目标 URL 是否被 robots.txt 屏蔽，或本身带参数、大小写不一致。
2. 站内其他信号是否指向同一版本
canonical 只是众多信号之一。如果其他位置指向不同版本，Google 更可能采纳多数派。
- 内链：导航、面包屑、相关推荐里链接的是哪个版本。
- 站点地图：sitemap 里的 loc 是否和 canonical 一致。
- 重定向链：旧版本是 301 到 A 还是到 B，链条是否超过一跳。
- 多语言或分地区页面：hreflang 指向的版本是否和 canonical 冲突。
3. 是否存在其他可抓取的等价版本
- http 与 https、带 www 与不带 www 是否都能打开且返回 200。
- 大小写、结尾斜杠、index.html 这类差异是否各自可访问。
- 带跟踪参数（utm、ref、排序参数）的版本是否被内链或外链大量引用。
如果这些版本都能正常返回内容，等于同时给索引提供了多个候选，选择权就交出去了。
常见的几个触发条件
- canonical 指向的页面内容更少、加载更慢，或经常返回 5xx、超时。
- 两个版本内容差异很小，Google 判断合并更合适。
- 模板、CMS 或插件自动生成了 canonical，运营端并不知情。
- 页面经过多次改版，旧 canonical 残留，与新的设置冲突。
canonical 是提示，不是命令。站内信号越一致，Google 越没有理由自己另选一个。
处理顺序与观察节奏
- 先确认到底哪个版本在日志里被抓得最多，别急着改设置。
- 统一页面内 canonical、内链、sitemap 三处指向，让它们说同一件事。
- 如果两个页面确实应该合并，优先用 301，而不是只留一个 canonical 标签。
- 修改后观察目标版本是否被抓取正常，有无 5xx 或超时。
- 用索引核对工具查看“Google 选择的 canonical”，但注意它和实际索引之间存在滞后。
不要在信号还没统一前反复提交或频繁改动，那只会让抓取和索引更难判断哪个才是你想要的版本。
两个容易弄反的点
- 给错误版本加 noindex 又想靠 canonical 传递权重，两者同时存在时通常不会按你的预期执行。
- canonical 指向的那个页面本身设置了 noindex，等于把索引引向一个不允许收录的地址。
把这几步按顺序走完，多数“canonical 被改写”的情况都能定位到具体是哪一层信号没对齐，而不是笼统地归结为收录失败。