做重复内容收口时，很多站点会在一组相似 URL 上都加上 canonical，指向自己认为的正版页面。过一段时间查索引，却发现被保留的是原来那一版，canonical 指向的页面迟迟没进索引，甚至搜索结果里的展示地址换成了另一个 URL。这不一定是你标签写错了，而是要先弄清 canonical 的定位。
canonical 是提示，不是强制指令
canonical 的作用是告诉搜索引擎：这一组页面里，我认为哪一个是主版本。它是一个信号，用来帮助合并重复内容、集中站内权重，但最终保留哪个地址进入索引，由搜索系统综合判断。它多数情况下会被采纳，也可能被忽略。
所以“写了 canonical，主版本就一定会被收录”这个前提本身不成立。更现实的目标是：让系统更容易判断哪一版是规范的，减少同一份内容被拆成多个索引项。
索引挑页面时会参考哪些信号
- 内容完整度：正文、图片、结构化数据更全的那一版，通常更容易被保留。
- URL 结构：简短、层级清晰、参数干净的地址往往更占优势。
- 内链与导航：站内链接更集中指向的那一版，被判断为主版本的几率更高。
- 站点地图：sitemap 里只放主版本，属于一致性上的加分项。
- 访问稳定性：长期可用、响应正常的地址，比时开时关的地址更可靠。
- 历史信号：已经被抓取、被外部链接过一段时间的地址，往往不容易被替换掉。
声明了却没生效的常见情况
- canonical 指向的页面本身返回错误码，或被 robots.txt 挡住、带有 noindex。
- 一组页面互相 canonical，或者 A 指向 B、B 又指回 A，信号自相矛盾。
- canonical 用的是相对路径，或带着参数，和实际 URL 对不上。
- 正文靠 JavaScript 渲染，抓取阶段拿到的 HTML 里 canonical 位置是空的。
- 主版本页面上没有内链入口，站内几乎没人指向它。
- 移动版和桌面版分别声明了不同的规范页。
排查顺序建议
- 先看被抓取的 HTML 源码，确认 canonical 是否真的出现在里面，而不是渲染之后才出现。
- 确认目标 URL 能正常打开、返回 200，且没有被 robots 规则或 noindex 排除。
- 核对 canonical 的写法与目标 URL 是否完全一致：协议、域名、大小写、末尾斜杠、参数。
- 检查这一组页面之间有没有互相指向、循环指向。
- 看内链和 sitemap 的指向是否和 canonical 保持一致。
- 以上都正常时，先观察几周，不要频繁改动标签。
该做与不该做
该做的是把一套信号统一起来：canonical、内链、sitemap、分页处理都指向同一个地址，并保证这个地址本身内容完整、能稳定访问。不该做的是把 canonical 当成收录开关，在几个 URL 之间来回切换，或者每个页面都写一句“此页为主版本”，让信号变得混乱。
判断标准很简单：如果连你自己都说不清哪个地址是主版本，搜索系统更难替你决定。先把主版本定下来，再让所有信号都指向它。
小结
canonical 能减少重复内容带来的困扰，但它既不保证主版本一定进索引，也不保证索引里只剩一个地址。把它理解为一份一致性声明，而不是收录开关，排查思路会清晰很多：先确认信号是否真实存在、是否彼此一致，再谈效果。