canonical 想解决的是什么问题
同一个内容经常长出好几个 URL：商品页带筛选参数、文章页带追踪参数、列表页有排序参数、旧路径还留着 301。这时页面可以自己声明一个“规范版本”，也就是 canonical，作用是告诉搜索引擎：在这一组地址里，我希望你把它当成同一个页面来处理。
但要说清楚，它只是建议，不是命令。搜索引擎会综合内链、外链、sitemap、页面之间的相似度来判断哪一版更该留下，canonical 只是其中比较重要的一个信号。写对了能减少干扰，写错了也可能把本来该独立的页面合并掉。
三种常见的 canonical 用法
自引用：自己指向自己
大多数正常页面都应该这样做。缺少 canonical，或者模板里把 canonical 写死成首页地址，是最常见的批量事故。尤其是复用同一套模板、靠变量拼 URL 的站点，上线前最好抽几个页面看源码确认。
同站多版本合并
带追踪参数、排序参数、打印版的页面，可以 canonical 到不带参数的原始地址。前提是两个版本内容确实一样。如果内容有明显差别，比如筛选后只剩少量商品，硬合并反而会让这些页面失去被单独看待的机会。
跨域 canonical
多个域名发布同一篇内容时，可以用 canonical 指向主站。它能表达意图，但跨域的信号强度比同站弱，搜索引擎仍会参考各站自身的权重、链接和访问情况，不能指望一句声明就完成合并。
容易写错的几种情况
- canonical 指向一个 301 或 404 的地址。最好直接指向最终可访问的 URL，少一层跳转。
- canonical 和 noindex 同时出现。两者目的相反，容易得到模糊结果，通常只保留一个。
- 形成链条或环：A 指向 B，B 指向 C，或者互相指。链条越长信号越弱，最好一步到位指向最终版本。
- 分页页全部 canonical 到第一页。这样第 2 页之后的页面基本不会被单独看待，如果它们有独立价值，需要重新考虑。
- canonical 与 sitemap、内链给出的首选版本互相矛盾。几路信号打架时，结果往往不稳定。
- HTML 里写了一个 canonical，脚本渲染后又改成另一个。搜索引擎可能只看到其中一个，最好由服务端直接输出，保持前后一致。
自查时按这个顺序看
- 打开页面源码，确认 canonical 里的地址能正常访问，返回 200。
- 对比 canonical 地址和实际访问的 URL，差异是否只在参数、大小写、末尾斜杠这类形式上。
- 检查同一组页面的内链、sitemap、canonical 是否都指向同一个版本。
- 抽查几个被合并掉的页面，确认它们在内容上确实重复，而不是碰巧模板相似。
- 改版、换模板或调整参数规则之后，重新检查一遍 canonical 有没有被批量写错。
放平预期
canonical 写对之后，收录和排名不会马上发生变化。它更像是减少干扰的基础工作：把重复地址收敛到一个版本，让后续的抓取和索引有明确的落点。
如果一组页面长期没有收录，先排查抓取是否正常、内容本身是否有价值，再回头看 canonical。规范标签解决的是“哪一版算数”，解决不了“这一版值不值得收录”。