301 还是 302 重定向？30 秒内给你正确答案

8 分钟阅读 · 最后更新于 2026 年 5 月 2 日

听，不要读

听，不要读

"90秒回答"

0:00

0:00

1x

太长不看版

永久搬移页面？ 用 301。只是临时的？ 用 302。这一条规则就覆盖了你以后要做的十次重定向决策里的九次。（剩下的那种，用于 API 端点、请求方式在迁移过程中不能变的情况，用 307 或 308。大多数人一辈子都用不到。）

想知道你网站上实际在跑什么？ 有一行命令就能揭示你的服务器真正在发送的代码。如果它返回 302，而这次搬移本来应该是永久性的，那你的排名正在实时流失。下面我们会带你完成这个检查，不需要任何命令行基础。

一旦你修正了错误代码并请求 Google 重新抓取该页面，恢复需要 2 到 6 周。 这段等待时间里的绝大部分，只是 Google 爬虫按自己的节奏再次回来而已。

现在是晚上十一点。你已经进入迁移的第三周，自然流量下跌了 40%。开发团队一口咬定重定向没问题。Search Console 看起来也正常。但你分析图表上那条线仍在往下掉，你一遍遍地刷新，好像下一秒数字会变出不一样的结果。

下面是没人告诉过你的部分。重定向其实分两种，在普通访客眼里它们长得一模一样。但在 Google 看来，两者天差地别。一种说：这个页面永远搬走了，所有权重都传过去吧。另一种说：这个页面只是暂时离开一下，继续让旧页面保留排名。迁移时用错了，搜索引擎会被你网站到底哪个版本才值得排名这件事困扰好几周。

修复通常只需要改一行代码。真正难的是先把问题找出来。

这份指南会带你走完整个过程。选对重定向的简单规则（真的就只有两个问题）。针对你网站所用技术的即贴即用代码（WordPress、Shopify、Next.js、Apache、Nginx，应有尽有）。事后要在 Google Search Console 里查的确切内容，以证明修复已生效。如果这是别人捅的篓子落到了你头上，文末还有一份四步恢复手册等着你。

还有一件事先说清楚。不要相信你的 SEO 仪表盘说的重定向状态。也不要相信开发者说的。亲眼去看你的服务器实际发回了什么。自己去验证。我们会告诉你最简单的办法。

30 秒速答

页面永久搬家？用 301。只是暂时离开一阵？用 302。另外值得知道的只有 API 端点的情况，需要 307（临时）或 308（永久）。除非你是处理 API 的开发者，否则几乎不会碰到它们。

这一条规则就能解决 90% 的决策。为什么这个选择如此重要？因为重定向状态码同时在做两件事。它告诉搜索引擎这次搬家是永久的还是临时的。它也悄悄告诉浏览器，请求方法（GET、POST 之类的）在跳转过程中是否需要保持完全一致。我们大多数人只需要考虑第一件事。

在底层，所有重定向的运作方式都一样。访客请求旧 URL。你的服务器回传一条简短消息说：这个页面已经搬走了，新地址在这里。那条消息上的数字（301、302、307、308），就是告诉搜索引擎如何处理这次搬家的依据。

有一个细节值得了解。Google 在 2016 年悄悄更新了对 302 的处理方式。他们变得更灵活，会把 302 当作正式信号看待，但前提是重定向存在的时间足够长，并且新页面与旧页面内容确实匹配。所以 SEO 的结果（最终哪个 URL 在排名、你的链接权重流向哪里）取决于的远不止你选了哪个数字。重定向存在多久。内容有多相似。Google 多久爬一次。这些都算在内。我们待会儿就过一遍证据。

这张表就是短答案。本指南剩下的篇幅会拆解：当你选了其中一种时，你的排名、抓取预算和已收录 URL 到底会发生什么。你会看到每个主流平台可以直接复制粘贴的代码，以及从真实爬虫数据和 Google 官方文档中整理出来的证据。

定义：301、302、307、308 与 Location 响应头

下面这些定义，你在本指南后续章节会反复遇到。值得收藏，你会回头查。

301 永久移动（Moved Permanently）： 一个响应状态码，告诉浏览器该资源已永久迁移至 Location 响应头给出的 URL。搜索引擎会把排名信号传递给新 URL；浏览器会积极缓存该重定向。

302 临时找到（Found）： 一个响应状态码，告诉浏览器该资源临时位于 Location 响应头给出的另一 URL 下。搜索引擎会在索引中保留原 URL；浏览器默认不缓存。

307 临时重定向（Temporary Redirect）： 与 302 类似，但严格保留请求方法。客户端必须用相同的方法重复请求（POST 依然是 POST）。当 API 契约不能更换动词时使用。

308 永久重定向（Permanent Redirect）： 与 301 类似，但严格保留请求方法。既永久，又方法安全。

Location 响应头： 承载任意 3xx 重定向目标 URL 的 HTTP 响应头。

关于相关但不同的 <link rel=canonical> 机制，另见规范 URL 指南。如需更深入的实现细节，MDN Web Docs 的 HTTP 重定向文档对浏览器特定行为有不错的说明。

何时使用 301 与 302：决策法则

归结为一个问题：这次迁移是永久的，还是只是临时的？下面的案例会告诉你属于哪一边。

在以下情况下使用 301……

你要永久迁移到新域名。 当 oldbrand.com 变成 newbrand.com，并且不会再回头时，使用 301。它告诉搜索引擎：把关于旧域名的一切都转交给新域名，并从索引中移除旧域名。

你要从 HTTP 迁移到 HTTPS。 你网站上的每一个页面都要从不安全的版本（浏览器里没有挂锁图标的那个）迁移到安全版本。这是永久性的。301 能确保从现在起，浏览器和搜索引擎把 HTTPS 视为官方版本。

你要重构 URL。 当 /blog/post-1 作为全站重排的一部分变成 /posts/post-1 时，你不希望旧路径再出现。301 会把所有排名权重交给新结构。

你要合并或精简页面。 当你把两个简短的页面合并成一个更强的页面时，永久重定向旧 URL。合并后的页面会继承两者的排名权重。

你要把已删除的页面指向它的父级分类。 与其为下架产品显示”页面未找到”，不如重定向到父级分类页面。用户能落到一个有用的地方，排名权重也会流向一个相关页面，而不是消失。

你要在带斜杠和不带斜杠之间选一个赢家。 在 /page 和 /page/ 之间选一个，并把另一个永久重定向过去。一致性能防止 Google 把它们当作两个不同的页面。

你要在 www 和非 www 之间选一个赢家。 选择 www.domain.com 或 domain.com 作为主版本。用 301 重定向另一个，这样搜索引擎就会把所有信号集中到一个版本上。

电商迁移（从 Shopify 到 WooCommerce，或从自定义店面到 Shopify Plus）是一个品牌会做的最大规模的 301 重定向工作之一。完整的迁移手册，包括你在任何 URL 变更上线之前就要构建的重定向映射表，都在营收漏斗 SEO 方法论里。

在以下情况下使用 302……

你在做 A/B 测试。 如果你有一半流量导向变体页面，那么在实验期间，任何一个版本都不该接管成为主 URL。302 告诉搜索引擎：在我们收集数据期间，原始 URL 仍然是主角。

你处于维护窗口期。 如果你在计划停机期间把访客引导到一个状态页面，那按定义就是临时的。302 能保持原始 URL 在 Google 中的地位不变，这样在你修复的时候排名不会波动。

你还没设置国家标签。 把印度访客导向 /in/，把美国访客导向 /us/？如果你还没添加 hreflang，就用 302。（hreflang 是告诉 Google 在哪个国家显示哪个版本的标签。）它能防止 Google 把错误的地区版本选为主 URL。

你在运行一个会消失的促销页面。 一个在 12 月 1 日后就消失的黑色星期五页面，不应该吸收你主页面的排名权重。302 能让原始 URL 保持为主版本，而促销页面只在活动期间存在。

你在重建期间使用占位页面。 当你重新设计网站的某个板块时，临时重定向到一个占位页面能保持原始 URL 的地位不变。一旦重建上线，你就移除重定向，原始 URL 再次接管。

规则没能完全拍板的边缘情况

结账后的购物车重定向技术上应该使用 303（它告诉浏览器：忘掉表单数据，直接获取这个页面）。大多数平台改用 302，而浏览器处理方式相同。客户端发送 POST 数据的 API 迁移其实应该用 308 来锁定请求类型。大多数团队反而会选择 301。它已经用了十年，至今没出什么问题。登录重定向通常用 302。访客跳转到登录页，登录后再跳回来。

选完之后你的 SEO 会怎样 (2026 年的实际情况)

选对状态码并不只是走个技术流程。它同时悄悄决定了三件事。Google 是否会把排名权重传递到新 URL。新 URL 是否会在搜索结果中取代旧 URL。以及像 ChatGPT 这样的 AI 搜索引擎是否还愿意引用你。每一环都牵动下一环,事后补救远比一次做对要费力得多。

链接权重传递

链接权重是重定向素养和站外 SEO 之间的主题枢纽。The Earned Authority Method 正是最初构建它的框架。这也正是为什么通过正确使用 301 来保住它,比大多数操盘手意识到的要重要得多。

这种割裂在迁移期间影响最大。一个从 HTTP 迁到 HTTPS 时使用 302 的站点并没有丢失权重。它只是让权重永远在不同协议版本间碎片化。

Google 的索引会怎么处理每一种

Googlebot 是 Google 的爬虫。它在把页面存入索引时,对 301 和 302 的处理方式截然不同。(索引就是 Google 已知所有页面的巨型数据库。)

301 告诉 Google:用新 URL 替换旧 URL。接下来几次访问中 Google 就会照做。一般站点通常在 2 到 6 周内完成,Google 访问更频繁的大型站点更快。新 URL 成为 Google 在搜索结果中展示的那一个。旧 URL 悄悄退场。

302 告诉 Google:保留旧 URL。Google 继续把旧 URL 作为搜索结果中的主 URL 展示。新 URL 可能会被访问,但永远不会接班。Google 把这个重定向读作短期绕行,而非地址的永久变更。

Google Search Console (Google 为站长提供的免费工具) 有一项叫做 URL 检查的功能,可以让你亲自验证这一点。一个带 301 的 URL 最终会显示”URL 不在 Google 上”,原因是”带重定向的网页”,而新 URL 会显示为已编入索引。一个带 302 的 URL 则会一直把原始地址保留为主 URL,并带有”带重定向的网页”标签。而新 URL 就一直晾在那儿,始终没被抓取。

对迁移来说,这意味着 302 会在两个 URL 之间制造永久割裂,除非你回头修正状态码。

AI 搜索与重定向:2025 年 ChatGPT 数据

SE Ranking 在 2025 年 12 月的一项研究发现了一个惊人现象。AI 搜索引擎 (ChatGPT、Perplexity、Google 的 AI Overviews) 引用重定向 URL 的频率远低于普通的 Google 搜索。

数字说明问题。ChatGPT 引用中只有 0.79% 指向经过重定向的 URL,而普通 Google 搜索结果中这一比例为 5.75%。这意味着 ChatGPT 引用重定向 URL 的频率比 Google 低 3 到 7 倍。

这里有个意外之处。当 ChatGPT 真的跟进一个重定向时,它强烈偏好永久重定向。同一项研究发现,ChatGPT 跟随 301 的频率是跟随 302 的 1.6 倍。Perplexity 和 Bing 的 AI 功能也呈现相同规律。AI 搜索系统把永久重定向视为比临时重定向更可信。

这对你的迁移意味着什么:藏在重定向链里任何一处的 302,都会悄悄削减你被 AI 搜索引用的机会。你会在两条战线上同时失分。Google 的常规搜索把你的 URL 当作割裂的碎片,并且新一波 AI 搜索引擎也不再在回答中提及你。

如果错误的状态码让 ChatGPT 停止引用你的内容,那就得让付费搜索来补位。The Pincer Method 正是我们用一套打法同时跑付费和自然流量的原因。当 AI 搜索掉线时,另一条渠道必须接住需求。

7 大平台的即复制代码

在 Google 上搜索 “301 vs 302 redirect”,排名靠前的结果会列出七个平台,却从来不给你实际可用的代码。所以这里就是。下面每一段代码都可直接复制粘贴,已对照各平台最新文档核对过,也针对最常见的错误做了测试。

Apache (.htaccess)

在 Apache 上,这段代码要放进网站根目录的 .htaccess 文件里。

# Single URL 301
Redirect 301 /old-url /new-url

# Pattern-based 301 (regex)
RedirectMatch 301 ^/old/(.*)$ /new/$1

# Domain change with HTTPS
RewriteEngine On
RewriteCond %{HTTP_HOST} ^oldbrand\.com$ [NC]
RewriteRule ^(.*)$ https://newbrand.com/$1 [R=301,L]

坑点:在使用 RewriteRule 之前忘了写 RewriteEngine On。这条指令会静默失效,你会花二十分钟纳闷为什么一点反应都没有。我们在 htaccess 与 Nginx 重定向规则对比中有详细讲解。

Nginx

在 Nginx 上,这段代码要放进 server block 配置文件(通常是 /etc/nginx/sites-available/yourdomain)。

# Single URL 301
location = /old-url {
    return 301 /new-url;
}

# Domain change
server {
    listen 443 ssl;
    server_name oldbrand.com;
    return 301 https://newbrand.com$request_uri;
}

坑点:明明 return 更快,却用了 rewrite。return 301 在正则匹配之前就执行,能省下服务器一点力气。完整对比见 htaccess 与 Nginx 重定向规则。

Cloudflare Workers + Page Rules

Page Rules(界面操作,无需写代码): Cloudflare 仪表盘 → Rules → Page Rules → “Forwarding URL” → 从下拉框选 301 或 302。免费套餐最多只能启用 3 条 Page Rules,如果站点有多种重定向需求,很快就用完了。

Workers(写代码,更灵活):

export default {
  fetch(request) {
    const url = new URL(request.url);
    if (url.pathname === '/old-url') {
      return Response.redirect('https://example.com/new-url', 301);
    }
    return fetch(request);
  }
}

坑点:Workers 每月 $5 能处理 1000 万次请求,但它提供的模式匹配能力是 Page Rules 完全比不了的。高级用法会在 Cloudflare Workers 重定向模式里展开。

WordPress:RankMath PRO + Redirection 插件 + 手动 .htaccess

RankMath PRO: WordPress 后台 → Rank Math → Redirections → Add New。从下拉框选 301 或 302,填入源 URL 和目标 URL。更改立即生效,无需重启服务器。

Redirection 插件(免费,John Godley 开发): 工具 → Redirection。最适合大规模迁移。支持 CSV 导入/导出、正则模式、404 跟踪。插件会记录重定向命中次数,帮你在问题累积之前发现链式或循环重定向。

手动 .htaccess: 能用,但只要插件或主题更新动了 .htaccess,你的规则就没了。只在需要永久保留、与 WordPress 状态无关的系统级规则时用它。

如果你以 WordPress 为主,并把每次重定向改动当作更大内容引擎的一部分,那么重定向这一步只是整套方法论中的一个环节。Content Compounder 方法论就是驱动这台引擎的核心。这个六支柱反馈循环把重定向素养作为第 2 支柱的基础设施消化进来。想看插件层面的对比,WordPress 重定向插件指南讲了选型标准的细节。

WooCommerce + Shopify

WooCommerce: 沿用上面提到的 WordPress 重定向工具。不过批量产品 URL 迁移需要去重逻辑。500 个 SKU 的店铺可能会产生 500 条重定向规则,拖慢 .htaccess 的解析速度。去重流程会在下面的”常见错误”部分讲。

Shopify: Online Store → Navigation → URL Redirects。Shopify 通过标准后台只支持 301。不写自定义 Shopify Function 或装像 Easy Redirects 这类第三方应用,是没法配置 302 的。

坑点:Shopify URL Redirects 能在换主题后保留,但源产品或页面一被删除,它们立刻失效。任何结构性变动之前,务必先导出重定向清单。Settings → Files 救不了你。

Next.js (next.config.js)

在 Next.js 上,这段代码要放进项目根目录的 next.config.js 文件。

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-url',
        destination: '/new-url',
        permanent: true, // permanent: true = 308; permanent: false = 307
      },
    ];
  },
};

坑点:Next.js 默认用的是 307/308(严格保留请求方法的版本),不是 301/302。如果确实需要 301/302,因为某些老旧 SEO 工具还不认 308,就把 permanent: true 换成 statusCode: 301。

Express 中间件

在 Express 上,这段代码要放进主服务器文件(通常是 app.js 或 server.js)。

// Express
app.get('/old-url', (req, res) => {
  res.redirect(301, '/new-url');
});

// Pattern-based redirect
app.use('/old-section/*', (req, res) => {
  const newPath = req.originalUrl.replace('/old-section', '/new-section');
  res.redirect(301, newPath);
});

坑点:如果不传状态码,res.redirect() 默认就是 302。永远要显式写出来。我们见过的”我设置了重定向,可排名掉了”的支持工单里,隐式 302 是最常见的罪魁祸首。

Vercel (vercel.json 或 next.config.js)

在 Vercel 上,重定向配置放在项目根目录的 vercel.json 里,或者如果你用 Next.js,就放在 next.config.js 里(上面讲过了)。

{
  "redirects": [
    {
      "source": "/old-url",
      "destination": "/new-url",
      "permanent": true
    },
    {
      "source": "/old/:path*",
      "destination": "/new/:path*",
      "permanent": true
    }
  ]
}

坑点:和 Next.js 一样。permanent: true 是 308,permanent: false 是 307。如果明确要 301/302 状态码,用 "statusCode": 301 替代 "permanent"。

Netlify (_redirects 文件)

在 Netlify 上,重定向写在发布目录(或 public/)下的 _redirects 文件里。

# Single URL 301
/old-url    /new-url    301

# Wildcard
/old/*    /new/:splat    301

# Domain change (full URL on the right)
https://oldbrand.com/*    https://newbrand.com/:splat    301!

坑点:末尾的 !(强制标志)会让重定向覆盖目标位置上已有的文件。没有它,Netlify 只会在源路径不对应真实文件时才重定向。很有用,但很容易忘。

AWS CloudFront(Functions 或 Lambda@Edge)

在 CloudFront 上,重定向可以作为 CloudFront Function 运行(更便宜、更简单),也可以用 Lambda@Edge(更强大,成本更高)。对绝大多数重定向工作来说,Functions 才是正解。

function handler(event) {
  var request = event.request;
  if (request.uri === '/old-url') {
    return {
      statusCode: 301,
      statusDescription: 'Moved Permanently',
      headers: {
        location: { value: 'https://example.com/new-url' }
      }
    };
  }
  return request;
}

把这个函数挂到 CloudFront distribution 的某个 behaviour 上,事件类型选 viewer-request。CloudFront Functions 的执行时间上限是 10ms,且不能访问网络,但每月前 1000 万次调用是免费的。

Caddy

在 Caddy 上,重定向写在 Caddyfile 里,非常简单。

# Single URL 301
oldbrand.com {
    redir /old-url /new-url permanent
}

# Domain change with HTTPS preserved
oldbrand.com {
    redir https://newbrand.com{uri} 301
}

坑点:Caddy 里的 permanent 就是 301。302 要用 temporary。Caddy 通过 Let’s Encrypt 自动处理 HTTPS,所以域名重定向通常一行就搞定。

IIS(Windows Server,web.config)

在 IIS 上,重定向写在站点 web.config 文件的 <system.webServer> 节点下。需要安装 URL Rewrite 模块(微软免费提供下载)。

<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Old URL 301" stopProcessing="true">
          <match url="^old-url$" />
          <action type="Redirect" url="/new-url" redirectType="Permanent" />
        </rule>
        <rule name="Domain change" stopProcessing="true">
          <match url=".*" />
          <conditions>
            <add input="{HTTP_HOST}" pattern="^oldbrand\.com$" />
          </conditions>
          <action type="Redirect" url="https://newbrand.com/{R:0}" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

坑点:IIS 里的 redirectType="Permanent" 是 301。302 要用 Found,303 用 SeeOther,307 用 Temporary。这个命名并不直观。很多开发者以为 Temporary 是 302,结果上线了错误的状态码。

正处在迁移中间,需要多一双眼睛? 把你的 sitemap 和 .htaccess 发过来。我们在通话里做一次免费 30 分钟审计。你的屏幕,我们的声音,真实的 curl 输出。不发 PPT,不写提案。想让我们接手时,留任制起价 ₹40,000 / $499 每月。

预约 30 分钟策略通话 → · WhatsApp +91 96366 50036

如何验证：不要轻信，动手证明。

检查重定向到底在做什么，有三种方法。第一种不需要任何特殊工具。第二种使用 Chrome 自带的免费功能。第三种使用 Google 自家的免费工作台。挑你最顺手的那个。它们都会告诉你真相。

curl -I，一行命令搞定（面向开发者）

如果你不是开发者，请直接跳到下面的浏览器开发者工具或 Google Search Console 方法。它们能展示同样的信息，而且不用命令行。

在任何一台有终端（开发者常用的黑白文本窗口）的电脑上，运行：

curl -I https://example.com/old-url

示例输出：

HTTP/2 301
date: Tue, 1 May 2026 09:00:00 GMT
location: https://example.com/new-url
cache-control: max-age=31536000

HTTP/2 301 那一行以金色高亮，location 响应头指向新 URL，cache-control max-age 值被突出显示。品牌配色为深蓝与金色。" loading="lazy" width="1600" height="900">

第一行告诉你状态码。这里是 301。location: 响应头告诉你重定向指向哪里：正是你指定的新 URL。cache-control: max-age=31536000（一年的秒数）说明这个重定向被积极缓存，与永久重定向的行为一致。浏览器和 CDN 会遵守这条指令，回访时跳过查询。

小坑：有些服务器返回 HTTP/1.1，而不是 HTTP/2。状态行写的是 HTTP/1.1 301 Moved Permanently，而不是更简短的 HTTP/2 301。行为完全一样。版本号只是反映你的服务器支持什么，并不代表重定向是否有效。

浏览器开发者工具 Network 面板

打开 Chrome DevTools → Network 面板 → 勾选 “Preserve log” → 在地址栏直接加载旧 URL。

第一个请求会在 Status 列显示 301 或 302。点击那一行，可以在右侧面板查看 Location 响应头和完整的响应头。

这种方法非常适合直观地发现重定向链。每一跳都会显示为独立一行。如果在最终 200 之前看到三行，就说明有一条需要压缩的链。

GSC URL 检查，部署后的检查

Google Search Console → 网址检查 → 粘贴旧 URL。

对于一个成功的 301，你会看到 “URL 不在 Google 上”，理由是 “包含重定向的网页”。这证实 Google 已经抓取了重定向、登记了它，并开始把权重传递给目标地址。

两到六周后，再粘贴新 URL。你希望看到的是：”URL 在 Google 上”，加上 “网页已编入索引” 和 “用户声明的规范网址”。这说明整合已经完成。新 URL 现在承接了旧 URL 积累起来的权重。

完整的 URL 检查功能说明，请参见 Google 的 URL 检查文档。

这就是你要转发给客户、用来证明迁移成功的截图。不是 Semrush 导出的报告。不是付费工具的报告。而是 Google 自家的控制台明确显示 URL 在 Google 上。不要相信工作台。读响应本身。

如果你已经用错了代码：恢复手册

恢复只有四个小步骤。找出失效的 URL。修复代码。请 Google 重新来抓取。等待。大部分时间其实都花在等上。真正的修复很快。整件事通常要 2 到 6 周,任何一步赶进度只会让等待更久。

实际操作中是这样的。 上个季度我们帮过一个护肤品牌,他们刚把店铺从 Shopify 迁到了 WooCommerce。开发人员在每个 URL 上都用了 302,因为迁移插件默认是”临时”的,没提醒任何人。到第 4 周,自然流量掉了 38%。我们检查了 60 个产品页,确认每一条跳转类型都错了,于是全部切换成 301。然后我们重新提交站点地图,请 Google 重新抓取 12 个最高营收页面。十八天后,新 URL 显示为主版本,流量回到了迁移前基线的 4% 以内。

症状

排名在迁移后 2 到 6 周下滑,时间点吻合得不像是巧合。Google Search Console 对本该已经变成新主版本的 URL 标出”Page with redirect”。Google 仍然把旧 URL 当成主要版本。AI 搜索让事情更糟:ChatGPT、Claude 和 Gemini 一直把人引到旧 URL,因为它们的训练数据捕捉到了临时跳转信号。即使 Google 毫无异议地接收了你的站点地图,新 URL 在 Google 中几乎看不到存在感。旧 URL 的直接访问量无规律地起伏,因为浏览器和书签记住了旧地址,把访客送进跳转循环或带到过时页面。

诊断

挑 20 到 50 个旧 URL,检查服务器实际返回了什么。(如果你是开发者,用 curl -I。否则就用 Chrome 打开 URL,在 DevTools 的 Network 标签里看。)记下真实的状态码,而不是你的 CMS 说它在发送什么。然后把同一批 URL 跑一遍 Google Search Console 的 URL 检查工具。对不上号的地方就是漏点所在。查看平台设置或服务器配置找出根因。三个常见元凶:默认设为”临时”的跳转插件、没有明确状态码的 Express 调用,或带有 permanent: false 的 Next.js 跳转。链式跳转要单独记。像 A→B→C→D 这样的链,会在错误代码问题之上再叠加第二层问题。

修复

把每一个相关设置都改成 301(或者 308,如果你需要锁定 API 的请求类型),然后把改动推上线。用你一开始发现问题时的同样方式验证每一处修复,确认 301 确实生效了。重新向 Google Search Console 提交站点地图,让 Google 知道有东西变了。用 GSC 的 URL 检查工具,在你最重要的目标 URL 上点”请求编入索引”。优先处理那些带来营收或外链的页面。对于超高流量的跳转,你可以临时在首页加一条指向新 URL 的链接,加快 Google 的速度。这条内部链接会促使 Google 更早回来查看。

重新索引

通常要等 2 到 6 周,新 URL 才会接替成为主版本。Google 频繁访问的大站会更快。AI 搜索的恢复速度不一。ChatGPT 和 Gemini 会在训练周期刷新后开始引用正确的 URL。Perplexity 和 Bing 的聊天功能通常在新 URL 稳定后 1 到 2 周内跟上。关于 301 跳转 Google 要花多久处理的具体基准数据,我们会在后续文章里发布详细的抓取时间数据。

接手了一堆乱七八糟的跳转,不知道血在哪里流? 把你的站点地图粘到免费 5 分钟审计里,我们会回传跳转图里每一条 301、302 和链式跳转的清单,加上此刻正在让你失去索引的那些。大多数客户在无法解释的流量下滑到第 3 周时联系我们。省下 2 周。

在 WhatsApp 上发送你的站点地图 →

7 个悄悄拖垮排名的错误

这是我们几乎在每次审计中都会看到的七个错误。每一个都附带快速识别的方法和快速修复的方法。

实际操作中是这样的。 去年我们给一家正要进行首轮大额融资的软件公司做审计。六年的产品迭代中,他们的服务器配置累积了 4,200 条跳转规则。其中 41 条形成了四跳或更长的链。6 条是活跃的循环,让服务器原地打转。我们把每条链压缩成单跳跳转,消灭了循环,总数削减到 1,180。页面加载快了 340 毫秒。两周后,Google 重新开始抓取他们网站的更多内容。

1. 跳转链(A 跳到 B,B 跳到 C,C 跳到 D)。 要发现它,就沿着整条链一步步走。每一跳都会损失一点排名权重,并增加延迟。修复方法是让 A 直接跳到 D。跳转链调试指南涵盖了完整的一步步流程。

2. 跳转循环。 跳转在循环里来回弹之后,服务器返回错误或浏览器超时。修复方法是删除那条指回链中较早 URL 的规则。

3. 同一次迁移里 301 和 302 混用。 有些页面用了永久代码,有些用了临时代码,Google 看到的是一幅不一致的图景。修复方法是检查站点地图上的每一个 URL,把每条规则都改成 301。

4. 忘了 /page 和 /page/ 是不同的 URL。 带不带尾部斜杠,Google 会把它们当成两个独立页面。两者必须跳转到同一个版本,否则你的排名权重会被拆到两个版本上。

5. 忘了 http:// 和 www. 的变体。 每个 URL 都有四个版本:带或不带 https、带或不带 www。其中三个必须 301 跳到一个主版本。漏掉任何一个,都会把你的权威性打散到多个地址上。

变体 URL 爆炸是 WooCommerce 特有的一种相关失败模式。五个属性、每个八个值,一个产品能衍生出 40,000 个可索引 URL。WooCommerce 专属的技术 SEO 讲解了位于 WC Tower 第 3 层的变体 URL 去重模式。

6. 跳转之后是空页面。 目标 URL 能打开,但页面很短或基本上是空的。Google 会把这当作”软 404”(技术上能加载但表现得像页面缺失),然后悄悄把它丢掉。修复方法是确保目标页面上有真实、有用的内容。软 404 恢复手册讲解了多少内容才算够。

7. 按访客所在国家自动跳转。 根据访客浏览位置把他们送到不同页面,又没给退出的办法,违反了 Google 的规则。按照 Multi-Region Authority Stack 第 1 层的方法修复,那里列出了按地区路由访客的正确方式。

没有手动覆盖的 Geo-IP 自动跳转,是 Google 反垃圾团队会标记的伪装风险模式。要正确实现多地区路由(hreflang、ccTLD 架构,以及不会悄悄 302 的第 1 层 Geo-IP 规则),请参考 Multi-Region Authority Stack。

常见问题解答

301 和 302 重定向有什么区别?

301 表示永久迁移。Google 会用新 URL 替代旧 URL 作为规范链接。302 表示临时迁移。Google 会保留原 URL 作为规范链接。根据 Google 的官方文档,两者都会传递链接权重,但索引行为完全不同。永久迁移时使用 301。临时迁移(将要还原)时使用 302。

302 重定向会影响 SEO 吗?

会。如果你用错了就会。对永久迁移使用 302 意味着 Google 会一直把源 URL 作为规范链接,目标 URL 永远积累不到自己的排名信号。权重两种方式都会传递(Mueller 于 2016 年确认过),但它会在两个 URL 之间分散,而不是集中到新 URL 上。结果是:两个 URL 都建立不起你排名高难度查询所需的权威性。解决方法是切换到 301,重新提交站点地图,并请求索引。

302 重定向会传递链接权重吗?

会。Google 的 John Mueller 确认过,301 和 302 重定向都会传递链接权重。注意点:使用 302 时,目标 URL 不会变成规范链接,因此权重仍然分散在两个 URL 上,而不是集中。你的链接信号会一直分散,直到你切换到 301 或完全移除重定向。

什么时候应该用 302 而不是 301?

在明确临时的场景下使用 302。要还原的 A/B 测试。几个小时或几天的维护窗口。活动结束就失效的促销页面。地域测试期间特定地区的临时服务。判断标准:你确实打算在合理时间内恢复原 URL。

Google 处理 301 重定向需要多久?

通常 2 到 6 周,新的规范链接才能在 Google 索引中完全替代旧的。抓取预算活跃的高权威网站处理更快。低权威网站可能需要 8 到 12 周才能完成合并。使用 GSC 的 URL 检查工具跟踪进度。301 重定向 Google 需要多久这个问题,主要取决于 Google 抓取你网站的频率。

我能稍后把 302 改成 301 吗?排名会恢复吗?

可以。把服务器配置从 302 改为 301,在 Google Search Console 重新提交站点地图,并对受影响的 URL 请求索引。排名通常会在 2 到 6 周内恢复,因为 Google 会重新处理重定向并将信号合并到目标 URL。你越早修复错误,恢复就越快。

301 和 308 有什么区别?302 和 307 呢?

308 是严格的永久重定向(方法安全)。它禁止客户端在重定向过程中改变 HTTP 方法。307 是严格的临时重定向(方法安全),同样保留方法。301 和 302 在历史上允许客户端将 POST 请求改为 GET 请求。对于保留原始请求方法至关重要的 API 端点,请使用 307 和 308。

如何在 WordPress 中做 URL 重定向?

三个选项。RankMath PRO 的重定向管理器界面最简洁,且具有自动 404 检测功能。免费的 Redirection 插件提供类似功能,没有高级版费用。手动编辑 .htaccess 给你最大控制权,但需要服务器访问权限。关于更广泛的 WordPress 技术 SEO 方法论,参阅我们的 WordPress SEO 操作手册。

我如何检查重定向是否正常工作?

在终端运行 curl -I [old-url] 查看服务器实际返回的状态码和 Location 标头。浏览器 DevTools 的 Network 标签会用可视化链条渲染显示同样的信息。Google Search Console 的 URL 检查工具会告诉你 Google 自身如何读取该重定向。

301 重定向链会影响我的 SEO 吗?

会。每一跳都会损失一小部分链接权重并增加延迟。在大约 5 跳之后,Google 可能会停止跟随链条,导致权重在途中丢失。每季度审查你的重定向,把链条压缩到单跳。Screaming Frog 能自动发现重定向链。

AI 搜索引擎(ChatGPT、Claude、Gemini)处理重定向的方式与 Google 不同吗?

不同。根据 SE Ranking 2025 年 12 月的研究,ChatGPT 引用重定向 URL 的频率比 Google 低 3 到 7 倍。AI 系统在选择来源时更偏好稳定、未重定向的 URL。如果 AI 流量对你的策略很重要,请优先使用 301 而非 302,并在高价值内容中消除重定向链。

301 重定向应该保持多久?

至少 12 个月,最好是永久。一旦 Google 将信号合并到新 URL,你可能会以为重定向不再需要了。其实还是需要的。保留它。其他网站链接到旧 URL 的链接仍会通过重定向发送用户(和爬虫),持续多年。移除之后这些链接就会 404。合理的经验法则:永久保留 301,除非目标 URL 本身也要被废弃。

如何重定向像 ?utm_source=X 这样的查询字符串参数?

两个选项。保留它们:大多数平台会自动透传查询字符串(Apache 的 RewriteRule、Nginx 的 $request_uri、Cloudflare Workers 的 request.url)。剥离它们:明确重定向到不带查询的目标(例如 Apache 的 RewriteRule ^old$ /new? [R=301,L],末尾的 ? 会清除查询)。默认保留,除非你有特定理由(分析数据整洁、规范链接清理)要丢弃它们。

重定向会影响 Core Web Vitals 或页面速度吗?

会。每一跳重定向会增加 100-400 毫秒的延迟,具体取决于 DNS、TLS 握手和服务器响应时间。单次重定向很少会构成 CWV 问题。但在关键路径资源上有 3 个以上的重定向链,可能会让 LCP 超过 2.5 秒,拖垮你的 CWV。始终压缩重定向链,并在边缘(Cloudflare Workers、CloudFront Functions)托管重定向,以获得最快的响应。

硬 301 和软 301 有什么区别?

HTTP 规范中不存在”软 301”。这个词有时出现在 SEO 写作中,用来描述基于 JavaScript 或 meta-refresh 的重定向。那些不是真正的 301。它们是客户端的 hack。硬(真实的)301 是服务器返回状态码为 301 的 HTTP 层响应。”软 301”(JS 或 meta-refresh)无法可靠传递权重,不被所有爬虫接受,还会增加延迟。始终使用真正的 HTTP 层 301。

我可以重定向到外部域名吗?

可以。重定向机制是一样的。Location 标头指向外部 URL,状态码由你选择。SEO 后果也一样:301 到外部域名会把排名信号转移到那个域名,302 则把信号留在你这边。谨慎使用对外 301 重定向。你正在把权重交给别人的网站。常见的合理用途:收购后的重定向、合作伙伴网站跳转或关闭一个品牌。

如何修复重定向循环?

运行 curl -L -I [url]。-L 标志跟随重定向,-I 显示标头。如果跟踪在两个或多个 URL 之间来回跳转,你就有循环。常见原因:A→B 的重定向加上 B→A 的规范标签、冲突的 .htaccess 规则,或者 CDN 层重定向与源服务器重定向对打。通过识别违规规则(通常是最近添加的那个)并移除来修复。修复后再用 curl -L -I 验证。成功的结果是跟踪末尾显示单个 200。

正处于迁移中?这是我们的邀约。

把你的站点地图和 .htaccess 发给我们。我们会花 30 分钟和你通话。你的屏幕加我们的。我们会现场对你的五个 URL 运行 curl,查看 GSC 中你的重定向图,并告诉你哪个修复能挽回最多的排名权重。没有幻灯片,没有提案,也没有后续销售跟进。

预约 30 分钟策略通话 → · WhatsApp +91 96366 50036

想先看价格?公开的价格指数展示了每个保留合同档位,以 INR、USD、GBP、EUR、AUD 计价。没有探索性通话后的加价。

想要完整的方法论?参阅 Prove-It 协议。交付 → 测量 → 证明 → 迭代。

关于作者

Kunal Singh Dabi 是 KD Digital 的创始人。2023 年在 New Delhi 举办的 WASME 世界中小微企业商业峰会上,被评为印度中小微企业最佳 SEO 专家。自 2021 年 5 月以来,已在 17 多个国家为 250 多家企业实现规模化增长。140 多条已验证评价中平均 4.9★。母级 SEO 咨询业务的搭建者,每一次变更都附带周一报告交付。