Of all the quiet technical mistakes that tank websites, choosing the wrong redirect type might be the most common — and the most invisible. Your visitors see the same thing either way: they click a link and land on the right page. But Google sees two completely different statements. A 301 says "we moved forever — update your records." A 302 says "we'll be back — don't change anything."
Pick the wrong one and you can quietly bleed rankings for months without a single visible symptom.
A redirect is a server instruction: "the thing you're looking for isn't here anymore — go there instead." When a browser or crawler requests the old URL, the server responds with a 3xx status code and the new address. The browser follows it automatically, usually in milliseconds.
Redirects exist for legitimate, everyday reasons: you redesigned the site and the URL structure changed, you moved from HTTP to HTTPS, you consolidated www and non-www versions, you deleted a product and want to send visitors to its replacement. The web couldn't function without them.
The critical detail is intent: is the move permanent or temporary? That single distinction determines which code to use — and Google treats the two very differently.
A 301 redirect is a permanent change of address. It tells everyone — browsers, Googlebot, other crawlers — three things:
Use 301 for: site migrations, HTTP → HTTPS moves, www ↔ non-www consolidation, deleted pages with a natural replacement, consolidating duplicate or thin pages into a stronger one, and changing URL structure during a redesign.
In practice, the vast majority of redirects you'll ever create should be 301s. When in doubt, it's 301.
A 302 redirect is explicitly temporary. It says: "the content is over here right now, but the original URL is still the real address — keep it in your index."
Google's response: it keeps ranking the old URL, doesn't fully transfer link equity to the new one, and continues checking the old address expecting the content to return. That's exactly right for genuinely temporary situations:
The disaster scenario: a 302 for a permanent move — a site migration, a rebrand, an HTTPS switch — where the new URLs never accumulate authority because Google keeps waiting for the "temporary" situation to end. Sites have run broken 302 migrations for over a year wondering why traffic never recovered.
Two more codes complete the picture:
For ordinary web pages (GET requests), 301 and 302 behave identically to 308 and 307. The strict versions matter mainly for forms and APIs where changing a POST to a GET would break things. If you're redirecting regular pages, 301/302 is all you need to know.
On Apache servers, redirects live in .htaccess. A basic 301 looks like this:
```
Redirect 301 /old-page.html https://yoursite.com/new-page/
```
For pattern-based redirects (say, moving a whole directory), mod_rewrite rules do the heavy lifting. Writing these by hand is error-prone — one misplaced character can redirect your entire site to nowhere. A htaccess redirect generator builds the correct rules for you from a simple old-URL/new-URL pair, so you paste working code instead of debugging regex at midnight.
On Nginx, redirects go in the server block:
```
rewrite ^/old-page.html$ https://yoursite.com/new-page/ permanent;
```
(permanent = 301; use redirect for 302.)
In WordPress, plugins like Redirection handle it through the dashboard — fine for a handful of redirects. For site-wide migrations, server-level rules are faster and more reliable. In Cloudflare, Redirect Rules handle redirects at the edge before traffic reaches your server — handy without server access.
Whichever method you use, the verification step is non-negotiable: check both old and new URLs with a WWW redirect checker to confirm the old URL returns the intended code (301, not 302) and lands on the new page in a single hop.
Using 302 for permanent moves. Covered above — the #1 redirect mistake in SEO. If your migration happened more than a month ago and traffic hasn't recovered, check your redirect codes first.
Redirect chains. Old URL → redirect 1 → redirect 2 → redirect 3 → final page. Each hop costs link equity and crawl budget, and Google may stop following after several hops. Always point old URLs directly at the final destination — chains accumulate over years of migrations, so audit them periodically, and use a URL rewriting tool to clean up messy legacy URL patterns while you're at it.
Redirect loops. A → B → A. The page never loads. Usually caused by conflicting rules (one in .htaccess, one in a plugin, one in Cloudflare). If a page suddenly shows "too many redirects," check every layer.
Redirecting everything to the homepage. When you delete 50 product pages and 301 them all to /, Google reads it as a soft 404 — it knows there's no real equivalent content there. Redirect each deleted page to its closest relevant replacement, or let it 404 cleanly.
Forgetting internal links. Redirects fix external requests, but your own site shouldn't rely on them. After a migration, update internal links to point directly at new URLs — every internal redirect wastes crawl budget.
Changing URLs without mapping. The nightmare scenario: a redesign launches with a brand-new URL structure and no redirect map. Every old URL 404s overnight, years of link equity evaporates, and recovery takes months. Our guide on how to migrate your website to a new host without losing SEO covers the redirect-mapping discipline — the same process applies to any URL change.
The rule is simple: permanent move = 301, temporary situation = 302 — and the vast majority of your redirects will be 301s. Implement them at the server level, verify each one returns the right code in a single hop, keep chains short and loops nonexistent, and update internal links to skip the redirect entirely.
Generate correct redirect rules free with our htaccess Redirect Generator — paste in your old and new URLs and get working .htaccess code in seconds.
Nearly. Google has said 301s pass full PageRank, and in practice the vast majority of ranking signals transfer. There can be small losses in the real world — topical relevance shifts, anchor text dilution — but a proper 301 is the best available mechanism for preserving authority across a URL change.
At least a year — Google recommends keeping them until it's confident the migration is permanent, and external links to the old URL may exist forever. In practice, many sites keep important redirects indefinitely; they're cheap to maintain and removing them risks breaking old backlinks.
Yes, and you should as soon as you know the move is permanent. Google will reprocess the redirect as a 301 once it recrawls. The ranking recovery isn't instant — expect weeks — but it does happen. The longer a wrong 302 has been in place, the longer the recovery takes.
Each redirect hop adds a round trip — typically 100–300ms. One hop is negligible; chains of three or four become noticeable, especially on mobile. Keep chains to a single hop wherever possible and the performance impact is effectively zero.
Both are permanent. The difference only matters for non-GET requests: 308 guarantees the request method is preserved (a POST stays a POST), while 301 technically allows clients to change POST to GET. For normal web pages, they're interchangeable — use 301.
