301 vs 302 Redirects: Impact on Link Equity

Everyone says use 301s. That advice is mostly right but the reasons people give are often wrong. I've read hundreds of forum threads, blog posts, and Twitter arguments about redirect types, and the amount of confidently incorrect information floating around is staggering. People repeat things they heard in 2012 as if nothing has changed. Other people overcorrect and claim redirects don't matter at all anymore. The truth, as usual, lives somewhere in the middle — and it's weirder than either camp admits.

Key Takeaways

• What the HTTP Spec Actually Says
• The Link Equity Question
• What Google Actually Does (Probably)
• The Thing About Redirect Chains That Nobody Wants to Hear
• Server Configuration: Where the Rubber Meets the Road
• When You Actually Want a 302

Let me be upfront: I've changed my own thinking on this topic at least three times over the past decade. Some of what I believed five years ago turned out to be wrong. Some of what I believe now might turn out to be wrong too. That's the nature of working with a system where the rules aren't published and the engineers who built it occasionally contradict each other in public statements.

What the HTTP Spec Actually Says

Before we get into SEO implications, let's ground this in what these status codes actually mean at the protocol level. This matters because a lot of the SEO confusion stems from people not understanding the underlying technology.

A 301 status code means "Moved Permanently." The resource you requested has been permanently moved to a new URL. Clients (including browsers and search engine crawlers) should update their records to use the new URL going forward. Here's what a 301 response looks like in the HTTP headers:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page
Content-Length: 0
Connection: keep-alive

A 302 status code means "Found" — which is actually a confusing name. It originally meant "Moved Temporarily" in HTTP/1.0, and was redefined as "Found" in HTTP/1.1. In practice, everyone still treats it as a temporary redirect. The response looks almost identical:

HTTP/1.1 302 Found
Location: https://example.com/temporary-page
Content-Length: 0
Connection: keep-alive

There's also a 307 (Temporary Redirect) and a 308 (Permanent Redirect), which were introduced in HTTP/1.1 to fix ambiguities in how 301 and 302 handled request methods. Specifically, 301 and 302 technically allowed browsers to change a POST request into a GET when following the redirect — 307 and 308 strictly forbid that. For SEO purposes, 307 behaves like a 302, and 308 behaves like a 301. But almost nobody uses 308 in practice, and 307 shows up mainly in HSTS redirects.

The reason I'm going through this is because the HTTP specification creates the conceptual framework. A 301 tells the world: "this URL is gone forever, use the new one." A 302 tells the world: "this URL is temporarily somewhere else, but the original URL is still the canonical one." That distinction is the foundation of everything else.

The Link Equity Question

Here's where we get into the part everyone actually cares about. When a page has backlinks and you redirect it to a new URL, what happens to the link equity (sometimes called "link juice," a term I find slightly embarrassing but whatever, it's stuck) that those backlinks were passing? To understand this better, take a look at The Beginner's Guide to Link Juice and How It Flows.

The traditional SEO wisdom was this: 301 redirects pass link equity. 302 redirects don't. Simple. Clean. And for a long time, it was more or less true — or at least true enough to be useful.

The reasoning was straightforward. A 301 tells Google "the old URL is permanently replaced by the new one," so Google should transfer all ranking signals from the old URL to the new one. A 302 tells Google "the old URL still exists, this is temporary," so Google should keep the ranking signals associated with the old URL and not transfer them to the temporary destination.

This made logical sense. And for years, practical testing seemed to confirm it. Sites that used 301 redirects during migrations preserved their rankings better than sites that accidentally used 302s. Case studies piled up. "Always use 301s" became gospel.

Then things got complicated.

What Google Actually Does (Probably)

In 2016, Gary Illyes from Google tweeted — in his characteristically casual way — that 30x redirects don't lose PageRank anymore. Any 30x. That includes 301, 302, 307, whatever. This caused a minor earthquake in the SEO community because it contradicted years of received wisdom.

The claim was that Google had changed their handling of redirects so that all redirect types passed full PageRank. The logic, presumably, was that penalizing 302 redirects for link equity was causing more problems than it solved — webmasters who accidentally used 302s instead of 301s were being unfairly punished for a technical misconfiguration rather than any attempt at manipulation.

Now. Do I believe this completely? Sort of. I believe Google made changes in this direction. I'm less confident that all redirect types are treated identically in every context. Here's why: even if the raw PageRank passes through a 302 the same way it passes through a 301, the redirect type still communicates something about the relationship between the URLs. And Google uses more than just PageRank to determine rankings.

With a 301, Google will eventually drop the old URL from its index and replace it with the new one. The new URL inherits the old URL's position in search results. With a 302, Google might keep the old URL in the index for a long time, or it might eventually swap it out — the behavior isn't entirely predictable. And as long as the old URL is the one showing up in search results, any "link equity" passed to the new URL is somewhat moot because users are still being directed through the old URL first.

So when someone says "302s pass link equity now," they're technically correct but possibly misleading. The equity might pass, but the indexing behavior is different, and indexing behavior affects how that equity manifests in actual rankings.

The Thing About Redirect Chains That Nobody Wants to Hear

This is the section where things get long because redirect chains are one of those problems that starts simple and becomes a nightmare of accumulated technical debt. I've seen sites with redirect chains five, six, seven hops deep. I once audited a site that had a chain of eleven redirects. Eleven. Each one added by a different developer during a different migration, and nobody ever went back to clean up the previous ones.

A redirect chain is what happens when URL A redirects to URL B, which redirects to URL C, which redirects to URL D. Instead of a single hop from the old URL to the final destination, you've got multiple hops. Every redirect in the chain adds latency — usually 50-200ms per hop, depending on server configuration and geographic distance. A chain of four redirects can add a full second to load time before the user even starts receiving the actual page content.

From a link equity perspective, redirect chains have historically been thought to lose some equity at each hop. Google's Matt Cutts said years ago that there was "a small amount" of PageRank lost with each redirect. Whether that's still true is debated. Google has suggested that chains of reasonable length don't lose significant equity, but "reasonable length" is doing a lot of work in that sentence.

Here's the practical problem. Even if we take Google at their word that redirect chains don't meaningfully impact link equity, they still create other problems: See also our post on Understanding Link Equity: A Complete Guide for more on this.

Crawl budget. Every redirect hop requires Googlebot to make another request. If you have thousands of URLs with redirect chains, that's thousands of extra requests during each crawl session. For large sites, this can meaningfully reduce how much of your site gets crawled in a given period.

User experience. Humans don't like waiting. A one-second delay might not sound like much, but it compounds with everything else — DNS lookup, TLS handshake, server response time, page rendering. If your redirect chain is adding a second on top of an already-slow page, you're pushing into territory where users start bouncing.

Debugging complexity. When something goes wrong with a redirect chain — and something always eventually goes wrong — tracing the problem through multiple hops is significantly harder than debugging a single redirect. I've spent entire afternoons trying to figure out which hop in a chain was causing a loop or serving the wrong destination. It's not fun. Don't create future problems for yourself or whoever inherits your site.

Mixed chain types introduce additional weirdness. What happens when you have a 301 pointing to a 302 pointing to a 301? Which redirect type "wins" for signaling purposes? The answer is: nobody's entirely sure. Google probably looks at the chain as a whole and makes a determination about whether the final destination should replace the original URL in the index. But the presence of a 302 in the middle of the chain might cause Google to be less certain about the permanence of the move, which could delay or prevent full URL consolidation.

My recommendation, which shouldn't be controversial but somehow still is: flatten your redirect chains. Every old URL should redirect directly to its final destination in a single hop. Yes, this requires maintaining a redirect map. Yes, it's extra work during migrations. Yes, it means you need to update your redirects when you do a subsequent migration instead of just layering new redirects on top of old ones. Do it anyway.

I've seen the impact of flattening redirect chains on multiple sites. One client had roughly 4,000 URLs going through chains of 3-4 hops. We flattened everything to single-hop 301s over a weekend. Crawl rate increased by about 15% within two weeks. Several pages that had been stubbornly stuck on page two moved to page one within a month. Could that have been coincidental? Sure. But the timing was suggestive.

Server Configuration: Where the Rubber Meets the Road

Redirects are implemented at the server level, and how you configure them matters. Different web servers handle redirects differently, and getting the configuration wrong is surprisingly easy.

On Apache servers, redirects are typically configured in the .htaccess file or in the main server configuration. A basic 301 redirect looks like this:

RewriteEngine On
RewriteRule ^old-page$ /new-page [R=301,L]

The [R=301] flag sets the status code. Change it to [R=302] for a temporary redirect. The [L] flag means "last rule" — stop processing rewrite rules after this one matches. Forgetting the [L] flag is a classic source of redirect chain bugs, because subsequent rules can match the already-rewritten URL and add additional redirects.

On Nginx, redirects go in the server configuration block:

server {
    location = /old-page {
        return 301 /new-page;
    }
}

Nginx's syntax is cleaner and harder to mess up, in my opinion. The = sign before the path means exact match — no regex, no ambiguity. Change 301 to 302 for a temporary redirect.

For sites running on Node.js or similar platforms, redirects are typically handled in application code:

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

The important thing with any of these approaches is to be explicit about the status code. Some frameworks default to 302 if you don't specify. Express.js, for example, uses 302 as the default for res.redirect(). If you just write res.redirect('/new-page') without specifying 301, you've just created a temporary redirect when you probably wanted a permanent one. I've seen this mistake on production sites more times than I can count. We wrote an entire guide on this: Canonical Tags and Their Effect on Links.

When You Actually Want a 302

Amid all the "always use 301" advice, people sometimes forget that 302 redirects exist for legitimate reasons. Not every redirect should be permanent.

A/B testing. If you're testing two versions of a page and redirecting some users to a variant, that redirect should absolutely be a 302. You don't want Google to treat the test variant as the permanent replacement for the original.

Geolocation redirects. If you're redirecting users to country-specific versions of a page based on their IP address, a 302 is appropriate. The original URL is still the canonical resource — you're just temporarily sending this particular user to a localized version.

Maintenance and outage pages. If a page is temporarily down and you're redirecting to a maintenance notice, use a 302. You want Google to come back and check the original URL later, not index your "we'll be back soon" page as the permanent replacement.

Promotional redirects. If you're running a limited-time campaign and temporarily redirecting a URL to a promotional landing page, 302 is correct. When the campaign ends, you'll point the URL back to its original destination.

Login redirects. When unauthenticated users hit a protected page and get redirected to a login form, that should be a 302 (or 307, to preserve the request method). The original URL is still the real resource — it's just not accessible without authentication.

In all of these cases, the key question is: will the original URL eventually serve content directly again? If yes, use a 302. If the original URL is gone forever and all future requests should go to the new location, use a 301.

Site Migrations and the Stakes Get Higher

Where the 301 vs 302 distinction matters most is during site migrations — changing domains, restructuring URL patterns, moving to HTTPS, consolidating subdomains. These are permanent changes and they demand 301 redirects. Getting this wrong during a migration can cost months of recovery time.

I've worked on migrations where someone accidentally deployed 302 redirects across the entire site. Rankings didn't collapse immediately — which is actually part of the problem, because it means people sometimes don't realize the mistake right away. But over the following weeks, the old URLs stayed in Google's index while the new URLs failed to gain traction. The site was essentially split between two versions in Google's eyes, with neither version having the full authority of the original.

Once we switched the 302s to 301s, it took about six weeks for Google to fully process the change and consolidate everything under the new URLs. Six weeks of diminished organic traffic because of a single character difference in a configuration file. That's the kind of thing that makes you double-check your redirect configuration before every deployment.

Large migrations also bring up the redirect map problem. If you're changing 10,000 URLs, you need a redirect map that correctly maps every old URL to its new equivalent. Building that map is tedious, error-prone work. Automated tools can help — Screaming Frog can crawl your old site structure and you can match it against the new structure programmatically — but you still need human review for edge cases. Pages that were merged, split, or deleted during the migration all need special handling.

Measuring Impact

How do you know if your redirects are working correctly? A few things to monitor: If this is new to you, How to Handle Links During a Site Migration breaks it down step by step.

Google Search Console's URL Inspection tool lets you check how Google sees a specific URL. After implementing a 301, you should eventually see the new URL as the canonical, with the old URL noted as an alternate that redirects. If you see the old URL still listed as the canonical weeks after implementing a 301, something's wrong.

The Coverage report in Search Console shows you redirect-related issues. Look for "redirect error" entries, which indicate chains or loops. Also watch for "page with redirect" in the excluded section — this can tell you whether Google is treating your redirected URLs correctly.

Server logs are your friend. If you have access to raw server logs, grep for the status codes on your redirect URLs. Make sure they're returning what you expect. I've seen cases where a CDN layer was caching a 302 response even after the origin server was updated to return a 301. The fix was purging the CDN cache, but without checking the logs, we would have assumed the 301 was in place when it wasn't.

# Check redirect status from command line
curl -I -L https://example.com/old-page

# Output shows each hop:
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/new-page
# ...
# HTTP/1.1 200 OK

That curl command with -I (headers only) and -L (follow redirects) is probably the single most useful debugging tool for redirect issues. Run it before and after changes. Run it from different locations if you're using a CDN. Save the output. Compare.

The Meta Refresh and JavaScript Redirect Tangent

While we're on the subject, I should mention that not all redirects happen at the HTTP level. Meta refresh tags and JavaScript redirects exist, and they behave differently from server-side redirects in ways that matter for SEO.

A meta refresh redirect lives in the HTML:

<meta http-equiv="refresh" content="0;url=https://example.com/new-page">

Google has said they treat meta refresh with a 0-second delay similarly to a 301. But "similarly" isn't "identically," and there's less certainty about how link equity flows through meta refreshes compared to proper server-side redirects. Also, the page has to load and be parsed before the redirect happens, which adds latency.

JavaScript redirects — using window.location or similar — are even more uncertain. Googlebot can execute JavaScript, but there's a rendering queue and a delay. Whether a JS redirect passes link equity the same way a 301 does is questionable. I wouldn't rely on it. If you have the option to use a server-side redirect, always prefer that over client-side solutions.

How Long Should You Keep Redirects?

Another question I get asked constantly. Once you've implemented a 301, how long do you need to keep it active? Can you eventually remove it?

The short answer: keep redirects for at least a year, and probably longer for high-value URLs. Google has said that after a year or so, they'll drop the old URL from their index entirely and the redirect is no longer needed for SEO purposes. But external links pointing to the old URL don't go away. If someone linked to your old URL in a blog post from 2019 and a user clicks that link, they'll get a 404 if you've removed the redirect. That's a bad experience and a wasted link.

For important URLs — especially those with significant backlink profiles — I'd argue for keeping redirects indefinitely. The server overhead of maintaining a redirect rule is negligible. The potential cost of losing link equity from old backlinks is not. It's one of those cases where the conservative approach is also the correct approach.

Some people argue that Google eventually just assigns the link equity to the new URL permanently and the redirect becomes truly unnecessary. Maybe. I haven't seen convincing evidence of that, and the risk-reward calculus doesn't favor removing redirects from valuable URLs.

Common Redirect Mistakes I Keep Seeing

After years of auditing sites, these are the redirect mistakes that come up again and again. They're all avoidable. You might also find Rel Attributes Explained: nofollow, sponsored, ugc useful here.

Redirecting everything to the homepage. When pages are deleted during a redesign, lazy implementations redirect all old URLs to the homepage instead of to the most relevant equivalent page. Google treats this as a soft 404 after a while, which means you lose the link equity anyway. If you're going to redirect, redirect to a relevant page.

Not redirecting HTTP to HTTPS. In 2026, this should be obvious, but I still find sites where the HTTP version of URLs returns a 200 instead of redirecting to HTTPS. This means Google might be splitting your link equity between two versions of every URL. Always redirect HTTP to HTTPS with a 301.

Redirect loops. URL A redirects to URL B, which redirects back to URL A. Browsers catch this and show an error. Googlebot eventually gives up. Usually caused by conflicting rules in the server configuration or a CMS plugin fighting with .htaccess rules.

Not handling trailing slashes consistently. /page and /page/ might be different URLs on your server. If one redirects to the other, fine. If both return 200 with the same content, you've got a duplicate content issue. If one redirects to the other with a 302 when it should be a 301... well, you get the picture.

Using redirects when a canonical tag would suffice. If two URLs serve the same content and you want to keep both accessible, a rel=canonical tag tells Google which one to prefer without redirecting users. Redirects are for when the old URL shouldn't serve content anymore. Canonicals are for when it still does but you have a preferred version.

Alright. I've said what I wanted to say. Use 301s for permanent moves, 302s for temporary ones, keep your chains flat, check your work with curl, and don't remove redirects from URLs that have backlinks.