canonical 是给搜索引擎的提示，不是强制指令。你指定了 A 作为规范页，索引里却出现 B，这在带参数、多域名或历史遗留较多的站上很常见。与其纠结“为什么不听我的”，不如先确认这条提示有没有被读到，再判断它为什么更倾向另一个 URL。
第一步：确认 canonical 是否真的被读到
- 位置与生成方式：标签是否在 head 里；如果是脚本动态插入，抓取时可能还没生成，需要看渲染后的 HTML。
- 指向是否有效：href 是否为绝对地址，是否指向一个 301、404 或需要登录才能访问的页面。
- 规范页本身的状态：如果 A 被 robots.txt 挡住，或 A 自己带了 noindex，这条 canonical 基本不会生效。
- 是否出现多个：同一页写了两条互相冲突的 canonical，等于把判断权交回给爬虫。
第二步：看索引选代表页时还参考了什么
canonical 只是信号之一。内链指向、sitemap 里的出现情况、多个 URL 的内容相似度、URL 结构是否稳定、哪个地址更早被收录，都会影响最终结果。常见的一种情况是：canonical 指向 A，但全站内链和 sitemap 都指向 B，最后索引里留下的是 B。
第三步：按场景对号入座
带参数与被清理后的地址
筛选、排序、追踪参数会生成大量近似 URL。如果站内链接里参数顺序不统一，或者不同页面模块用了不同的参数写法，索引很容易选到一个你没预期的版本。做法是让内链统一指向无参数或参数固定的版本，其余入口用 301 收拢，而不是只在页面里写一条 canonical。
协议、子域与大小写
http 与 https、带 www 与不带 www、路径大小写不同，都可能被当作不同 URL。这类问题的重点不是补 canonical，而是从服务器层面把非规范版本 301 到规范版本，并检查 sitemap 和站内链接是否还有旧写法残留。
分页与聚合页
列表分页、标签聚合页、搜索结果页之间内容高度重叠时，索引可能选聚合页，也可能选其中某一页。先明确这类页面的取舍意向：需要留的就给它稳定的入口和唯一标题，不需要留的就挡在索引之外，避免留下模糊地带。
移动版与独立域名
PC 与移动端分属不同域名时，两边的 canonical 和互指关系要成对检查。只在一侧写规范，另一侧没有对应提示，容易让索引在两套地址间摇摆。
第四步：改动后的处理顺序
- 先统一站内信号：内链、sitemap、canonical 尽量指向同一个 URL。
- 再处理入口：不该被访问的重复地址用 301，而不是只靠页面内的提示。
- 确认规范页本身返回 200、可抓取、可索引。
- 记录改动时间，等一次完整的重新抓取后再核对索引中的实际 URL。
当内链、sitemap 和 canonical 各指一个方向时，爬虫只能自行判断，结果通常不会刚好等于你的预期。
别急着反复改
代表页的选择需要重新抓取和重新评估，短期内反复调整只会让信号更乱。比较稳的做法是：先记录当前索引里的实际 URL 和页面状态，改一次，给它一个抓取周期，再对照结果决定下一步。