Back in 2021 I was brought in to audit a 400-page e-commerce site that had migrated six months earlier. Traffic was down 38% and the client couldn't figure out why. The developer who'd done the migration had used 302 redirects across the board, on every single old URL, because he'd "seen it work before". The site's domain authority was intact. The backlinks were still there. But Googlebot was treating the old pages as temporarily moved, holding link equity in limbo, waiting to see if the original URLs might come back. Six months of that. It's a painful lesson to watch someone else learn.
This is the thing about redirect types: they look identical to a user clicking a link. The browser takes you from A to B either way. But to search engines, the difference is significant enough to wreck a migration if you get it wrong.
What These Two Redirect Codes Actually Mean
At the HTTP protocol level, a 301 tells the client (browser, Googlebot, Bingbot, whatever) that the resource has 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.
But the downstream SEO implications are where it gets interesting.
With a 301, Google consolidates the signals (backlinks, page authority, crawl priority) from the old URL onto the new one. With a 302, Google is supposed to keep the original URL indexed, because the move is temporary. In practice, Google has gotten smarter about this over the years, and 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.
The Link Equity Question
Link equity transfer from 301s isn't instantaneous either. It typically takes a few crawl cycles, which can be days or weeks depending on crawl budget and domain size. For a brand new destination URL with no existing authority, that consolidation matters enormously. I've seen sites recover to pre-migration traffic levels within 6-8 weeks after fixing incorrect 302s to 301s, just by running a corrected .htaccess file and forcing a recrawl through Google Search Console.
When to Use a 301 Redirect
Use a 301 any time the move is genuinely permanent. Some concrete scenarios:
- You're migrating from HTTP to HTTPS (every single redirect here should be 301)
- A page has been deleted and you're pointing the URL to its nearest relevant replacement
- You've changed your permalink structure in WordPress (this one bites people constantly)
- You're consolidating two domains into one after a merger or rebrand
- A product is discontinued and you're redirecting to the category page
On a WooCommerce migration I did for a fashion retailer in late 2022, they had roughly 800 old product URLs that needed redirecting to their new URL structure. Every single one got a 301 via the 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.
The HTTPS Migration Trap
This one specifically. I still see developers doing HTTP to HTTPS migrations and using 302s because they want to "test the SSL first". Don't. If the cert is installed and working, go straight to 301s. The 302 approach on HTTPS migrations is one of the most common causes of the dreaded "duplicate content" flags in Google Search Console, because Googlebot may index both versions for a period.
When to Use a 302 Redirect
Genuinely fewer cases than most people think. A 302 is appropriate when:
- You're A/B testing a page and you want the original URL to keep its ranking signals during the test
- You're running a temporary promotional campaign (a short-term landing page that replaces your homepage for Black Friday, for example)
- You're doing maintenance and routing users to a status page for a few hours
- You need to geo-redirect users to localised versions of a page without making it permanent
That last one is worth lingering on. If you're redirecting UK visitors to /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 had a SaaS client last year who was running a 30-day free trial promotion where the homepage temporarily redirected to a /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.
The "Google Treats 302s Like 301s" Myth
You've probably read this somewhere. And there's a grain of truth in it. 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.
But here's the thing: that's Google being forgiving of developer mistakes, not a feature you should plan around. Bing does not behave the same way. And relying on Google's discretion for something as consequential as a domain migration is just sloppy work. Use the right tool.
How to Check What Type of Redirect You Have
If you're not sure what's live on a site right now, there are a few quick ways to check.
The fastest: open your terminal and run 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.
For a more thorough audit across hundreds of URLs, 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.
For WordPress specifically, the Redirection plugin has a built-in log that shows you every redirect firing in real time, including the response code. Genuinely useful for catching anything odd after a migration.
Redirect Chains: The Problem Nobody Talks About Enough
A 301 pointing to another 301 pointing to the final URL. This is a redirect chain, and they happen all the time on sites that have been through multiple migrations or CMS changes. Each hop in the chain dilutes the link equity transfer slightly and costs crawl budget.
The rule I follow: if Screaming Frog shows any chain longer than one redirect, fix it. Point the first URL directly to the final destination. This applies to both 301 and 302 chains.
Implementing Redirects Correctly
Depends on your stack, but the most common scenarios:
Apache (.htaccess): `` Redirect 301 /old-page https://www.example.com/new-page ``
Nginx: `` return 301 https://www.example.com/new-page; ``
WordPress (via Redirection plugin): 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: 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.
One thing I'd add: after implementing any redirect, verify it with 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.
What Happens to Backlinks Pointing at Redirected URLs
Short answer: a 301 will, over time, consolidate the linking value to the destination URL. But the backlinks themselves don't disappear or automatically update. They still point to the old URL. The redirect tells Google to associate the value of those links with the new destination.
This is why changing your permalink structure without setting up 301s is catastrophic. Every backlink you've ever earned pointing at /blog/post-name/ becomes worthless if that URL now 404s instead of redirecting to /articles/post-name/.
I audited a content site in 2020 that had switched WordPress themes, and the new theme had a different URL structure baked in. No redirects were set up. They'd lost link equity on about 200 articles overnight. According to 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.
FAQ
Does a 301 redirect pass 100% of link equity?
No, and it probably never has. Google has historically suggested there's a small amount of PageRank loss through any redirect. The old figure cited was around 15% loss, though Google has since walked that back somewhat. Ahrefs and Moz both estimate the loss is minimal for a single clean 301. What kills you is chains, loops, or using the wrong redirect type entirely.
Can I change a 301 redirect to point somewhere else later?
Yes. A 301 is a server-side instruction, not something permanently baked into Google's index. You can update the destination at any time. Google will pick up the new destination on its next crawl. The "permanent" in 301 means permanent intent at the time, not that it's technically immutable.
How long does Google take to process a 301 redirect?
For high-authority sites with frequent crawling, sometimes within a day or two. For smaller sites, it can take several weeks. Submitting the new URLs via Google Search Console's URL Inspection tool and requesting indexing speeds this up meaningfully. I do this as standard on every migration.
Should I redirect every old URL or just the important ones?
Every URL that has any backlinks, any indexed traffic, or any internal links pointing at it should get a proper 301. For pages with zero links and zero indexed traffic, a 404 is actually fine. Don't create redirect bloat by redirecting genuinely dead URLs that never had any value.
What about JavaScript redirects? Are they treated the same?
No. JavaScript redirects (using 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.
---
Redirect type is one of those things that looks trivial until it isn't. I've spent hours on calls explaining to clients why their traffic dropped six months after a migration, tracing it back to one developer's decision to use 302s because it was "safer". It's not safer. Get the type right, keep the chains short, and verify with something other than your browser.