11 种重定向类型及其对 SEO 的影响

重定向（redirect）用于在页面位置发生变化时，把请求旧 URL 的人和机器人引导到新 URL。

在美国搬家时，你会向美国邮政署（USPS）设置邮件转寄服务。如果有人把邮件寄到你的旧地址，USPS 会查阅邮件转寄规则，发现你已经不住在旧地址了，于是把这封信改投到新地址，而不是旧地址。

重定向的原理与此相同。用户或机器人请求旧地址时，会被转发到新地址。例如，我们前一段时间把 blog.ahrefs.com 迁移到了 ahrefs.com/blog。尝试访问 blog.ahrefs.com，就会被转发到这个新 URL。看看会发生什么。

何时使用重定向

以下情况会用到重定向：

• 迁移网站或页面
• 希望合并重复页面
• 合并网站
• 删除页面后把用户引导到新页面
• 更改 URL 结构或整理 URL

重定向的类型及其对 SEO 的影响

重定向有助于在页面之间整合各种信号，并帮助搜索引擎确定该向用户展示哪个页面。这个过程叫做规范化（canonicalization），Google 用它来避免重复页面进入索引。可见，重定向对 SEO 很重要。

在 SEO 圈子里，围绕重定向流传着许多误区和误解，希望这篇文章能把它们讲清楚。

重定向可以是永久的，也可以是临时的，取决于你是否打算长期保留它。这也会影响哪个页面会被索引并展示在搜索引擎中，下一节会详细说明。

重定向也可以是服务器端的——发生在某台服务器上；或者客户端的——发生在用户的浏览器里。

下面几张表格对不同类型的重定向做了分类，可供参考。下一节会逐一详细介绍。

实施永久重定向该选哪种方法，推荐的优先顺序是：308 / 301 > Meta refresh 0 / HTTP refresh 0 > JavaScript > Crypto

实施临时重定向该选哪种方法，推荐的优先顺序是：307 / 302 / 303 > Meta refresh 0 / HTTP refresh 0

服务器端重定向不一定发生在你的主机服务器上，也可能发生在“别人的服务器”上，比如 CDN 或你的域名服务商。客户端重定向也可以通过多种方式添加，但它们始终在用户的浏览器中触发。

以下是你可能遇到这些重定向的一些位置：

下面更详细地看看它们。

永久重定向

永久重定向表示某个资源已永久迁移到新位置。

以下情况应使用永久重定向：

• 永久更改网页或其他资源的 URL。
• 永久迁移到新域名。
• 从 HTTP 切换到 HTTPS。
• 修复非 www/www 的重复内容问题。
• 永久合并两个或更多页面或网站。
• 永久更改网站的 URL 结构。

永久重定向是很强的规范化信号，它表明页面上的信号（例如链接）应向前整合到新 URL 指向的页面上。最终通常由新页面承接全部信号，并出现在搜索引擎中。

假设你把一个页面从 site1.com/x 重定向到 site2.com/x，内容没有变化，那么链接信号会在 site2.com/x 上整合。也就是说，如果 site1.com/x 有 10 条反向链接，site2.com/x 会像这些链接直接指向自己一样获得它们的价值。

只有当重定向不相关时，才不会发生这种情况，因为Google 会把不相关的重定向当作软 404 处理。

例如，把一篇博客文章重定向到首页。两个页面完全不同，Google 可能不会整合链接信号。

想知道 Google 如何对待某个重定向？

方法如下：

1. 打开 Google Search Console
2. 进入“链接”（Links）>“外部链接”（External Links）>“链接最多的页面”（Top linked pages）
3. 在报告中找到那个“新”URL 并点击它（可以用“目标页面”筛选器来帮忙）
4. 按“站点”（Site）筛选链接，然后逐个粘贴指向旧页面的引荐域名（你可以在 Ahrefs 的 Site Explorer（站点分析）中的“引荐域名”（Referring Domains）报告里找到它们）

如果好几个引荐域名都匹配不到结果，说明 Google 很可能把这个重定向当作软 404，不会把旧页面的反向链接算到新 URL 上。

如果匹配到了，就点击该站点查看实际链接。如果你在“目标 URL”（Target URL）列中看到旧 URL，说明 Google 正在把链接整合到新 URL 上。

下面看看几种永久重定向的类型。

HTTP 301

301 重定向是服务器端重定向，它把机器人和用户转发到新 URL，并告诉搜索引擎该资源已永久迁移。

HTTP 308

308 重定向与 301 相同，区别在于执行重定向时会保留原始请求的 HTTP 方法（GET 或 POST）。从 SEO 角度看两者一致，但如果你有通过表单发送的数据，就不希望在 GET 和 POST 之间来回切换。

JavaScript 重定向

JavaScript 重定向用 JavaScript 指示浏览器把用户或机器人重定向到另一个 URL。

这种重定向需要先渲染页面才能触发，属于客户端重定向，因此并不推荐。Google 会渲染每一个将要索引的页面，但渲染可能出问题而失败。其他重定向类型得到的支持更好，也更可靠。

下面示例展示该重定向在 HTML 中可能的样子：

JavaScript 重定向也可能出现在配置文件中。Next.js 配置里有一个 redirect 函数，可用来设置重定向。在其他系统中，你可能会在路由器（router）里找到它们。

Meta refresh（=0 秒）

Meta refresh 重定向告诉浏览器在设定的秒数之后跳转。它发生在浏览器中，属于客户端重定向。

Meta refresh 重定向需要放在 HTML 的 <head> 部分。它们的样式如下：

HTTP refresh（=0 秒）

HTTP refresh 类似 meta refresh，但发生在 HTTP 响应头中。它可以在服务器端实现，实际却在客户端触发。

它的样式如下：

加密重定向（Crypto redirect）

一个并不真正执行跳转的“重定向”？听起来很怪，但 Google 会把它当作永久重定向处理，也就是说它们也应把所有信号向前传递到新 URL。

加密重定向是一种特殊情况：页面上有迁移到新域名的说明，却没有发生实际跳转。它的样式如下：

我会尽量改用其他重定向方法，因为并不是每个机器人或搜索引擎都支持加密重定向。

临时重定向

临时重定向表示某个资源暂时迁移到了新位置。

以下情况应使用临时重定向：

• 想根据用户的位置/语言，把他们引导到最适合的网站版本。
• 想对网页的功能或设计做 A/B 分流测试。
• 做促销活动时，想把访客临时引导到一个销售页面。

临时重定向是较弱的规范化信号，它暗示页面上的信号（例如链接）应向前整合到新页面。由于信号较弱，多数情况下信号实际上会整合回原来被重定向的页面。

不过在某个时间点，累积的信号可能足够多，使临时重定向最终向前整合。一段时间内，你可能看到原始 URL 被 Google 索引、信号也整合在那里；一旦发生这种“互换”，你会在 Google 中看到新 URL，信号也随之整合到新 URL 上。

临时重定向需要存在多久，Google 才会把它当作永久重定向处理，并没有固定时间。通常是几周到几个月，也可能只有几天。

这种“互换”也可能永远不发生，例如国际网站用 302 把用户引导到最合适的首页版本。这种配置被许多网站用了近十年，它们的原始 URL 至今仍被索引。

在某些情况下，Google 甚至似乎从一开始就把临时重定向当作永久重定向处理。

例如，我做过一个实验，把一个已有一定权重的网站用 302 重定向到另一个网站。Google 看到这个重定向后，就把旧域名从搜索结果中撤下，转而采用“新”域名。

如果你不确定 Google 如何对待某个临时重定向，可以把被重定向的 URL 粘贴到 Search Console 的 网址检查（URL Inspection）工具中。若它显示“网址不在 Google 上”的警告，说明 Google 正在把这个重定向当作永久处理；若它仍在 Google 上，说明 Google 把它当作临时处理。

这样做时，务必查看最近一次抓取日期。如果这个日期晚于你添加重定向的时间，就请求重新索引，然后再回来查看。

下面看看几种临时重定向的类型。

HTTP 302

302 重定向把用户转发到新 URL，并告诉搜索引擎该资源已临时迁移。

HTTP 307

307 重定向与 302 相同，区别在于执行重定向时会保留原始请求的 HTTP 方法（POST、GET）。从 SEO 角度看两者一致，但如果你有通过会重定向的表单发送的数据，就不希望在 GET 和 POST 之间来回切换。

排查重定向问题时，你可能会看到一种不同的 307，它是发生在浏览器中的缓存重定向。这与 HSTS 有关，它告诉浏览器在请求不安全资源时改用安全连接（HTTPS）。

当 Web 服务器要求客户端只能使用 HTTPS 连接（HSTS 策略）时，Google 看不到这个 307，因为它缓存在浏览器中。首次访问（没有缓存）时，服务器返回的响应码很可能是 301 或 302。浏览器在后续请求中则会显示 307，这让排查更困难。你需要用一个全新的无痕会话才能看到返回的状态码。

HTTP 303

303 重定向把用户转发到与所请求资源相似的资源，属于临时重定向。它通常用于防止用户点击浏览器“返回”按钮时重复提交表单这类场景。把 303 用于 SEO 目的并不常见，即便有，也会被当作 302/307 处理。

Meta refresh（>0 秒）

meta refresh 等于 0 秒时，被当作永久重定向；大于 0 秒时，被当作临时重定向。

Meta refresh 重定向告诉浏览器在设定的秒数之后跳转。它发生在浏览器中，属于客户端重定向。

Meta refresh 重定向需要放在 HTML 的 <head> 部分。它们的样式如下：

HTTP refresh（>0 秒）

HTTP refresh 等于 0 秒时，被当作永久重定向；大于 0 秒时，被当作临时重定向。

HTTP refresh 类似 meta refresh，但发生在 HTTP 响应头中。它可以在服务器端实现，实际却在客户端触发。

它的样式如下：

服务器端重定向

服务器端重定向指：页面被请求时，由服务器决定把用户或搜索引擎引导到哪里。它们通常对应 301、302、303、307 或 308 状态码。

服务器端重定向是做 SEO 重定向的首选方式。

服务器级别

这些重定向发生在你自己的服务器上，具体如何实现取决于网站主机和后端所用的服务器环境或脚本语言。常见的服务器类型都有完善文档，最常用的有 Nginx、Apache、Cloudflare Server、LiteSpeed、Microsoft-IIS 和 Node.js。

如果你在 WordPress、Shopify、Wix、Squarespace、Joomla 或 Drupal 这类 CMS 上，通过插件或自定义方案输入重定向，这些重定向实际上是在服务器级别添加的。

大多数 WordPress 站点运行在 Apache 上，用于重定向的插件实际上是在编辑网站的 .htaccess 文件。这个文件位于网站根目录。

要在 .htaccess 中创建一个从某页面到另一页面的重定向，可以添加：

也可以用不同的语言（比如 PHP）实现重定向，样式如下：

301 重定向的文章里有更多示例，包括重定向域名、www 到非 www、非 www 到 www， HTTP 到 HTTPS。重定向也可能位于服务器配置文件中。

在许多常见系统中，输入一个重定向就会自动触发。不过有些系统的工作方式像错误捕获器：你输入了重定向，但只有在删除旧页面之后它才触发。这给流程增加了一步，但更不容易出错。

DNS 级别

域名服务器通常由域名注册商管理，也可能由 CDN 管理。各家服务商略有不同，但通常都能找到相应文档。

这一级别的重定向常用于网站迁移。有些主机允许为重定向指定状态码，比如 301 或 302。

有些服务商甚至允许对页面的 HTTPS 版本进行重定向。严格来说，HTTPS 在这一级别并不存在，过去也没有这个选项，但一些服务商已经找到了实现它的办法。

CDN 级别

许多 CDN 提供多种实现重定向的方式。例如在 Cloudflare 上，可以做单个或批量重定向，有专门的重定向规则（redirect rules），可以编写带重定向的 Page Rule，可以用 Workers 和键值对（key-value pairs）实现重定向，也可以用 Workers 修改响应头并添加重定向。

相比把重定向放在服务器上，我个人通常更倾向于放在边缘（CDN 级别）。对其他人，我总是建议选择最容易实现的方式，对很多人来说那就是服务器级别的重定向。

客户端重定向

客户端重定向由用户的浏览器触发。在重定向发生之前，用户可能会短暂地看到某个页面。

一般来说，除非别无选择，否则不应在客户端做重定向。

HTML

前面已讨论过 meta refresh 重定向和 JavaScript 重定向，它们都在客户端触发。

Meta refresh 重定向需要放在 HTML 的 <head> 部分。它们的样式如下：

下面是一个 JavaScript 重定向在 HTML 中可能的样子：

HTTP 响应头

HTTP refresh 类似 meta refresh，但发生在 HTTP 响应头中。它可以在服务器端实现，实际却在客户端触发。

它的样式如下：

CDN 级别（特定情况下）

前面提到过 Cloudflare Workers，它让你可以在内容被提供给用户之前，在边缘进行修改。你实际上可以重写部分 HTML，以加入像 meta refresh 这样的客户端重定向，不过这种做法并不常见，因为有更好的办法。

重定向的最佳实践

以下是重定向相关、值得检查的一些事项。

将 HTTP 重定向到 HTTPS

每个人都应该使用 HTTPS。

检查网站是否正确地从 HTTP 重定向到 HTTPS，有几种方法。第一种是安装并启用 Ahrefs 的 SEO Toolbar（SEO 工具栏），然后尝试访问首页的 HTTP 版本，它应该会发生重定向。

这里通常希望看到 301 或 308 重定向，因为这种重定向应当是永久的。

不过，如果你的网站像我们的 Ahrefs 一样使用了 HSTS，你可能会看到 307 重定向。

这种 307 在浏览器中触发，你仍需要检查服务器响应，确认它是不是 301 或 308。

还有另一种方法：

• 进入 Ahrefs 的 Site Audit（站点审计）
• 点击“+ New Project”（新建项目）
• 点击“Add manually”（手动添加）
• 把“Scope”（范围）改为 HTTP
• 输入你的域名

你应该会看到首页的 www 和非 www 两个版本都出现“Not crawlable”（无法抓取）错误，同时还有“301 moved permanently”（301 永久移动）的提示。

使用 HSTS（以产生 307 重定向）

在服务器上实施 HSTS（HTTP 严格传输安全）可以阻止人们访问网站上的非安全（HTTP）内容。它的原理是告诉浏览器：你的服务器只接受安全连接，对于任何被要求访问的 HTTP 资源，浏览器都应 307 重定向到其 HTTPS 版本。

请记住，这发生在浏览器内部，机器人不会看到这个特定版本的 307。

实施 HSTS 之后，可以考虑把网站提交到 HSTS preload 列表。这样，所有尝试访问你网站的人（即便之前从未访问过）都会启用 HSTS。

把相关旧内容做重定向

网站乃至整个网络总在变化。我们做过一项研究，发现在我们考察的九年时间里，网络上指向页面的链接约有三分之二消失了。

很多时候，你的旧 URL 上有来自其他网站的链接。如果没有把它们重定向到当前页面，这些链接就丢失了，不再为你的页面产生价值。现在做这些重定向还不算晚，可以迅速找回丢失的价值，帮助内容获得更好的排名。

下面介绍如何找到这些机会：

• 把你的域名粘贴到 Site Explorer 中（也可以在 Ahrefs Webmaster Tools 中免费使用）
• 进入“Best by links”（按链接排序）报告
• 添加一个“404 not found”（404 未找到）的 HTTP 响应筛选器

我通常会按“Referring domains”（引荐域名）排序。

我甚至写了一个帮助匹配重定向的脚本。不必被吓到，你只需下载几个文件再上传即可。这个 Colab notebook 会一步步引导你操作，替你完成繁重的工作。

避免过长的重定向链

重定向链指在一个被请求的资源与其最终目的地之间发生了多次重定向。

Google 的官方文档称，Googlebot 最多会跟随 10 次重定向跳转，因此比这更短的重定向链通常不会对 SEO 造成问题。它在一次会话中会跟随 5 跳，并在下次会话时从上次中断的地方继续。

如果抓取程序在 10 跳之内没有获取到内容，Search Console 会在网站的“索引覆盖情况”（Index Coverage）报告中显示一个重定向错误。

很多 SEO 痴迷于连一次多余的重定向跳转都要消除，我完全不为此担心。

如果重定向链少于 5 跳，我通常不会担心；超过 5 跳之后，我见过它们在抓取和正常计入方面出现问题，因此这就是我建议开始处理的临界点。

可以使用 Ahrefs Webmaster Tools 免费查找过长的重定向链：

• 用 Site Audit 抓取你的网站
• 进入“Redirects”（重定向）报告
• 点击“Issues”（问题）选项卡
• 查找“Redirect chain too long”（重定向链过长）错误

点击该问题并选择“View affected URLs”（查看受影响的 URL），即可看到作为重定向链起点的 URL 和链中的所有 URL。

避免重定向循环

重定向循环是一种无限的重定向循环，当某个 URL 重定向到它自身，或重定向链中的某个 URL 又重定向回链中更靠前的 URL 时就会发生。

它会带来三个问题：

• 对用户而言——它们切断了用户访问预期资源的途径，并在浏览器中触发“too many redirects”（重定向次数过多）错误。
• 对机器人和搜索引擎而言——它们会“困住”抓取程序，浪费抓取预算。
• 对服务器而言——它们会浪费你的资源。有些机器人能较好地处理这种情况，有些则不能，它们可能以持续不断的 DDoS 攻击拖垮你的服务器。

查找重定向循环最简单的方法，是用 Ahrefs 的 Site Audit 这类工具抓取你的网站。用一个 Ahrefs Webmaster Tools 账户即可免费完成。

• 用 Site Audit 抓取你的网站
• 进入 Redirects（重定向）报告
• 点击 Issues（问题）选项卡
• 查找“Redirect loop”（重定向循环）错误

点击该错误并点击“View affected URLs”（查看受影响的 URL），就会看到一份发生重定向的 URL 列表，链中的所有 URL：

修复重定向循环的最佳方式，取决于链中最后一个 URL（循环之前的那个）是否是你真正想要的最终目的地。

如果是，就从最终 URL 上移除重定向。然后确认该资源可以访问，并返回 200 状态码。

如果不是，就把造成循环的重定向改为指向你真正想要的最终目的地。

无论哪种情况，把任何指向残留重定向的内链换成直接指向最终 URL 的链接，都是个好习惯。

避免过于宽泛的重定向

创建重定向规则时，有时人们会匹配某个文件夹之后的所有内容，导致一大堆页面可能被重定向到同一个页面。应尽可能让重定向保持 1:1 匹配。

可以在域名后输入 domain.com/asfkljlkdfs 之类的内容来测试，也可以试试你的一些主要文件夹。如果返回 404 页面，那就没问题；如果它发生了重定向，说明有人设置了过于宽泛的规则。

这些规则不一定有害，但可能把用户带到意想不到的地方。某些情况下它甚至可能有害。假设你网站曾被入侵，被添加了一堆页面，还建了链接指向这些页面。如果你删掉这些页面，又把它们重定向到某处，基本上就等于在宣称那些垃圾链接属于你。

注意过期的证书

如果你迁移到了其他域名，而旧站点使用的是 HTTPS，那么当证书过期后，机器人可以通过，但用户会收到错误提示，并且不会被重定向。

有一种覆盖多个网站的多域名证书，可以帮助避免这个问题。现在有些 DNS 服务商也允许 HTTPS 重定向，这也能防止这种情况发生。

至少保留重定向 1 年

据 Google 的说法，你应该让重定向至少保持启用一年。在那之后，信号应该会永久传递过去。

如果你不信，我做了测试，结果看起来确实如此。

我主张尽可能长久地保留重定向，甚至可能永久保留。移除任何重定向之前，还应检查是否仍有用户在访问旧页面。

迁移时别忘了重定向其他文件

迁移时，除了页面之外，把图片、PDF 这类文件也做重定向是个好主意，尤其当它们曾为网站带来可观流量时。不必操心 JS、CSS 或字体文件。重点是为会被搜索引擎索引的内容做重定向，其他文件类型无需在意。

SEO 重定向问题排查

以下是一些帮助你排查重定向问题的技巧。

弄清楚重定向存在于哪个系统中

在企业级环境中，情况可能会变得复杂。你可能有多套不同的系统可以输入重定向，而你需要弄清楚到底是哪一套实际触发了重定向。

你可以利用 HTTP 响应头中的信息判断可能是哪个系统触发了重定向。例如，我们的博客使用了一个叫 Redirection 的插件，它会添加一个 X-redirected-by 响应头标签，表明正是它触发了重定向，正如下面 Site Audit 的 URL 概览中所显示的那样。

我们的 SEO Toolbar 是另一个选项，让你在浏览时快速检查响应头。

重定向可能只针对特定的 user-agent 发生

重定向可以使用条件逻辑，也就是说它们只在某些条件下发生，比如针对指定的 user-agent。你可以用我们的 SEO Toolbar 更改 user agent，看看重定向是否针对某个特定 user-agent 触发。

重定向可能会返回错误的状态码

不要盲目相信所显示的状态码。任何状态码下都可能仍在发生重定向。你的页面可能显示为 200 OK 状态码，实际上却仍在重定向到另一个位置。

结语

处理可用于批量 URL 重定向的匹配模式时，正则表达式能帮你省下大量时间。去 Google 搜一份指南或速查表，再找一个好用的正则测试工具。我通常用 regex101。

有问题？在 X 或 LinkedIn 上给我留言。