Google 使用约 40 种规范化信号
据 Google 网站管理员趋势分析师 Gary Illyes 称，互联网上约 60% 的内容属于重复内容。Google 的抓取流程高度专注于消除重复，因为互联网上约六成内容是重复的……
规范化（Canonicalization）是搜索引擎在存在重复 URL 时，用来确定将被索引并展示给用户的主版本 URL 的过程。聚类（clustering）把重复页面归为一个簇，规范化则决定信号整合到哪个版本、以及搜索结果中展示哪个页面。这一过程涉及重复检测、重复消除、信号传递、错误页面和本地化。
据 Google 网站管理员趋势分析师 Gary Illyes 称，互联网上约 60% 的内容是重复内容。
规范化过程复杂，且常被误解。我认为大多数重复并非出于恶意，多半由技术问题引起，稍后会进一步探讨。下面讲解规范化流程的运作方式，以及以下内容：
规范化信号
规范化流程会用到许多不同的信号。据 Google 的 Allan Scott 称，共有约 40 种不同的规范选择信号，包括：
- 重复内容
- 规范链接元素
- 站点地图中的 URL
- 内链
- 外链
- 重定向
- Hreflang
- X-default hreflang
- PageRank
- HTTPS 页面优先于 HTTP
- 短 URL 优先于长 URL
- 内容首次发布/被看到的位置
- 站点级信号，例如抓取内容的历史记录
- 页面优先于 PDF
Google 会查看所有不同的信号并对其加权，以确定规范版本应该是哪一个，那就是它将要索引、通常也会展示给用户的页面版本。这一过程由一套机器学习系统处理，由 Google 一个名为 Dups（他们说明应拼作 Dupes）的团队管理。
重复内容
有些 SEO 认为存在重复内容惩罚，但事实并非如此。一般来说，终归会有某个版本被索引。它可能不是你希望被索引的版本，但它会被索引，并且和同一页面的其他任何版本一样排名良好。
以下是一些可能导致重复页面、有时也会引发规范化问题的例子：
- HTTP 与 HTTPS 变体 例如：http://www.example.com 和 https://www.example.com。有多种规范判断标准来处理这种情况。
- 非 www 与 www 变体 http://example.com 和 http://www.example.com。
- 带与不带结尾斜杠的 URL https://example.com/page/ 和 https://example.com/page。
- 带与不带大写字母的 URL https://example.com/page/ 和 https://example.com/Page/。
- 页面的默认版本，例如 index 页面 https://www.example.com/、https://www.example.com/index.htm、https://www.example.com/index.html、https://www.example.com/index.php、https://www.example.com/default.htm 等。
- 页面的替代版本可能包括移动版（例如 example.com 和 m.example.com）、AMP 版（例如 example.com/page 和 amp.example.com/page）、打印版（例如 example.com/page 和 example.com/page/print）、面向其他国家但包含相同内容的替代版本（例如 example.com/en-us/、example.com/en-gb/、example.com/en-au/），或者位于开发或预发布站点上的版本（例如 dev.example.com）。
- URL 参数例如：example.com?parameter=whatever。它们可能因跟踪代码、分面导航、内容排序、会话 ID 等而存在。有些情况下，参数可能改变页面内容，使其不再是重复内容。
- 展示完整内容的其他页面 当另一个页面完整展示内容时，Google 可能会选错规范版本。这可能包括博客主页、分页页面、标签页、分类页或 feed 页面。
- 抓取或联合发布的内容 内容联合发布的最佳实践通常建议设置一个指向原创内容的规范标签，或至少放一个指向原创内容的链接。这是因为被选中的规范版本可能来自完全不同的域名。Google 会尝试选择原始来源作为规范版本，但在某些情况下会选错页面。
- 样板内容的翻译。指像菜单和每个页面都会出现的文字可能被翻译了，但主要内容没有翻译。这些内容会被归到同一个簇中。不过，如果价格或货币不同，Google 会尝试把它们归入不同的簇。
- 错误页面。错误页面可能彼此聚为一簇，包括软 404 / crypto 404、因 JavaScript 依赖未加载或未渲染而产生的页面、机器人检测错误页面等。
这些问题大多通常不算问题。正如我提到的，Google 通常会选择某一个版本作为规范版本。但也有少数例外。
- 有时在内容联合发布的情况下，原始来源没有被选为规范版本。这是真正的问题。如果有人开始凭你写的文章获得排名，你会作何感想？
- Hreflang 并不能解决国际化站点上的重复问题。Google 通常会尝试切换到展示正确的版本，但这并非保证，而且这种设置经常出问题。一旦出问题，用户就会看到来自错误国家的页面。对于国际化网站，最好避免在多个页面上放置相同内容。
- 对于一些 JavaScript 网站（通常是 app shell 模式），页面的初始代码可能看起来像其他页面，甚至像其他网站的代码。有时这些页面会被规范化到同一网站甚至不同网站上的其他页面。
我认为 hreflang 和 JavaScript 内容这两部分问题的部分原因在于，Google 可能通过爬虫算法运行重复检测来识别重复模式——既在只看代码之后运行一次，也在渲染页面之后再次运行。
对于使用 hreflang 的页面，如果 Google 在没有抓取的情况下就认定这些页面是重复的，可能就无法正确地在它们之间切换。
在页面被渲染之前，它可能仅凭 HTML 内容就"看起来"像另一个页面。Google 可能基于这个初始版本选择规范版本，并因为已经认定它是重复页面而不再优先渲染它。这通常会在渲染后自行解决，但清理掉可能需要一些时间。
在重复内容的规范化方面，Google 通常会遵循几条规则。
1. 它优先选择 HTTPS 页面而非 HTTP 页面。
Google 通常会索引 HTTPS 版本，但有几个问题或相互冲突的信号可能导致它转而选择 HTTP 版本，例如：
- 安全证书无效。
- HTTPS 页面链接到页面内的 HTTP 资源（图片除外）。
- HTTPS 重定向到 HTTP。
- HTTPS 页面上有一个 rel="canonical" 链接元素指向 HTTP 页面。
- HTTPS 页面重定向到 HTTP 页面，该 HTTP 页面又重定向回 HTTPS 页面。它并不安全，所以可能导致 HTTP 被选为规范版本。
这里的关键点在于，当页面不安全时，Google 会选择 HTTP 页面。
2. 它优先选择较短的 URL 而非较长的 URL。
多年来，SEO 们把这句话曲解为：你所有的 URL 都应该更短。但原来的说法并非这个意思。Google 说的是，例如，如果你有一个简洁、短的 URL 版本，以及一个附加了参数的更长版本，它通常会选择不带参数的那个较短 URL 版本作为规范版本。
规范链接元素
这也常被称为规范标签（canonical tag）。它看起来像这样：
[['Text', '<link rel="canonical" href="https://www.example.com" />']]
如果规范标签被采纳，像链接这样的所有信号都会传递过去。然而，如果规范标签被忽略，则不会传递任何价值。这些价值并不会丢失；它会留在原页面，或者流向 Google 选择的那个作为规范版本的页面。
规范链接元素可以通过两种不同的方式实现。它可以放在 <head> 区域，也可以放在 HTTP 响应头中。
一个有趣的轶事。Google 的 SEO 入门指南曾经是一份 PDF。它没有在 HTTP 响应头中设置规范标签，于是人们常用自己的重复版本来"抢走"这个条目。
有时页面的 <head> 区域会提前结束，早于它本该结束的位置。这通常是因为 <head> 中某个标签没有正确闭合。一旦发生这种情况，规范标签可能会被放进 <body> 区域。如果这样，你的规范标签就不会被采纳。
如果在一批页面上使用了空白的规范链接元素""（会被当作"/"处理），它可能会被忽略。规范标签中在页面加载时未被填写的变量也是如此。Google 是在帮你，因为是你弄错了。
站点地图中的 URL
你放在站点地图中的 URL 也是一个规范化信号。大多数时候，你只应包含你希望被索引的页面 URL。
这有一些例外，因为站点地图中的 URL 也有助于抓取。在网站迁移之后，你应该创建一个仍列出旧页面的站点地图，即使它们不是规范版本。这有助于重定向被更快处理。等大部分重定向都被抓取和处理之后，你就会想删除这个站点地图。
内链
你如何链接到页面很重要。内链是另一个规范化信号。
重定向
有几种不同类型的重定向，它们都是规范化信号。重定向通常是相当强的规范化信号。它们会传递 PageRank，并帮助确定哪个 URL 会被展示在 Google 的索引中。
永久重定向（如 301）会把信号向前传递到新 URL。临时重定向（如 302 和某些 307）会把信号向后传递到被重定向的 URL。如果临时重定向保留得足够久，或者它重定向到的 URL 已经存在，它可能会被当作永久重定向，从而改为向前传递信号。这需要足够多的信号来打破我们前面看到的规范化信号天平。随着链接积累、内链被修改、站点地图 URL 被更新等，指向新 URL 的信号会多于旧 URL，于是天平就会翻转。
307 有两种不同情况。在临时重定向的情况下，它的处理方式和 302 一样，会尝试向后整合。当 Web 服务器要求客户端只使用 HTTPS 连接（HSTS 策略）时，Google 不会看到这个 307，因为它被缓存在浏览器中。首次请求（没有缓存时）会有一个服务器响应码，很可能是 301 或 302。但你的浏览器在后续请求中会显示 307。
如何检查规范版本
如果你没有 Google Search Console 的访问权限，检查 Google 索引的页面版本，推荐的做法是把 URL 粘贴到 Google 里。最顶部的结果通常就是规范版本。
同样，如果你在 Google 中查看某页面的缓存版本时显示的是另一个页面，那么 Google 已经选择了该页面的另一个版本。
警告：不要用 site: 搜索来检查规范版本。它展示的是 Google 知道的内容，而不一定是已被索引的内容或所选的规范版本。
即便你的网站有很多与规范化相关的问题，搜索引擎也可能能弄清应该索引哪个版本、以及应该在哪里整合信号。这也许不会给它们造成任何实际问题。
一个有趣的冷知识。运行站点审计时，我们只把页面的规范版本计入抓取额度，其他一些工具会把页面的每个版本都计入额度。在很多网站上，这可能每页就吃掉多个额度！
常见错误
规范化有很多地方可能出错。下面来看一些常见错误。
错误 #1. 通过 robots.txt 屏蔽被规范化的 URL
在 robots.txt 中屏蔽某个 URL 会阻止 Google 抓取它，也就意味着 Google 看不到该页面上的任何规范标签。这反过来又阻止它把任何"链接权重"从非规范版本传递到规范版本。
除非你有抓取预算问题，否则让所有信号整合起来可能更好。即便你打算屏蔽或对某些版本设置 noindex，你可能仍想检查那些带有链接、你本应将其规范化的版本。不过，由于 Google 往往会随时间推移越来越少地抓取非规范页面，你也大可以耐心等待。
错误 #2. 把被规范化的 URL 设为"noindex"
永远不要把 noindex 和 rel=canonical 混在一起用，它们是相互矛盾的指令。
正如 John Mueller 所说，Google 通常会优先采用规范标签，而不是"noindex"标签。
错误 #3. 为被规范化的 URL 设置 4XX HTTP 状态码
为被规范化的 URL 设置 4XX HTTP 状态码，效果和使用"noindex"标签一样：Google 将无法看到规范标签，也无法把"链接权重"传递到规范版本。
错误 #4. 把所有分页页面都规范化到根页面
分页页面不应被规范化到该系列中的第一个分页页面。相反，所有分页页面都应使用自我引用的规范标签（self-referencing canonical）。
为什么呢？正如 John 在 Reddit 上所说，这是对 rel=canonical 的不当使用。
如果你有兴趣，我们有一篇关于分页的 SEO 指南和最佳实践。
错误 #5. 使用 Google Search Console 中的 URL 移除工具来做规范化
这会移除某个 URL 的所有版本，实际上就是把你的页面从搜索中除籍（deindex）。
错误 #6. 不保持规范化信号一致
正如前面谈到的，规范化信号有很多种。
不同的信号指向不同的规范版本，意味着你将依赖 Google 替你选择规范版本。你向 Google 展示的、指向你偏好版本的信号越一致，这个版本成为所选规范版本的可能性就越大。
错误 #7. 使用 hreflang 时不搭配规范标签
Hreflang 标签指定网页的语言和地理定位。
Google 表示，使用 hreflang 时，你应"指定一个同语言的规范页面，或者如果同一语言没有规范页面，则指定最合适的替代语言页面"。
错误 #8. 存在多个 rel=canonical 标签
存在多个 rel=canonical 标签通常会导致 Google 忽略它们。在很多情况下，出现这种情况是因为标签在不同环节被插入到系统中，例如由 CMS、主题和插件分别插入。这就是为什么许多插件都有覆盖选项，用来确保自己是规范标签的唯一来源。
另一个可能出问题的场景是用 JavaScript 添加规范标签。如果你在 HTML 响应中没有指定任何规范 URL，然后用 JavaScript 添加一个 rel=canonical 标签，那么当 Google 渲染页面时，它应被采纳。然而，如果你在 HTML 中指定了一个规范版本，又用 JavaScript 替换了偏好的版本，那你就是在向 Google 发送混杂的信号。
错误 #9. rel=canonical 出现在 <body> 中
Rel=canonical 应只出现在文档的 <head> 中。位于页面 <body> 区域的规范标签会被忽略。
这里可能出问题的地方在于文档的解析。即便页面的源代码把 rel=canonical 标签放在了正确的位置，很多情况——比如未闭合的标签、注入的 JavaScript，或 <head> 区域中的 <iframe>——都可能导致 <head> 在渲染时提前结束。在这些情况下，规范标签可能会被意外地丢进渲染后页面的 <body> 中，从而不被采纳。
结语
如果你有疑问，可以在 Twitter 上给我发消息。