A 301 redirect signals a permanent move: the original URL is gone and the destination is the canonical replacement. A 302 signals a temporary move: the original URL is still considered canonical, and the redirect is expected to be reversed eventually. From a user experience standpoint, 301 vs 302 redirects look identical — both deliver the destination page instantly. From a search engine standpoint they are meaningfully different, and using the wrong one can either slow down link equity transfer or permanently confuse which URL Google considers authoritative.

How Each Redirect Type Affects SEO

Google has confirmed that 301 redirects pass PageRank — link equity flows to the destination URL. Historically there was a documented loss of some PageRank through redirects, but Google has said this is no longer the case for properly implemented 301s. When you use a 301, you are explicitly telling Googlebot that the original URL is retired and the destination is its replacement. The index entry moves over time, and the link equity follows.

With a 302, Google is supposed to keep the original URL as the canonical and not permanently reassign ranking signals to the destination. In practice, if a 302 stays in place long enough and the destination page accumulates more signals, Google may start treating it as permanent anyway — but you are relying on Google to make that inference rather than instructing it. That is unnecessary ambiguity, and it is the kind of ambiguity that shows up in the Index Coverage report in Google Search Console as conflicting signals around which URL is considered canonical.

The practical consequence: if you use a 302 for a permanent move, you may find that the original URL continues to be crawled for months, that link equity splits between the two URLs, and that neither ranks as strongly as it would if you had used a 301 from the start. I have cleaned up exactly this situation on site migrations where the development team used 302s as placeholders and then never updated them. The fix is straightforward — change them to 301s — but the ranking recovery takes time because Googlebot has to re-crawl and re-process the signal.

When to Use Each One

  • Use 301 when you are permanently moving a page to a new URL, consolidating duplicate content, migrating a domain, or retiring a URL and replacing it with a different page
  • Use 302 when you are running a short-term A/B test and the original URL will return, when you are temporarily redirecting users during maintenance, or when a page is conditionally redirected based on user context (geo, device) and the original URL remains valid for other users
  • Use 307 instead of 302 when you need a temporary redirect and want to guarantee the HTTP method (POST, PUT) is preserved — 302 behavior on method preservation is inconsistent across older HTTP clients
  • Use 410 (Gone) instead of any redirect when a URL is permanently deleted and there is no replacement — this signals to search engines to drop the URL from the index faster than a 404 does

A note on 303: it is rarely relevant in SEO contexts, but worth knowing. A 303 forces the redirect to use GET regardless of the original method. If you are building forms or API flows that affect crawlable URLs, the distinction between 302, 303, and 307 matters. For standard page moves, stick to 301.

How to Implement Redirects Correctly

Server-level redirects are always preferable to application-level or JavaScript-level redirects. A 301 handled in your web server config or .htaccess file is processed before any application code runs — it is fast, reliable, and unambiguous to crawlers. A JavaScript redirect requires Googlebot to render the page first, which introduces the same rendering delay issues that affect JavaScript-rendered content. Here is an Apache .htaccess example for a clean permanent redirect:

# Permanent redirect — single URL
Redirect 301 /old-page/ https://example.com/new-page/

# Permanent redirect — entire directory
RedirectMatch 301 ^/old-section/(.*)$ https://example.com/new-section/$1

# Temporary redirect — for maintenance
Redirect 302 /checkout/ https://example.com/maintenance/

# 410 Gone — no replacement exists
Redirect 410 /discontinued-product/

For Nginx, use return 301 in a server or location block rather than rewrite with redirect — the return directive is faster and avoids regex processing overhead on rules that do not need it.

Redirect Chains and How to Avoid Them

Redirect chains — where URL A redirects to URL B which redirects to URL C — are common on sites that have gone through multiple migrations or CMS changes without cleaning up old redirects. Each hop adds latency and gives crawlers an additional opportunity to stop following the chain. Googlebot will follow redirect chains, but it has a limit, and each hop consumes part of your crawl budget allocation for that URL. More importantly, the SEO signal does not compound through chains the way a single direct redirect does.

The fix is to audit your redirects periodically and collapse chains: if A redirects to B and B redirects to C, update A to redirect directly to C. Most redirect management plugins and server-level redirect maps make this straightforward once you have mapped the chain. I recommend auditing redirect chains any time you do a significant site migration or URL restructure, and again six months later when new chains have often crept back in through routine CMS activity.

Screaming Frog makes this easy: crawl the site, go to the Response Codes tab, filter to 3xx, and look at the redirect chain column. Any chain longer than one hop is a candidate for collapsing. Export the list, trace each chain to its final destination, and update the origin redirect to point directly there.

Redirect Loops and Other Edge Cases

A redirect loop — A redirects to B, B redirects back to A — is a configuration error that browsers and crawlers handle differently. Browsers will typically show an error after a few hops. Googlebot will stop following the chain and report the error in Search Console. Loops usually happen when www and non-www redirect rules conflict, when HTTPS and HTTP redirects are misconfigured, or when a CMS canonical setting creates a cycle with a server-level redirect. Check for loops in Screaming Frog or by inspecting the response headers directly with curl -I -L and watching for cycling status codes.

Mixed signal situations — where a 301 redirect exists but the original URL also has a canonical tag pointing somewhere else — create ambiguity about which URL should be treated as authoritative. The canonical tag and the redirect should agree. If they conflict, Google has to guess, and it may not guess what you intended. This is covered in more depth in the article on canonical tags.

How Redirects Fit into a Full Technical Audit

Redirect auditing is a standard component of any technical SEO review. The questions are: how many redirects exist, are they the right type (301 vs 302), do they resolve in one hop, and do they agree with the canonical tags on the destination pages? Answering all four requires both a site crawl (Screaming Frog) and a look at the index (Google Search Console), because redirect issues often manifest as indexation problems rather than as obvious redirect errors.

To get a full picture of your redirect health alongside your broader technical foundation, a website audit is the right starting point. You can also read the companion article on indexation issues — redirect problems and indexation problems are closely related and usually need to be diagnosed together.