Use a 301 when the move is permanent and you want search engines to consolidate ranking signals at the new address. Use a 302 when the change is temporary and you want the original URL to keep its rankings while it’s away. If you’re merging domains, switching to HTTPS, or retiring a URL for good, that’s a 301. If you’re running an A/B test, a flash sale, or maintenance page, that’s a 302. Get this wrong and you either strand your link equity or accidentally kill a page you meant to bring back.
TL;DR:
- A 301 redirect is suitable for permanent moves like domain migrations, HTTPS upgrades, or structural URL changes, ensuring search signals consolidate over time.
- A 302 redirect is best for short-term scenarios such as A/B testing, sales promotions, or maintenance pages, where the original URL should remain indexed and rank intact.
- Search engines treat 301s as definitive, gradually transferring link equity, while 302s often keep the original URL’s ranking unless left in place for many months or years.
- Use 307 or 308 instead of 302 or 301 when redirecting form submissions or API requests to preserve the original request method and body.
- Always verify redirect response codes via server tools and monitor indexing and traffic data to prevent unintended long-term temporary redirects or redirect chains.
Table of Contents
- What Do 301 and 302 Status Codes Actually Mean?
- How Do 301 and 302 Redirects Affect SEO Rankings?
- Method Handling, Caching, and When to Use 307 or 308
- When Should You Use a 301 Redirect?
- When Should You Use a 302 Redirect?
- How Do You Implement Redirects in Apache, Nginx, and WordPress?
- How Do You Test and Monitor a Redirect?
- What Are the Most Common Redirect Mistakes?
- A Practical Note on Redirect Discipline
- A Simpler Way to Handle Campaign Redirects
- Sources
What Do 301 and 302 Status Codes Actually Mean?
Both codes live in the HTTP 3xx family, and both tell a browser or crawler “go somewhere else.” The difference is in the promise each one makes.
A 301 means “Moved Permanently.” The server is telling every client, human or bot, that the resource has a new home and it isn’t coming back to the old one. A 302 means “Found,” which HTTP’s original spec used to call temporary redirect. The resource still technically lives at the original URL. It’s just parked somewhere else for now.
Both send a Location header pointing to the new URL, and both cause the browser to follow that header automatically, usually without the user noticing anything happened. Where they diverge is caching. Browsers and CDNs are allowed to cache a 301 aggressively, sometimes remembering it long after you’ve changed your mind, according to MDN’s redirection guide. A 302 is meant to be checked again on the next request, which is exactly why it fits short-lived changes.
Three related codes matter here too. 303 (See Other) tells the client to fetch the new location with a GET request, which is the right call after a form submission. 307 (Temporary Redirect) and 308 (Permanent Redirect) are the method-safe versions of 302 and 301. They guarantee the browser repeats the original request method and body instead of silently switching to GET, a distinction that trips up more developers than it should.
How Do 301 and 302 Redirects Affect SEO Rankings?
The core SEO question isn’t “which code is better.” It’s “which URL do you want search engines to treat as the real one, and how fast do you need that to happen?”
A 301 usually signals to Google that the destination URL should become canonical, and over time the search engine consolidates backlinks, anchor text signals, and ranking history toward that new address, according to Ahrefs. This consolidation isn’t instant; it happens gradually as Google recrawls the old URLs and re-evaluates the relationship.
A 302, by contrast, typically leaves the original URL in the index and lets it keep ranking, because the redirect is framed as short-term. Links pointing at the old URL generally stay associated with it rather than passing through to the destination, at least until Google decides otherwise.
That last clause matters more than most guides let on. Search engines are pattern-matchers, not rule-followers. If a “temporary” 302 sits in place for months or years, Google will often start treating it as a de facto permanent move, regardless of what the status code claims. That’s a real risk for any site running long-lived 302s out of habit rather than intent.
A few practical ways to check what Google is actually doing with a given redirect:
- Run the destination and source URLs through Search Console’s URL Inspection tool and compare which one Google reports as indexed.
- Watch organic traffic on the old URL. If it’s still pulling meaningful search traffic weeks after a supposed permanent move, something’s off.
- Check whether the old URL still appears in search results at all. A 301 that’s been fully processed usually drops the source from the index in favor of the destination.
Pro Tip: If you set up a 301 and traffic doesn’t shift within a few weeks, don’t assume Google is slow. Check for a redirect chain or a mismatched canonical tag first. Those two issues account for most delayed consolidations.
Method Handling, Caching, and When to Use 307 or 308
Redirects don’t just move a URL. They can also change what request the browser sends next, and that catches people off guard.
Historically, both 301 and 302 allowed clients to convert a POST request into a GET when following the redirect. That’s fine for a simple page move, but it’s a problem if you’re redirecting a form submission or an API call where the method and body actually matter. MDN’s documentation on 302 responses is explicit about this: user agents may switch the method to GET, and if you need the original method preserved, use 307 instead.
That’s the whole reason 307 and 308 exist. They carry the exact same permanence semantics as 302 and 301, respectively, but they guarantee the request method and body survive the trip. If your redirect sits behind a login flow, a payment gateway, or any API endpoint, 307 and 308 are the safer defaults, not 302 and 301.
Caching adds another wrinkle. Because clients and CDNs are allowed to cache 301s hard, testing one during development can leave you staring at stale behavior long after you’ve fixed the underlying rule, an issue frequently reported in developer discussions on Stack Overflow. Use a temporary code or force a hard refresh while you’re still iterating, and only switch to a permanent code once the destination is final.
Use 303 specifically after a POST, when you want the browser to fetch the confirmation page with a clean GET rather than resubmitting the form.
When Should You Use a 301 Redirect?
A 301 is the right call whenever the old URL is never coming back. Common scenarios include:
- Domain migrations — moving an entire site from one domain to another.
- Protocol upgrades — forcing HTTP traffic to HTTPS.
- Permalink or URL structure changes — restructuring slugs, categories, or folder paths.
- Site consolidations — merging two sites or sections into one.
- Retired pages and discontinued products — pointing dead URLs to the closest live equivalent instead of a dead end.
Before you flip the switch, run through this checklist:
- Confirm the destination page actually contains equivalent or better content. A 301 to an unrelated page confuses users and wastes the ranking signal you’re trying to preserve.
- Implement the redirect server-side, never with a JavaScript snippet or meta refresh.
- Check for redirect chains, where URL A redirects to B, which redirects to C. Point A directly at C instead.
- Use Search Console to request reindexing on high-value pages if the update seems slow to register.
- Leave the redirect live indefinitely. Removing it early strands anyone still holding the old link, including other websites’ backlinks.
Pro Tip: Give Google at least a few weeks, often longer for large sites, before judging whether a 301 has “worked.” Ahrefs’ guidance on redirect consolidation notes the transfer happens progressively, not instantly, so check URL Inspection periodically rather than once and giving up.
When Should You Use a 302 Redirect?
A 302 fits any situation where the original URL needs to stay the canonical, indexed version while something temporary happens around it.
That covers A/B testing variants, limited-time promotional pages, maintenance windows, and geo-based routing where you still want the base URL treated as the “real” page once the routing logic resolves.
A few best practices keep a 302 from misbehaving:
- Set an explicit internal deadline for how long the redirect should live, and revisit it. “Temporary” redirects that never get reviewed are how sites accidentally end up with permanent 302s.
- Use 307 instead of 302 whenever the redirected request involves a form, API call, or anything where the method must survive the hop.
- Monitor the original URL’s indexing status and organic traffic periodically. If it drops out of search results or traffic quietly shifts to the destination, Google may be reading your “temporary” redirect as permanent.
If you spot that drift, the fix is simple: either remove the redirect and restore the original page, or formally switch it to a 301 if the change turned out to be permanent after all. Don’t leave it ambiguous.
How Do You Implement Redirects in Apache, Nginx, and WordPress?
Server-side implementation is almost always the right choice over client-side alternatives, because crawlers process HTTP status codes far more reliably than JavaScript execution.
On Apache, a basic permanent redirect in .htaccess looks like this:
Redirect 301 /old-page/ /new-page/
RedirectMatch 301 ^/blog/(.*)$ /articles/$1
The Redirect permanent directive maps directly to a 301 response, as Apache’s own documentation confirms. Drop the “301” and Apache defaults to a temporary redirect instead.
On nginx, the equivalent sits in the server block:
return 301 https://example.com/new-page/;
Swap 301 for 302 and the redirect becomes temporary. For DNS or registrar-level forwarding, that’s useful for pointing a bare domain at a subdomain, but it’s a blunter tool. It won’t preserve full paths or handle pattern matching the way server config or .htaccess can.
If you’re on WordPress and don’t want to touch server config, plugins like Redirection handle both 301 and 302 rules through a dashboard. Avoid JavaScript-based redirect plugins for anything SEO-critical. They load after the page has already responded with a 200, which crawlers can misread entirely.
Pro Tip: Whatever method you choose, verify the actual response code afterward. Plugin settings and cached pages sometimes silently serve a different status than the one you configured.
How Do You Test and Monitor a Redirect?
Confirm the technical response before trusting anything visually.
- Run
curl -I https://example.com/old-page/to see the status code andLocationheader without following the redirect, or add-Lto follow the full chain and see every hop. - Check your browser’s network tab in devtools to watch the actual request sequence, including any unexpected intermediate redirects.
- Use Search Console’s URL Inspection tool to see which version Google has indexed and whether it considers the redirect resolved.
- Run a site crawler periodically to catch chains, loops, or redirects that quietly broke after a template change.
What Are the Most Common Redirect Mistakes?
Most redirect problems trace back to a handful of repeat offenders.
- Redirect chains and loops. Each extra hop dilutes signal strength and burns crawl budget. Point straight to the final destination.
- Accidental permanent 302s. A redirect meant as a quick fix that nobody revisits for two years. Check Search Console periodically and convert to a 301 if the move turned out permanent.
- Client-side and JavaScript redirects. They delay signal transfer and can be missed entirely by crawlers that don’t execute scripts consistently.
Pro Tip: When something looks wrong during testing, check the server response with curl before blaming your code. Browser caching hides more redirect bugs than actual misconfiguration does.
A Practical Note on Redirect Discipline
Most redirect mistakes I see aren’t about picking the wrong code. They’re about never revisiting the choice once it’s live. A 302 set up for a two week promotion becomes a permanent fixture nobody remembers to audit, and by then the analytics on both URLs are a mess. Decide intent, choose the code, implement it server side, test it, then actually monitor it.
— Andrea
A Simpler Way to Handle Campaign Redirects
For a lot of marketing redirects, rewriting server rules is overkill. Rdyrct gives you branded short links and QR codes that handle the redirect logic outside your site architecture entirely, so a seasonal promotion or a paid campaign doesn’t require touching .htaccess or nginx config every time it starts or ends.
Because some URL shortening services don’t store IP addresses, you can get referrer, device, and country level analytics without the privacy tradeoffs that come with typical tracking setups, which matters if you’re running the kind of temporary or A/B campaign links this article just covered. It works alongside your existing 301 and 302 rules rather than replacing them. Site-wide moves still belong on the server; campaign links, promo codes, and QR-driven traffic are where a dedicated short-link workflow earns its place, an approach also covered in this breakdown of branded short-link alternatives. Check the pricing tiers, including the free forever plan, and set up your first branded link at Rdyrct to see how the analytics look on your next campaign.