什么是 HTTPS？你需要了解的一切
HTTPS 能保护你的浏览器与服务器之间的通信，防止其被攻击者拦截和篡改，为当今绝大多数万维网流量提供了机密性、完整性和身份验证。任何在地址栏中显示锁形图标的网站……
超文本传输安全协议（HTTPS）是 HTTP 的加密版本，而 HTTP 是在万维网上传输数据所使用的主要协议。
HTTPS 能保护你的浏览器与服务器之间的通信，防止其被攻击者拦截和篡改。它为当今绝大多数万维网流量提供了机密性、完整性和身份验证。
任何在地址栏中显示锁形图标的网站，都在使用 HTTPS。
在本文中，你将了解：
HTTP 与 HTTPS：了解基础知识
首先，让我简化并说明当客户端（浏览器）与服务器之间存在攻击者时的通信过程。
如你所见，攻击者可以获取登录和支付详情等敏感数据，或向所请求的资源中注入恶意代码。
潜在的网络攻击可能发生在任何使用不受信任的路由器或 ISP 的地方。因此，任何公共 WiFi 网络都容易受到此类攻击。幸运的是，公众似乎正在意识到这一事实（VPN 的使用日益增多）。
然而，让每个人的浏览体验变得安全的责任，现在和将来都应该落在网站站长身上。
这正是采用 HTTPS 发挥作用的地方。
HTTPS 会对 HTTP 请求和响应进行加密，因此，拦截通信的攻击者只能看到随机字符，而不是诸如信用卡详情这样的内容。
打个比方，HTTPS 的工作原理就像用一只坚不可摧的带密码锁的箱子寄送贵重物品。只有发送方和接收方知道密码，即使攻击者拿到了箱子，也无法打开它。
如今，建立 HTTPS 连接时会发生很多事情。主要是，HTTPS 依赖 TLS（传输层安全）加密来保障连接安全。
HTTPS 可防范的攻击
如果没有 HTTPS，你的网站就容易受到几种众所周知的攻击：
- 中间人攻击（MITM）：攻击者拦截浏览器与服务器之间的通信
- 会话劫持：窃取通过未加密连接发送的会话 cookie
- SSL 剥离：在用户不知情的情况下将 HTTPS 降级为 HTTP
- 凭据窃取：截获以明文发送的登录凭据
HSTS（HTTP 严格传输安全）通过强制使用 HTTPS 连接来专门防范 SSL 剥离——我们稍后会介绍它。
TLS 证书的工作原理
在你的网站上启用 HTTPS 的唯一方法，是获取一份 TLS 证书并将其安装到你的服务器上。你还会遇到它被称为 SSL 或 SSL/TLS 证书，但别担心，它们都是同一回事。尽管我们在技术上使用的都是 SSL 的继任者 TLS，但 SSL 这个术语仍被广泛使用。
TLS 证书由证书颁发机构（CA）签发。CA 的作用是在客户端-服务器关系中充当受信任的第三方。基本上，任何人都可以签发 TLS 证书，但只有公开受信任的 CA 才会被浏览器所支持。
你可以点击浏览器地址栏中的锁形图标，查看每个网站的 TLS 证书及其签发的 CA。
你可以点击证书以了解更多信息。这里重要的是“颁发给：”（Issued to:）这一行。正是在这里，我们会接触到 TLS 证书的不同验证标准，而这主要是区分免费证书和付费证书的关键。
TLS 版本：为什么 1.3 很重要
并非所有 TLS 都是平等的。以下是关于 TLS 版本你需要了解的内容：
- TLS 1.3（2018）：当前标准。握手更快、加密更强，移除了存在漏洞的加密套件
- TLS 1.2（2008）：仍可接受且被广泛支持
- TLS 1.0/1.1：已弃用。各大浏览器已于 2020 年放弃支持，微软也于 2026 年 2 月弃用了这些版本
最佳实践：将服务器配置为支持 TLS 1.3，并回退到 TLS 1.2。完全禁用更旧的版本。
DV、OV 和 EV：它们意味着什么，该选哪一个？
随你的主机和 CDN 方案附带的免费 TLS 证书只进行域名验证（DV）。它验证的是证书持有者控制着某个给定的域名。这种基础验证技术对博客和不处理敏感信息的网站来说已经足够，但对处理敏感信息的网站来说则并不理想。
使用 DV TLS 证书的网站看起来是安全的，但你点击锁形图标时不会看到“颁发给：”这一行。
最常见的 DV TLS 证书来自一家名为 Let's Encrypt 的非营利性 CA，它在 SSL 证书颁发机构中占有约 64% 的市场份额。大多数提供免费、可自动续期 TLS 证书的公司使用的都是它。
仅使用 DV 证书并没有什么不好，毕竟它是唯一能够大规模自动签发的 TLS 证书类型。然而，HTTPS 的安全性取决于用于验证与你通信的服务器的底层证书。
如果你的网站允许登录或支付，你应该投资一份提供组织验证（OV）或扩展验证（EV）的 TLS 证书。这两种类型的验证流程不同，其中 EV 更为严格。
如果你只打算买一份，我建议直接购买 EV TLS 证书。它是最值得信赖的，而且价格并不会比 OV 贵多少。
通配符和 SAN TLS 证书
先放下验证标准，我们来看看另一类 TLS 证书。
通配符证书和 SAN 证书用于一次性保护多个（子）域名。例如，如果你为 example.com 购买了一份标准的 EV TLS 证书，你就需要为 blog.example.com 再单独购买一份证书。
通配符证书可以保护不限数量的子域名（example.com、blog.example.com、docs.example.com），而 SAN 证书还可以选择保护其他域名（example.com、blog.example.com、different.org）。
这些类型会与验证类型相结合，因此当你浏览 CA 提供的各种选项时，会看到各种各样的组合。它们还会引导你完成验证流程。
HTTPS 如何帮助 SEO
HTTPS 的几乎所有好处都与 SEO 相关：
- 轻量级的排名信号
- 更好的安全性和隐私
- 保留引荐数据
- 支持使用可增强安全性和网站速度的现代协议
轻量级的排名信号
早在 2014 年，Google 就宣布 HTTPS 是一个轻量级的排名因素。它更像是一个决胜因素，而不是在其他排名因素变量保持不变时能让你的排名一飞冲天的东西。
这基本上是 Google 为推动全球更快采用 HTTPS 所做的贡献。
更好的安全性和隐私
我们已经谈过这一点了。但它与 SEO 有什么联系呢？
当你访问一个不安全的网站时，你会看到类似这样的提示：
这确实不能建立信任，对吧？我很清楚自己有职业偏见，但我个人会留意这一点，如果我在任何网站上看到这种情况，就会很快形成糟糕的第一印象。
我猜测迁移到 HTTPS 可以提高停留时间并防止“弹回”（pogo sticking）。虽然这些都只是理论上（而非已确认的）排名因素，但让用户在你的网站上“停留”下来，是无论从 SEO 还是其他角度都想要的结果。
2026 年重要更新：Google Chrome 将从 2026 年 10 月起（Chrome 154）推出“默认使用 HTTPS”。这意味着 Chrome 会自动尝试建立 HTTPS 连接，并在加载任何 HTTP 网站前显示警告。该功能从 2026 年 4 月起面向“增强型安全浏览”用户推出。如果你的网站仍在使用 HTTP，那么在 Chrome 开始主动警告访客远离之前，你还有到 2026 年底的时间。
保留引荐数据
如果你的网站仍在使用 HTTP，并且你在使用 Google Analytics 等网站分析服务，那么我有个坏消息要告诉你：从 HTTPS 页面不会向 HTTP 页面传递任何引荐数据。
由于现在绝大多数网站都运行在 HTTPS 上（据 W3Techs 统计，截至 2026 年占所有网站的 89%），大多数引荐流量（即点击其他网站上的链接）的来源在大多数分析软件中都会被标记为“直接访问”。
这样做的一个缺点是会让你的数据变得杂乱和失真。另一个缺点是，你无法看到最好的引荐来源——这白白浪费了链接建设的机会。
支持使用可增强安全性和网站速度的现代协议
从理论上讲，由于增加了安全特性，HTTPS 比 HTTP 更慢。然而，拥有 HTTPS 是使用最新安全和 Web 性能技术的前提条件。
换句话说，除了安全性之外，当你使用 TLS 1.3、HTTP/2 和 HTTP/3 等协议时，HTTPS 还能让你的网站提升页面速度。
HTTP/3 与 QUIC：HTTP/3 是最新的 HTTP 协议版本，它使用 QUIC 而非 TCP 进行传输。主要优势包括更快的连接建立（0-RTT 握手）、在移动网络和 WiFi 等不可靠网络上更好的性能，以及内置加密（因为 QUIC 要求使用 TLS 1.3）。截至 2025 年，HTTP/3 的全球采用率已达到约 35%。
除了更好的用户体验之外，Google 也认为页面速度是与 HTTPS 类似的轻量级排名因素：
常见的 HTTPS 错误及其修复方法
在我们深入讨论迁移错误之前，先快速参考一下用户常遇到的 HTTPS 错误及其成因：
这些错误大多源于配置错误的服务器或已过期的证书。如果你在自己的网站上看到这些错误，请立即处理——浏览器会警告访客远离。
如何设置 HTTPS
这取决于你的具体情况。
1. 你正在上线一个新网站
恭喜你，你中奖了。从一开始就使用 HTTPS，你就永远不必担心 HTTP 以及与之相关的迁移错误。
你只需要一个优秀的托管服务商，它会指导你完成整个过程，并支持最新的 HTTP 和 TLS 协议版本。一切运行起来之后，最后一步是实施 HSTS 来锁定安全性。
2. 你的网站已经启用了 HTTPS
你在阅读本文这件事本身就说明，它可能配置得并不正确。请按照下一节中的建议检查常见错误。
3. 你的网站仍在 HTTP 上运行
把所有内容准备好并完成需要一段时间。迁移的复杂程度取决于：
- 你网站的规模和复杂程度
- 你使用的 CMS 类型
- 你的托管/CDN 服务商
- 你的技术能力
虽然我认为，使用流行 CMS 和可靠托管的小型网站所有者可以自己完成迁移，但其中涉及很多变量。
我建议你查阅 CMS/服务器/托管/CDN 的文档，并据此谨慎操作。你需要执行的步骤相当多，因此请创建或遵循一份迁移检查清单，不要试图同时兼顾其他活动。
如果这一切对你来说太技术性了，那就聘请专业人士。这会为你节省数小时的时间，让你省心，并确保实施具有前瞻性。
如何检查潜在的 HTTPS 迁移错误
即使你完成了整份 HTTPS 迁移检查清单，你仍有可能遇到一些问题。
虽然 HTTPS 的采用情况已有显著改善，但实施错误仍然很常见——尤其是在迁移期间。我们在 2016 年对 10,000 个域名的研究发现，当时问题普遍存在，而如今许多相同的错误模式依然存在。
我建议你检查下面五个常见的 HTTPS 迁移错误。这不会花太多时间，而且其中大多数都不难修复。
你还可以启用 Ahrefs Site Audit 中的 Always-on Audit（持续审计）。它会 24/7 监控你的网站，并在关键问题（例如遗漏的 HTTP 页面或损坏的重定向）一旦出现时立即提醒你。这在 HTTPS 迁移之后尤其有用，因为问题可能会意外浮现。
错误 1：遗留的 HTTP 页面
首先也是最重要的，你需要确保网站上的所有页面都已经在使用 HTTPS。
你可以通过彻底抓取网站来发现遗留的 HTTP 页面。如果你遵循了任何一份 HTTPS 迁移清单，这应该不是什么新鲜事。只需确保抓取工具拥有所有必需的 URL 来源，以免遗漏页面。
为此，你可以免费使用 Ahrefs Webmaster Tools，并按照以下方式设置：
完成之后，打开最新的抓取结果，进入 Page Explorer（页面浏览器）并应用以下筛选条件：
导出 HTTP URL 列表并将它们重定向，以完成迁移。
请记住：不在你的站点地图中、且没有任何链接指向它们的页面，是无法通过抓取发现的。这种情况常常发生在专门的 PPC 落地页上。发现这些页面的一种方法是，从 Google Ads 或 FB Business Manager 等广告管理平台导出 URL 列表。
然后，确保这些孤立页面已被正确迁移。别忘了在广告系列后台中把它们更新为较新的 HTTPS 格式。
错误 2：HTTPS 页面包含 HTTP 内容
当初始 HTML 文件通过 HTTPS 加载，但其资源文件（图片、CSS、JavaScript）尚未更新为 HTTPS 时，就会出现这种错误。
如果你的网站存在这个问题，你会在抓取概览和“内部页面”报告中看到它。免费的 Ahrefs Webmaster Tools 中的所有错误、警告和提示都包含问题说明以及如何修复的建议。
错误 3：内链未更新为 HTTPS
未将你的内链更新为 HTTPS 会导致不必要的重定向。这显然比落到一个 HTTP 页面上要好，但我们已经讨论过这个错误了。这些链接很容易被发现并修复。
你可以在 Ahrefs Webmaster Tools 中 Site Audit 的“链接”（Links）报告下找到这个问题：
只需把 URL 改写为 https:// 就可以了。这只适用于你已经按照错误 #1 中的建议确认没有遗留 HTTP 页面的情况。
错误 4：标签未更新为 HTTPS
你的网站上可能在使用两种同样需要把 URL 更新为 HTTPS 的标签：规范标签（Canonical tags）和 Open Graph 标签。
规范标签告诉 Google，在一堆相似或重复的页面中，你认为哪一个是最具权威性的页面。把它指向 HTTP 版本肯定会给 Google 发出糟糕的信号，而且很可能会被忽略。
如果你使用 Open Graph 标签来优化社交媒体帖子，那么 URL 标签是 Facebook 所要求的。它们应当与规范 URL 相同。
要找出带有 HTTP 规范标签和 OG 标签的页面，请在 Page Explorer 中设置以下自定义筛选条件：
同样，在迁移完全完成后，剩下的就是把它们改写为 https://。
错误 5：失败的重定向
重定向可能很棘手。从损坏的重定向到重定向链和重定向循环，可能出错的地方相当多。
幸运的是，使用 Site Audit 很容易发现这些错误。只需查看“重定向”（Redirects）报告并逐一检查所有问题即可。
点击“查看受影响的 URL”按钮后，你会看到一份类似的报告，只是默认列和指标更多：
这里最好的地方在于，你能真正看到所有受影响的 URL——被重定向的 URL、重定向链中的 URL，以及链接到被重定向 URL 的那些 URL。
这里你应该做两件事。
第一件是拆分重定向，在这种情况下：
https://blog.example.com/123/> -> 301 重定向 -> >https://example.com/blog/987/
这样就能确保指向 https://blog.example.com/123/ 和 https://example.com/blog/123/ 的所有反向链接都只被重定向一次。对外部反向链接来说这没问题，因为联系网站站长请求修改链接会非常低效，而且相当烦人。
不过，在内部我们可以做得更好。
你应该力求把重定向次数降到最少。这时“入站链接数”（inlinks）这一列就派上用场了。
入站链接是指那些链接到受重定向链影响的 URL 的 URL。你会希望把这些页面上的链接替换为返回 200 HTTP 状态码的 URL。如果你点击入站链接的数量，就会看到所有这些链接：
当然，下一步同样是检查重定向链中 URL 的入站链接。不过，这属于较低优先级，因为我们已经打破了重定向链。在下一次抓取时，这些链接会被标记为 3XX 重定向报告中的标准 301 重定向。
最后总结
HTTPS 对网站安全至关重要，如今用户和搜索引擎都期望网站使用 HTTPS。随着 Chrome 2026 年“默认使用 HTTPS”的推出日益临近，现在正是确保你的网站配置得当的最佳时机。
迁移过程可能很复杂，但其好处——更高的安全性、更好的 SEO 信号、保留的引荐数据，以及可使用 HTTP/3 等现代协议——都让它值得去做。
使用 Ahrefs Webmaster Tools 来审计你的 HTTPS 实施情况，并在常见迁移错误影响你网站表现之前发现它们。借助 Always-on Audit 和 Patches 等功能，你可以持续监控问题，无需等待开发者就能修复它们。