301 vs 302 Redirect: The Complete Guide

When you move a page, change a URL, or migrate a site, you have to choose: 301 or 302. Most people guess. Some copy what they did last time. Getting it wrong doesn't break the site. Users still reach the right page. But it can quietly drain months of SEO value before you notice anything is wrong.

Here is the short answer. Use 301 when the move is permanent. Use 302 when the move is temporary and you genuinely plan to bring the original URL back. If you are not sure, use 301. The cost of the wrong call with a 302 is far higher than the cost of the wrong call with a 301.

The rest of this guide covers exactly what each redirect does, when each one belongs, what 307 and 308 add to the picture, how recovery looks when you use the wrong one, and how to verify your redirects are actually working.

What These Status Codes Actually Mean

301 and 302 are HTTP status codes. They're numbers a server sends back to a browser along with a "Location" header pointing to the new URL. The browser reads the code, follows the location, and the user lands where they should. That part is identical for both types.

The difference is what search engines do with the signal.

A 301 tells Google: this page has moved permanently. Stop indexing the old URL. Index the new one. Transfer the ranking signals (authority, backlinks, history) to the new destination. Over time (usually weeks), the new URL replaces the old one in search results and inherits its rankings.

A 302 tells Google: this page has moved temporarily. Keep the old URL in the index. Don't transfer ranking signals. The original might come back. Google holds the original URL's position in search results and does not pass authority to the destination.

For users, both redirects feel the same. For search engines and for your rankings, they behave completely differently.

301 vs 302 vs 307 vs 308: The Full Comparison

Most guides stop at 301 and 302. That leaves 307 and 308 unexplained, which matters when you are working with form submissions, API calls, or any request that uses POST instead of GET.

Status Code	Meaning	Permanent?	Preserves HTTP Method?	SEO Behavior	When to Use
301	Moved Permanently	Yes	No (POST may become GET)	Transfers ranking signals to new URL	Permanent URL changes, domain migrations, URL restructuring
302	Found (Temporary)	No	No (POST may become GET)	Passes PageRank; keeps the original URL canonical in the index	A/B tests, temporary campaigns, maintenance pages
307	Temporary Redirect	No	Yes (POST stays POST)	Same as 302 for SEO purposes	Temporary redirects where form/API method must be preserved
308	Permanent Redirect	Yes	Yes (POST stays POST)	Same as 301 for SEO purposes	Permanent redirects where form/API method must be preserved

For standard web pages and content URLs, 301 and 302 cover nearly everything. The method preservation distinction only matters when you are redirecting endpoints that receive POST requests, such as login forms, checkout flows, or API routes. In those cases, use 307 instead of 302, or 308 instead of 301, to prevent the browser from converting a POST request into a GET.

When to Use a 301 Redirect

Use 301 whenever the change is permanent. If you do not plan to bring the old URL back, use 301 every time without exception.

Domain and site migrations

Moving from HTTP to HTTPS. Switching from www to non-www (or back). Rebranding to a new domain. Every URL on the old origin should 301 to the equivalent URL on the new one. This tells Google to stop indexing the old URLs and start indexing the new ones. It also moves whatever authority those old URLs had built up to the new destination.

URL restructuring

Cleaning up slugs, removing dates from blog post URLs, dropping stop words, switching from /category/post-title/ to /post-title/. All of it needs 301 redirects from old to new. Without them, the new URLs start with zero history and Google has two pages for the same content.

Consolidating duplicate content

If you have two pages covering the same topic, pick the stronger one and 301 the weaker one to it. This concentrates ranking signals instead of splitting them. It also prevents Google from choosing canonicals you did not intend.

Retiring old pages

A product you no longer sell. A service page for something you stopped offering. A blog post replaced by a better one. 301 redirect these to the most relevant replacement. Google has said it may ignore "lazy" redirects to the homepage and treat the old URL as a 404 instead, so send people somewhere actually relevant.

Domain portfolio consolidation

Companies growing through acquisition or agencies managing multiple client domains often end up with a fleet of old domains pointing at new ones. Every one of those needs a 301, not just a DNS forward. DNS-level forwarding does not pass SEO signals the same way a proper HTTP 301 does.

When to Use a 302 Redirect

Use 302 only when the original URL is coming back. That sounds obvious. But the number of permanent changes set up as 302 redirects is genuinely high, and it is almost always because a developer picked the easier default rather than the right one.

A/B testing

You are testing a new version of a page at a different URL. The original URL will be the destination again once the test ends. Use 302 so Google does not start treating the test variant as the canonical URL. If you accidentally 301 a page you are A/B testing, you may find the test variant ranking after the test is over.

Temporary campaigns and seasonal pages

A flash sale landing page. An event registration page that only stays active during open enrollment. A seasonal campaign that runs every year at the same URL. The original URL is returning, so 302 is correct.

Maintenance and downtime pages

Sending users to a "we will be right back" page during scheduled maintenance. You want your real pages indexed and ranking normally once the maintenance window closes, so 302 tells Google not to replace your original URL with the maintenance page.

Geo-based routing during testing

Routing a segment of users to a localized page for testing purposes. If the routing logic is temporary or subject to change, use 302. Note: if you are doing permanent geo-routing, canonicals and hreflang tags are usually the better tool than redirects.

Login walls

Redirecting unauthenticated users to a login page is inherently temporary behavior. The original page still exists behind authentication. 302 is correct here.

The SEO Cost of Using the Wrong One

This is where the real damage happens, and it shows up slowly.

When you use 302 for a permanent move, Google keeps treating the original URL as canonical. Your new URL does not accumulate authority. All the ranking signals (the links, the history, the trust) stay attached to the old URL, which is now just a redirect pointing somewhere else. Over weeks and months, rankings erode. You may not connect the cause to the effect because the timing is off.

The pattern that shows up repeatedly: "I did 301s on every URL and still lost rankings." That story usually has a variant hiding in it. The 301s were not on every URL. The redirect chain had an unexpected hop through a 302. One URL was missed. The old domain had canonicals still pointing somewhere wrong. The redirects worked, but the signals did not fully consolidate.

Migrations that include correct 301 redirects on every URL can still drop in rankings if chains are present, URLs are missed, or crawl rate is slow during the transition period. These are not failures of the redirect type. They are failures of the redirect implementation. Chains, missing URLs, and slow crawl rates all compound the damage.

If You Used the Wrong One: Recovery

The fix is straightforward, but the recovery takes time.

If you used 302 when you meant 301: Change the redirect type to 301. Google will crawl the URL again, see the permanent redirect, and begin transferring signals to the destination. Expect 2 to 6 weeks for rankings to stabilize, depending on crawl frequency for your domain.

If you used 301 when you should have used 302: Remove the redirect or replace it with a 302. Google will re-index the original URL over time. Be aware: browsers that cached the 301 will keep sending users to the old destination until the cache clears. Chrome and Firefox cache 301s aggressively. The cache is often persistent until the user manually clears it. A 301 is not reliably reversible in the short term, and there is nothing you can do server-side to force returning visitors past a cached redirect.

If you are recovering from a redirect chain: Map the full chain, then collapse it. If URL A redirects to URL B which redirects to URL C, update A to point directly to C. Each hop in a chain dilutes the signal passing through and adds latency. Chains form when teams add redirects incrementally without auditing what already exists. A redirect map helps prevent this.

The Decision Framework

One question determines the answer almost every time:

Will the original URL ever be used again as a live page?

• No — use 301
• Yes — use 302
• Not sure — use 301

If you are still not sure after that, work through this:

1. Is this a permanent domain or URL change? Use 301.
2. Is this an A/B test or a campaign page that will end? Use 302.
3. Is this a maintenance page that will come down? Use 302.
4. Is this a page you are retiring? Use 301 to the most relevant replacement.
5. Does the request use POST and need method preservation? Use 307 (temporary) or 308 (permanent).
6. None of the above match? Default to 301. You can change it later if needed.

Real-World Scenarios

Scenario 1: Moving a blog post permanently

You wrote a post at /blog/2019/04/redirect-basics/. You are cleaning up your URL structure and moving it to /blog/redirect-basics/. The old URL is gone for good. This is a 301. Any links pointing to the old URL will pass their authority to the new one. Google will update its index to reflect the new canonical.

Scenario 2: Running an A/B test on a landing page

Your homepage is at /. You are testing a new hero section at /home-v2/. A portion of visitors get 302-redirected from / to /home-v2/ during the test. When the test ends, / goes back to being the live page. This is a 302. Google keeps / in its index throughout the test. The test variant does not accumulate authority or rankings you will need to undo later.

Scenario 3: Site migration where rankings disappear anyway

You migrated 500 pages with 301 redirects and rankings dropped. Before assuming the redirects failed, check: Are there chains? Are there any pages that were missed? Did you update your sitemap to the new URLs? Did you submit the new sitemap in Google Search Console? Did the canonical tags update? Are there any 302s mixed into what was supposed to be an all-301 migration? One missing step is usually the answer.

Implementing Redirects: The Manual Path

Most redirects on the web are still set up by hand in server configs. That works, but it ties every redirect change to a deploy, makes auditing hard, and doesn't scale once you're managing hundreds of rules across multiple domains. Here's what the manual approach looks like in the common stacks. Then we'll cover the case for managing redirects outside server config.

Apache (.htaccess)

The first two examples use mod_alias (loaded by default in most installs). The third uses mod_rewrite, which must be enabled separately.

# 301 - Permanent redirect (mod_alias)
Redirect 301 /old-page/ https://example.com/new-page/

# 302 - Temporary redirect (mod_alias)
Redirect 302 /temp-page/ https://example.com/destination/

# 301 - Redirect entire domain (mod_rewrite, for domain migrations)
RewriteEngine On
RewriteCond %{HTTP_HOST} ^olddomain\.com [NC]
RewriteRule ^(.*)$ https://newdomain.com/$1 [R=301,L]

Nginx

# 301 - Permanent redirect
location /old-page/ {
    return 301 https://example.com/new-page/;
}

# 302 - Temporary redirect
location /temp-page/ {
    return 302 https://example.com/destination/;
}

Node.js / Express

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

// 302 - Temporary redirect
app.get('/temp-page', (req, res) => {
  res.redirect(302, '/destination');
});

When the manual path breaks down

These configurations work fine for a handful of redirects on a single host. They start to creak when you're consolidating domains after an acquisition, running redirect audits before a migration, or trying to give non-engineers the ability to add a rule without filing a PR. Each redirect is invisible until someone reads the config file. Chains form quietly. Nobody knows who added what or when.

That's the gap RedirectBoss fills. Redirects live in a dashboard with chain detection, change history, and bulk import. No server config required, and no deploy cycle between adding a rule and having it live. The rest of this guide assumes you have a way to verify and audit what's actually in place, whether that's a tool or a careful manual process.

How to Verify Your Redirects Are Working

Never trust that a redirect is correctly set up without testing it. The easiest check uses curl from the command line:

# Check what status code and location header a URL returns
curl -I -L https://example.com/old-page/

The -I flag returns headers only. The -L flag follows redirects. Look for the HTTP status code (301 or 302) and the Location header showing where the redirect points. If you see a 200 at the final destination, the full redirect chain resolved correctly.

To see every hop in a redirect chain:

curl -I -L --max-redirs 10 https://example.com/old-page/ 2>&1 | grep -E "HTTP/|Location:"

This shows the status code and location at each step. Any unexpected 302 in what should be a 301 chain, or any chain longer than one hop, is worth fixing before it causes ranking problems.

For teams managing a large number of redirects across multiple domains, the manual curl check does not scale. A redirect management platform with a built-in analytics layer lets you verify status codes, catch chains, and audit redirect behavior without running scripts across hundreds of URLs. RedirectBoss is built for exactly that. Manage and audit your redirects from a dashboard without touching server configs or writing curl commands for every URL.

If you are not comfortable with the command line, Google Search Console gives you a non-technical path to the same information. Open the URL Inspection tool, paste any URL, and it will show you how Google sees it, including whether a redirect is present and where it points. For broader coverage, the Pages report surfaces indexing issues across your whole site, including a "Page with redirect" category that lists URLs Google found to be redirect sources rather than canonical pages. If you are expecting a URL to rank and it appears there, something in your redirect setup is telling Google the wrong thing.

Frequently Asked Questions

Does a 301 pass full link equity?

Google has confirmed that 301 redirects pass the same PageRank as a direct link. Most SEOs observe a small reduction in practice, but for working purposes a 301 transfers the large majority of a URL's ranking signals to the destination.

Does a 302 pass link equity?

Yes. Google's John Mueller and Gary Illyes have both confirmed that 302 redirects do pass PageRank. The common belief that 302s "don't pass equity" is outdated. The real difference between 301 and 302 is indexing behavior and signaling clarity, not equity transfer. A 302 tells Google the original URL is still canonical, so Google keeps the source URL in the index rather than replacing it with the destination. Use 302 when you want that behavior. Use 301 when you want the destination URL to become canonical and inherit the rankings.

How long does a 301 take to take effect in Google?

Googlebot needs to crawl the old URL to detect the redirect. For frequently crawled, established sites, this can happen within days. For lower-priority URLs, it may take a few weeks. The full ranking effect, meaning the new URL ranking where the old one was, typically takes 2 to 4 weeks from the time the redirect is crawled.

Can I reverse a 301 redirect?

Yes, but not instantly. Remove or change the redirect and Google will re-index the original URL over time. Browser caches are a bigger short-term problem. A browser that cached a 301 will keep redirecting users to the old destination until the cache expires. Do not rely on 301s to be easily reversible on a short timeline.

What happens if I leave a 302 in place for a long time?

Google has indicated that a long-standing 302 may eventually be treated as a 301, but no specific timeframe has been published and the behavior is not something you can rely on. If the move is permanent, change the redirect type. Don't wait and hope Google reclassifies it for you. A 302 that lingers long enough to get promoted creates the same problem as a misused 301, but without you making an explicit choice.

What happens if I do not set up any redirect?

The old URL returns a 404 (Not Found) or 410 (Gone). Google removes it from the index. Any links pointing to that URL stop passing authority. They point into a dead end. If the page has any organic traffic or inbound links, always set up a redirect when you move or retire it.

Do redirects slow down my site?

Each redirect adds latency, typically 50 to 300ms per hop. A single redirect is negligible. A redirect chain (URL A to B to C) compounds the delay and should be collapsed to a single hop. Keep your redirect architecture flat: one hop from source to destination wherever possible.

Summary: Which Redirect Should You Use?

Situation	Use This	Why
Permanent page move	301	Transfers ranking signals to new URL
Domain migration or rebrand	301	Consolidates all authority to new domain
URL restructuring	301	Old rankings carry over to new slugs
Retiring old content	301 to best match	Preserves whatever authority the old URL had
A/B test variant	302	Keeps original URL canonical; no ranking side effects
Temporary campaign page	302	Original URL returns to active after campaign ends
Maintenance redirect	302	Real pages stay indexed while site is down
Login wall	302	Original page exists behind authentication
Redirect with POST method preservation	307 (temp) or 308 (perm)	Prevents POST from converting to GET at the redirect
Not sure	301	Lower downside risk than 302 for an unknown case

301 and 302 redirects do the same thing for users. They do very different things for your search rankings. The distinction is not technical complexity. It comes down to one question: is this move permanent? If yes, 301. If not, 302. Get that right and the rest follows.