早在 2021 年，我被请来审计一个 400 页的电商网站，该网站在六个月前迁移过。流量下降了 38%，客户搞不清楚原因。做迁移的开发者对每一个旧 URL 都使用了 302 重定向，因为他"之前见过这个方法能用"。该网站的域名权威度完好无损。反向链接仍然存在。但 Googlebot 把旧页面当作临时移动的，把链接权益搁置起来，等着看原始 URL 是否可能回来。整整六个月都是这样。看别人学到这个痛苦的教训是件难受的事。
重定向类型的问题就在这里：对点击链接的用户来说，它们看起来完全一样。浏览器无论如何都会把你从 A 带到 B。但对搜索引擎而言，这种区别大到足以在迁移中造成严重破坏，如果你搞错的话。
这两个重定向代码实际上意味着什么
在 HTTP 协议层面，301 告诉客户端（浏览器、Googlebot、Bingbot，或任何东西）资源已永久移动到新位置。302 则表示它临时移动了。就这样。这就是规范层面的全部区别。permanently moved to a new location. A 302 says it's temporarily moved. That's it. That's the whole difference at the spec level.
但后续的 SEO 影响才是真正有趣的地方。
使用 301 重定向时，Google 会将信号（反向链接、页面权重、抓取优先级）从旧 URL 合并到新 URL。使用 302 重定向时，Google 应该保持原始 URL 的索引状态，因为这种移动是临时的。实际上，Google 多年来已经变得更聪明了，Google 自己的文档承认 Googlebot"可能会"最终从 302 重定向转移信号。但"可能"和"最终"不是我想拿客户收入去赌的词。Google's own documentation acknowledges that Googlebot "may" transfer signals from 302s too, eventually. But "may" and "eventually" are not words I want to bet a client's revenue on.
链接权重问题
301 重定向的链接权重转移也不是瞬间完成的。它通常需要几个抓取周期，具体时间取决于抓取配额和域名大小，可能是几天到几周。对于一个没有现有权重的全新目标 URL，这种合并至关重要。我见过一些网站在将错误的 302 重定向改为 301 后，仅通过运行修正的 .htaccess 文件并通过 Google Search Console 强制重新抓取，就在 6-8 周内恢复到迁移前的流量水平。.htaccess file and forcing a recrawl through Google Search Console.
何时使用 301 重定向
只要移动是真正永久的，就使用 301 重定向。以下是一些具体场景：
- 你正在从 HTTP 迁移到 HTTPS（这里的每个重定向都应该是 301）
- 页面已被删除，你将 URL 指向其最接近的相关替代页面
- 你在 WordPress 中更改了永久链接结构（这个问题经常困扰人们）
- 在合并或品牌重塑后，你正在将两个域名合并为一个
- 产品已停产，你正在重定向到分类页面
我在2022年底为一家时装零售商进行的WooCommerce迁移中，他们有大约800个旧产品URL需要重定向到新的URL结构。每一个都通过Redirection插件使用正则表达式模式匹配获得了301重定向。设置得当花了大约两小时。另一种方式——手动操作或使用302"只是为了测试"——本来会花费他们数月的恢复时间。Redirection plugin with regex matching for the pattern. Took about two hours to set up cleanly. The alternative, doing it manually or using 302s "just to test", would have cost them months of recovery time.
HTTPS迁移陷阱
就是这一个。我仍然看到开发者在进行HTTP到HTTPS迁移时使用302，因为他们想"先测试SSL"。别这样做。如果证书已安装且正常工作，直接使用301。HTTPS迁移时使用302是Google Search Console中臭名昭著的"重复内容"标志最常见的原因之一，因为Googlebot可能在一段时间内索引两个版本。
何时使用302重定向
真正的使用场景比大多数人想象的要少。302适用于以下情况：
- 你在对一个页面进行A/B测试，希望原始URL在测试期间保留其排名信号
- 你在运行临时促销活动（例如在黑色星期五用短期着陆页替换你的首页）
- 你在进行维护，将用户路由到状态页面几小时
- 你需要将用户地理位置重定向到本地化版本的页面，但不希望这是永久性的
最后一个值得深入探讨。如果你将英国访客重定向到/en-gb/，将美国访客重定向到/en-us/，这些应该是302，因为没有单个用户组"拥有"规范URL。Google通过hreflang单独处理地理定位，但302表示原始URL仍然是规范目标。/en-gb/ and US visitors to /en-us/, those should be 302s, because no single user group "owns" the canonical URL. Google handles geo-targeting separately through hreflang anyway, but the 302 signals that the original URL is still the canonical destination.
Seahawk去年有一个SaaS客户，他们在运行一个30天免费试用推广活动，首页临时重定向到/free-trial/登陆页面。正确的做法：302。他们希望一旦推广结束，原首页就能重新获得排名。如果他们用了301，首页的信号就会开始合并到/free-trial/，而那个页面在活动结束后会完全消失。/free-trial/ landing page. Correct call: 302. They wanted the original homepage to reclaim its rankings the moment the promotion ended. If they'd used a 301, the homepage's signals would have started consolidating onto /free-trial/, which was going to disappear entirely after the campaign.
"Google将302视为301"的谣言
你可能在某个地方读过这个说法。其中确实有一定道理。Google在某些情况下可能会将长期存在的302视为301，特别是当目标URL在很长一段时间内保持一致时。John Mueller在多次Google搜索中心办公时间会议上都提到过这一点。can in certain situations treat a long-standing 302 similarly to a 301, especially if the destination URL is consistently the same over a long time period. John Mueller has mentioned this in various Google Search Central office hours sessions.
但关键是：这是Google对开发者错误的宽容，而不是你应该规划的功能。Bing不会以同样的方式运作。而且依赖Google的判断来处理域名迁移这样有重大影响的事情，就是不严谨的做法。用对的工具。
如何检查你有什么类型的重定向
如果你不确定网站上目前运行的是什么，有几个快速的检查方法。
最快的方法：打开终端并运行 curl -I https://example.com/old-page 。在响应头中查找 HTTP/1.1 301 或 HTTP/1.1 302 。只需五秒钟。curl -I https://example.com/old-page . Look for the HTTP/1.1 301 or HTTP/1.1 302 in the response headers. Takes five seconds.
要对成百上千的URL进行更全面的审计，我使用Screaming Frog SEO Spider。导出你的爬取结果，按响应代码3xx过滤，你就能看到网站上的每个重定向及其类型。在Seahawk进行每次网站审计之前，我都会标准地运行这个工具。免费版本可处理多达500个URL，这对许多小型网站来说足够了。Screaming Frog SEO Spider is what I use. Export your crawl, filter by response code 3xx, and you can see every redirect on the site and what type it is. I run this as standard on every site audit at Seahawk before we touch anything. The free version handles up to 500 URLs which covers a lot of smaller sites.
对于WordPress，Redirection插件有一个内置日志，实时显示每个正在执行的重定向，包括响应代码。对于在迁移后捕获任何异常情况非常有用。
重定向链：没有人充分讨论的问题
一个 301 重定向指向另一个 301 重定向，再指向最终 URL。这就是重定向链，在经历过多次迁移或 CMS 更改的网站上频繁发生。链中的每一跳都会轻微削弱链接权益转移，并消耗抓取预算。
我遵循的规则是：如果 Screaming Frog 显示任何长度超过一个重定向的链，就要修复它。将第一个 URL 直接指向最终目标。这适用于 301 和 302 链。
正确实现重定向
取决于你的技术栈，但最常见的场景是：
Apache (.htaccess)：`` Redirect 301 /old-page https://www.example.com/new-page `` `` Redirect 301 /old-page https://www.example.com/new-page ``
Nginx：`` return 301 https://www.example.com/new-page; `` `` return 301 https://www.example.com/new-page; ``
WordPress（通过 Redirection 插件）：将 HTTP 代码字段显式设置为 301。该插件默认为 301，但我见过被其他插件或导入更改的情况，所以始终要再次检查。 Set the HTTP code field to 301 explicitly. The plugin defaults to 301 but I've seen it get changed by other plugins or imports, so always double-check.
Cloudflare Page Rules：你可以在 CDN 级别设置重定向规则，并明确指定 301 或 302 状态代码。对于在请求到达服务器之前的全域重定向很有用。 You can set redirect rules at the CDN level with explicit 301 or 302 status codes. Useful for domain-wide redirects before the request even hits your server.
我要补充一点：实现任何重定向后，用 curl 或 HTTP Status Checker 工具验证它。不要只是在浏览器中点击链接。浏览器会积极缓存重定向，你会认为它有效，而服务器实际上对首次访问者返回的是不同的内容。curl or the HTTP Status Checker tool. Don't just click the link in a browser. Browsers cache redirects aggressively, and you'll think it's working when the server is actually returning something different for first-time visitors.
指向重定向 URL 的反向链接会发生什么
简短回答：301重定向会随着时间推移，将链接价值合并到目标URL。但反向链接本身不会消失或自动更新。它们仍然指向旧URL。重定向告诉Google将这些链接的价值关联到新目标。
这就是为什么在不设置301的情况下更改永久链接结构是灾难性的。你曾经获得的指向 /blog/post-name/ 的每一条反向链接，如果该URL现在返回404而不是重定向到 /articles/post-name/，就会变得毫无价值。/blog/post-name/ becomes worthless if that URL now 404s instead of redirecting to /articles/post-name/.
我在2020年审计了一个内容网站，它更换了WordPress主题，而新主题的URL结构不同。没有设置重定向。他们在一夜之间丧失了大约200篇文章的链接权重。根据Ahrefs数据，即使是实施得当的301重定向也能保留大约90-99%的链接权重，尽管Google没有公布官方数字。重点是：即使不完美的301也远胜于404。Ahrefs data, even a well-implemented 301 redirect retains somewhere around 90-99% of link equity, though Google hasn't published an official figure. The point is: even an imperfect 301 beats a 404 by an enormous margin.
常见问题
301重定向是否传递100%的链接权重？
不，而且可能从未有过。Google历来暗示任何重定向都会有少量的PageRank损失。过去引用的数字约为15%的损失，不过Google后来有所收回。Ahrefs和Moz都估计单个干净301的损失最小。真正会伤害你的是链式重定向、循环或完全使用了错误的重定向类型。
我可以后来更改301重定向以指向其他地方吗？
可以。301是服务器端指令，不是Google索引中永久写入的东西。你可以随时更新目标。Google会在下次抓取时获取新目标。"301中的"永久"是指当时的永久意图，而不是说它在技术上是不可改变的。
Google处理301重定向需要多长时间？
对于权限高的网站且爬虫频繁访问的，有时一两天内就能完成。对于较小的网站，可能需要几周。通过Google Search Console的URL检查工具提交新URL并请求索引会显著加快这个过程。我在每次迁移中都把这作为标准做法。
我应该重定向每个旧网址，还是只重定向重要的网址？
任何有反向链接、有索引流量或有内部链接指向它的网址都应该获得正确的 301 重定向。对于零链接和零索引流量的页面，404 实际上是可以接受的。不要通过重定向那些从未有任何价值的真正死链接来造成重定向混乱。
JavaScript 重定向呢？它们的处理方式相同吗？
不相同。JavaScript 重定向（使用 window.location）由 Googlebot 处理的速度要慢得多，因为它们需要 JavaScript 渲染。它们在其他爬虫中也不一致。对于任何 SEO 敏感的内容，使用服务器端重定向。总是这样做。window.location) are processed much more slowly by Googlebot because they require JavaScript rendering. They're also inconsistent across other crawlers. For anything SEO-sensitive, use server-side redirects. Always.
---
重定向类型是那些看起来微不足道的东西之一，直到它真的成为问题。我曾经花了几个小时的电话时间向客户解释为什么他们的流量在迁移后六个月下降了，追溯到一个开发者决定使用 302 因为它"更安全"。这并不安全。选择正确的类型，保持链接链条简短，并用浏览器以外的工具进行验证。