规范标签详解：为何它对 SEO 如此重要
规范标签（canonical tag）是一段 HTML 代码，用于在存在相似或重复 URL 时告知搜索引擎哪个页面版本为主版本，从而确保只有主版本被索引。本文说明其作用原理与使用时机。
规范标签可防止重复内容引发问题，避免其对 SEO 造成损害。
下文说明其工作方式与适用场景。
什么是规范标签？
规范标签（rel="canonical"）是一段 HTML 代码，用于在存在相似或重复 URL 时告知搜索引擎哪个页面版本为主版本，从而确保只有主版本被索引。
下面是规范标签的一个示例：
所指定的 URL 即你希望被索引的页面主版本。
何时应该使用规范标签？它对 SEO 为何重要？
只要同一份或相似的内容能通过多个 URL 访问，就应使用规范标签。
以下是造成这种情况的若干原因：
- 带与不带末尾斜杠的 URL 上存在重复内容（例如 example.com/ 与 example.com）
- 页面的桌面版与移动版上存在重复内容（例如 example.com 与 m.example.com）
- URL 的参数化版本上存在重复内容（例如 example.com 与 example?tracking-code）
例如，假设你经营一家销售小配件的电商店铺。你可能有一个列出所有蓝色小配件的分类页面，其 URL 为 [['Text', 'example.com/widgets/blue/']]。但访客应用商品筛选器后，完全相同的内容可能通过这样一个不美观的 URL 访问到：[['Text', 'example.com/widgets?color=blue']]
若不指定规范版本，"错误"的 URL 版本可能被索引并出现在搜索结果中。
规范标签还能让链接等排名信号集中到同一页面。这一点很重要，因为链接是已被证实的Google 排名因素，而链接与流量之间存在很强的相关性。
重复内容过多还会消耗"抓取预算"（crawl budget），即 Google 把资源浪费在抓取内容的重复版本上，而不去抓取你真正希望被索引的新页面。最终它多半会明白不必频繁抓取这些页面，但得出这一结论前必须先抓取一次，抓取预算就浪费在这里。
如何为网站添加规范标签
你可以手动把 [['Text', '<link rel="canonical" href="https://example.com"/>']] 添加到页面代码的 [['Text', '<head>']] 部分，但几乎没人这么做，因为过于繁琐。通过网站平台操作通常简便得多。
无论采用哪种方式，都请遵循以下黄金法则：
- 使用绝对 URL。Google 表示不要使用相对 URL（例如
[['Text', '/sample-page/']]），尽管它们也受支持。因此，规范标签中应指定完整的绝对 URL（例如[['Text', 'https://example.com/sample-page/']]）。 - 使用正确的域名。如果你已切换到 SSL（如今本应如此），务必不要在规范标签中声明任何非 SSL（即 HTTP）的 URL。否则可能让 Google 产生困惑，并带来意想不到的结果。
- 每个页面只指定一个规范版本。如果你声明了多个规范版本，Google 会忽略所有已声明的规范标签。
下面来看几个常见平台的操作流程。
在 WordPress 中设置规范标签
安装 Yoast SEO，然后在页面或文章中找到"高级"（Advanced）部分，即可看到指定规范版本的选项。
在 Wix 中设置规范标签
按照他们的分步指南操作。相比 WordPress 稍显繁琐，但仍然可行。
在 Shopify 中设置规范标签
Shopify 开箱即用的规范化处理已相当到位。但这并不意味着它总是完美无缺。多数中小型店铺可能无需手动添加规范标签。如果你确实需要，建议请开发者协助，因为必须直接编辑主题代码（.liquid 文件）。
在 Squarespace 中设置规范标签
进入页面的高级设置，即可把规范标签注入到 header 中。
声明规范 URL 的其他方式
规范标签并非声明页面规范版本的唯一方式。还有另外三种方法：
- 重定向
- HTTP 头中的 rel="canonical"
- 站点地图
重定向
Google 表示，只有在弃用一个重复页面时才使用这种方式，因为它会把 Googlebot（以及访客）重定向到另一个 URL。对于 HTTP 与 HTTPS 页面同时可访问而导致的重复内容，这是特别有用的选项。
HTTP 头中的 rel="canonical"
对于 PDF 这类文档，无法把规范标签放在页面头部，因为没有页面 <head> 部分。此时需要通过 HTTP 头设置规范版本。
下面是本篇博客文章的 PDF 版本可能呈现的样子：
你也可以在标准网页上使用 HTTP 头中的规范版本。
站点地图
站点地图中应只列出规范 URL，不过 Google 表示这样做只是一个较弱的规范化信号。
常见的规范化错误与最佳实践
规范化可能相当复杂。也正因如此，关于如何正确规范化存在许多误解和错误观念。
错误 1：通过 robots.txt 屏蔽被规范化的 URL
在 robots.txt 中屏蔽某个 URL 会阻止 Google 抓取它，这意味着它无法看到该页面上的任何规范标签。这又使它无法把任何"链接权重"从非规范版本转移到规范版本。
错误 2：把被规范化的 URL 设置为 noindex
切勿把 noindex 与 rel=canonical 混用，二者是互相矛盾的指令。
John Mueller 在 Reddit 上表示，Google 通常会优先考虑规范标签而非 noindex 标签，但这并非保证。Google 的官方文档称，noindex 会把页面彻底从搜索中移除。这也许是你想要的结果，但其他规范化方法同样能达到目的，却没有潜在负面影响（例如 Google 无法整合"链接权重"）。
错误 3：为被规范化的 URL 设置 4XX HTTP 状态码
为被规范化的 URL 设置 4XX HTTP 状态码，效果与使用 noindex 标签相同：Google 将无法看到规范标签，也就无法把"链接权重"转移到规范版本。
错误 4：把所有分页页面都规范化到根页面
Google 表示不要把分页页面规范化到系列中的第一页。
错误 5：配合 hreflang 使用时未使用规范标签
Hreflang 标签用于指定网页的语言和地域定位。
Google 指出，使用 hreflang 时，应"指定同一语言的规范页面，或者如果同一语言没有规范版本，则指定最合适的替代语言版本"。
错误 6：存在多个 rel=canonical 标签
存在多个 rel=canonical 标签很可能导致它们被 Google 忽略。很多情况下，这是因为标签在不同环节被插入系统，例如由 CMS、主题和插件分别插入。因此许多插件都提供覆盖选项，以确保自己是规范标签的唯一来源。
另一个可能出问题的地方是通过 JavaScript 添加的规范标签。如果你在 HTML 响应中没有指定规范 URL，随后用 JavaScript 添加 rel=canonical 标签，那么当 Google 渲染页面时它应当被遵循。然而，如果你已在 HTML 中指定了规范版本，却用 JavaScript 替换了首选版本，那就是在向 Google 发送混乱的信号。
错误 7：rel=canonical 出现在 <body> 中
rel=canonical 只应出现在文档的 <head> 中。位于页面 <body> 部分的规范标签会被忽略。
可能出问题的地方在于文档解析。虽然页面的源代码中 rel=canonical 标签位置正确，但当页面在浏览器中实际构建或由搜索引擎渲染时，未闭合的标签、注入的 JavaScript，或 <head> 中的 <iframes> 等因素都可能导致 <head> 在渲染时提前结束。在这些情况下，规范标签可能被意外地抛进渲染后页面的 <body> 中，从而不被遵循。
如何发现并修复网站上的规范标签问题
规范化容易出错，因此定期审计网站、检查与规范标签相关的问题并尽快修复是值得的。
你可以用 Ahrefs 的 Site Audit 完成这一工作；对于已验证的网站，配合 Ahrefs Webmaster Tools（AWT）账户即可免费使用。它会为网站抓取 170 多项 SEO 问题，其中包括与规范标签相关的问题。
以下是 Site Audit 可能发现的 14 个规范标签问题，以及各自的修复方法：
1. 规范版本指向 4XX
一个或多个页面被规范化到一个失效（4XX）的 URL。
为什么这是个问题
搜索引擎不会索引 4XX 页面，因为它们无法正常工作。因此，它们会忽略指向此类页面的任何规范标签，并往往最终索引错误（非规范）的页面版本。
如何修复
检查受影响的页面，把失效（4XX）的规范链接替换为指向你希望被索引且正常可访问（200）页面的链接。
2. 规范版本指向 5XX
一个或多个页面被规范化到一个 5XX 的 URL。
为什么这是个问题
5XX HTTP 状态码表明存在服务器问题，会导致规范页面无法访问。Google 不太可能索引无法访问的页面，因此可能忽略该规范版本。
如何修复
把任何错误的规范 URL 替换为有效的 URL。如果指定的规范版本看似正确，就检查是否存在服务器配置错误。请注意，如果抓取发生时网站正因维护而宕机，或服务器过载，这可能只是暂时问题。
3. 规范版本指向重定向
一个或多个页面被规范化到一个被重定向的 URL。
为什么这是个问题
规范版本应始终指向页面最具权威性的版本，而被重定向的 URL 并非如此。因此，搜索引擎可能误判或忽略该规范版本。
如何修复
把规范链接替换为直接指向页面最具权威性版本的链接（即返回 200 HTTP 状态码且不重定向的版本）。
4. 规范 URL 没有入站内链
一个或多个指定的规范 URL 没有入站内链。
为什么这是个问题
没有内链的规范 URL 对网站访客来说无法访问，说明网站中某处把用户导向了页面的非规范版本。
如何修复
把任何指向被规范化页面的内链替换为直接指向规范版本的链接。
5. 规范 URL 没有入站内链
没有任何内链指向一个或多个已声明的规范 URL。
为什么这是个问题
浏览网站的用户没有办法到达该规范 URL。内链对 Google 来说也是一个规范化信号。
如何修复
检查网站导航和链接架构，确保所有规范页面都易于访问。只要有可能，都应通过内链直接指向规范 URL。
6. 存在没有规范版本的重复页面
存在一个或多个重复或非常相似的页面，却未指定规范版本。
为什么这是个问题
因为没有指定规范版本，Google 会自行尝试确定在搜索结果中展示的最合适版本，而这未必是你想要被索引的版本。
如何修复
检查各组重复页面，挑选一个应在搜索结果中被索引的规范版本，并在所有重复页面中把该版本指定为规范版本（同时为该规范版本添加一个指向自身的规范标签）。
7. Hreflang 指向非规范版本
一个或多个页面在其 hreflang 标注中指定了非规范 URL。
为什么这是个问题
hreflang 标签中的链接应始终指向规范页面。在 hreflang 标注中链接到页面的非规范版本会混淆并误导搜索引擎。
如何修复
把受影响页面的 hreflang 标注中的链接替换为其规范版本。
8. 站点地图中存在非规范页面
站点地图中列出了一个或多个非规范页面。
为什么这是个问题
Google 指出，不应在站点地图中包含非规范 URL，因为 Google 会把站点地图中的页面视为建议的规范版本。你只应列出希望被索引的页面。
如何修复
从站点地图中移除非规范 URL。
9. 非规范页面被指定为规范版本
一个或多个页面指定的规范 URL 自身又被规范化到另一个页面，由此形成"规范链"：页面 A 被规范化到页面 B，而页面 B 又被规范化到页面 C。
为什么这可能是个问题
规范链可能混淆并误导搜索引擎，因此它们可能误判或忽略所指定的规范版本。
如何修复
把受影响页面规范标签中的非规范链接替换为直接指向规范版本的链接。例如，如果页面 A 被规范化到页面 B，而页面 B 又被规范化到页面 C，就把页面 A 上的规范链接替换为指向页面 C 的链接。
10. Open Graph URL 与规范版本不匹配
og:url Open Graph 标签中指定的 URL 与 rel=canonical 标签中指定的 URL 不一致。
为什么这可能是个问题
这对 Google SEO 来说不是问题，但页面的非规范版本会在社交网络上被分享。
如何修复
确保 og:url 中指定的 URL 与规范页面的 URL 一致。
11. 规范版本从 HTTPS 指向 HTTP
一个或多个安全（HTTPS）页面把非安全（HTTP）版本指定为规范版本。
为什么可能值得修复
HTTPS 是一个排名因素，因此在可能的情况下把页面的安全版本指定为规范版本是合理的。
如何修复
把 HTTP 页面重定向到对应的 HTTPS 页面。如果无法做到，就从页面的 HTTP 版本添加一条 rel="canonical" 链接指向 HTTPS 版本。
12. 规范版本从 HTTP 指向 HTTPS
一个或多个非安全（HTTP）页面把安全（HTTPS）版本指定为规范版本。
为什么可能值得修复
HTTPS 优于 HTTP，页面的 HTTP 版本却把 HTTPS 版本指定为规范版本，逻辑上不通。这很可能不会造成大问题，但如果可能，仍值得修复。
如何修复
实施从 HTTP 到 HTTPS 的 301 重定向，并把任何指向页面 HTTP 版本的内链替换为直接指向 HTTPS 版本的链接。
13. 规范 URL 已更改
自上次抓取以来，一个或多个 URL 上声明的规范版本发生了变化。
为什么可能值得修复
自上次抓取以来的这一变化可能指向某个错误或问题。请记住，所声明的规范版本应是你希望 Google 索引并排名的那一版页面。
如何修复
检查受影响的页面，确认这些更改是有意为之。
14. 非规范页面获得自然流量
一个或多个非规范页面出现在搜索结果中并获得自然搜索流量（这不应发生）。
为什么可能值得修复
要么是你设置的规范标签不正确，要么是 Google 选择忽略了所指定的规范版本。
如何修复
检查所有被报告页面上的 rel=canonical 标签是否设置正确。如果问题不在那里，就用 Google Search Console 中的 URL 检查工具查看它们是否把所指定的规范 URL 视为规范版本。如果不一致，就排查原因。
进一步了解规范化
阅读我同事 Patrick 的规范化指南。他更详细地介绍了规范化信号，以及如何用 Google Search Console 中的 URL 检查工具查看 Google 如何看待某个 URL 的规范版本。
有疑问？可以在 LinkedIn 上找我。