摘要

  • 2009 年 2 月，Google 让网站在重复页面的 HTML 头部写入 rel="canonical"，提名希望搜索结果采用的网址。发布者可以提名，索引方仍有最终选择权；Google 当时就称它为「强提示」。
  • 2012 年的 RFC 6596 把风险写得很直白：如果长文第二页把第一页标为 canonical，索引程序可能把第二页当作重复内容，连独有段落一起略过。网址整洁的代价可能是正文失踪。

给站长一张选票

同一件商品往往有几张门牌：原始网址、带分类参数的网址、带广告追踪参数的网址，还有会话 ID 版本。人看到的是同一件商品，搜索引擎看到的却是几个可收录地址。Google 在 2009 年 2 月 12 日的发布说明里，给网站一个简短写法：在重复页的 <head> 放上 <link rel="canonical" href="...">，指出希望由哪张门牌代表它们。

这行代码不搬走页面，也不替浏览器跳转。它向搜索索引提出请求：把重复网址的链接等信号归到偏好的地址，让搜索结果展示那一个。Google 随即回答关键问题：这是命令吗？不是，是会认真参考的提示，还要与其他信号一起判断。网站知道自己制造了哪些网址；搜索引擎掌握抓取、链接及重复页聚类。前者递交选票，后者点票。

当年的边界还在同一篇说明里。最初的回答允许不同子域名之间提出建议，却没有开放完全不同域名之间的 canonical；跨域迁移更适合永久重定向。Google 在 2009 年 12 月 17 日补写更新，才说跨域 canonical 已获支持。把补写日期抹掉，就会把一个逐步扩张的索引功能误写成上线首日已经无所不包。

一份关系说明，两个执行者

RFC 6596 于 2012 年 4 月把 canonical 定义为网页资源之间的关系：引用页可以指向内容重复、或者内容更完整的目标页。声明既能放在 HTML，也能放进 HTTP Link 响应头。后者让没有 HTML 头部的文件也能表达偏好。规范列出接收程序可能采取的动作：只处理目标页、汇总链接声望、展示目标网址。这里的动词是「可能」；RFC 给了关系语义，没有替每个索引程序签收执行单。

最锋利的例子是一篇被拆成两页的长文。第二页有独有段落，完整阅读页包含两页内容。让各分页指向完整阅读页，逻辑上说得通；让第二页指向第一页，则等于宣称第一页包含第二页的文字。RFC 提醒，索引程序可能据此把第二页认作重复页，略过其内容。读者在浏览器里仍能打开第二页，搜索索引却可能忘掉它。这不是排版小错，而是把文章的一部分交给了错误的代表。

RFC 还建议每个资源只给一个 canonical，避开返回错误、永久跳转或继续指向别处的目标。声明不合格时，接收程序可以忽略它，改用自己的判断。Google 现行的说明同样把最后一步留在搜索系统：它按多个信号选代表页，可能不采用站长指定的地址。今天的文档说明今天的操作；2009 年那句「强提示」已经说出了权力分界。