301 vs 302 Redirects: When to Use Each

TL;DR: Permanent move gets a 301, genuinely temporary move gets a 302. Pick wrong and Google indexes the wrong URL. Use the decision table below, then read the canonicalization section if you want to understand the mechanism.

The 30-second answer (decision table)

Before anything else: here's the scenario-to-code map. If you're in a hurry, this is the article.

Flowchart showing the redirect decision process: Is the move permanent? Yes leads to 301. Does the method need preserving? Yes leads to 308. Temporary? Yes leads to 302 or 307 for method-safe. — Redirect decision tree: which HTTP status code to use based on permanence and method requirements.

Scenario	Code	Why
Site migration / domain change	301	Permanent. You want Google to reindex the new domain.
HTTP to HTTPS consolidation	301	Permanent. Old URLs are gone for good.
A/B test (returning to original)	302	Temporary. Keep the original URL as canonical.
Maintenance page	302	Temporary. The real page is coming back.
Out-of-stock product (coming back)	302	Temporary. Preserve the product URL's ranking.
Discontinued product (gone forever)	301	Permanent. Send equity to the closest equivalent.
Geo / language routing	302	Temporary. The original URL still serves most users.
Marketing campaign landing page	302	Temporary. Campaign ends, URL returns to normal.
Login / checkout POST flow	307	Method-safe. Preserves POST body; 302 would flip to GET.
Consolidating duplicate URLs (permanent)	301	Permanent. One canonical from now on.

If you find yourself debating whether something is "permanent enough" for a 301, it probably is. The bar is whether you intend to maintain the destination URL long-term — if you're confident you will, use 301.

What a redirect actually is

When a browser or crawler requests a URL, the server can respond with a 3xx status code instead of the page content. That code says: "The resource you want is somewhere else." The Location header in the response tells the client where to go next.

The 3xx family covers a range: 301 (Moved Permanently), 302 (Found / Moved Temporarily), 303 (See Other), 307 (Temporary Redirect), 308 (Permanent Redirect), and a few others. For SEO purposes, 301, 302, 307, and 308 are the ones that matter. The rest are edge cases.

301: what "permanent" tells Google

A 301 is a signal to both the browser and the indexing pipeline that the old URL is gone for good. Google's own documentation puts it plainly: "If you need to change the URL of a page as it is shown in search engine results, we recommend that you use a permanent server-side redirect whenever possible."

The indexing pipeline treats the 301 as a canonical signal. Google follows the redirect, then marks the destination URL as the one to keep in the index. Over time, the old URL stops appearing in search results and the new one takes its place. Rankings, cached pages, and consolidated signals all shift to the destination.

One thing I'd stress from experience: permanent means permanent. Google advises using permanent redirects "when you're sure that the redirect won't be reverted." If you put up a 301 and then tear it down six months later, you're not undoing the signal cleanly. Googlebot needs to recrawl the old URL and reprocess everything. I've watched clients do this during a revert and spend weeks wondering why rankings had gone sideways. Keep the 301 in place for at least a year, ideally longer.

302: the temporary move and the consolidation trap

A 302 tells Google: keep the original URL in your index, this move is temporary. Google's guidance is direct: "If you just want to send users to a different page temporarily, use a temporary redirect."

Googlebot follows a 302 just like a 301. The difference is what the indexing pipeline does afterward. With a temporary redirect, Google does not treat the destination as canonical. The original URL stays the indexed one. For a maintenance page or A/B test, that's exactly the behavior you want.

The trap is using a 302 for a permanent move because someone wasn't sure, or because it was "easier to change later." Google sometimes reinterprets a long-lived 302 as a 301, but I wouldn't count on it. I've seen sites run a 302 for months on a migrated domain and find that Google had never fully reindexed the new URLs. Don't rely on Google's heuristics here. Be explicit.

The link-equity myth (and what actually differs)

Here's the thing almost every article on this topic gets wrong: 302 redirects do not leak link equity.

In 2016, Gary Illyes, a Google Webmaster Trends Analyst, posted it directly: "30x redirects don't lose PageRank anymore." That covers 301s, 302s, and every other 3xx. All of them pass PageRank.

John Mueller explained the mechanism in a Webmaster Hangout: "We can forward PageRank through 301 and 302 redirects. Essentially what happens there is we use these redirects to pick a canonical. By picking a canonical we're concentrating all the signals that go to those URLs to the canonical URL."

Read that carefully. The mechanism is canonical consolidation, not a pipe that passes juice from one URL to another. Signals accumulate at whichever URL Google treats as canonical. The redirect type determines which URL that is.

So the real question is: which URL do you want Google to treat as canonical? A 301 makes the destination canonical. A 302 keeps the source canonical. That's the actual decision.

(I should note: equity recognition isn't instant even with a 301. Google has to recrawl the old URL first, and the consolidation happens over multiple crawl cycles. The relevance of the destination still matters too. A 301 from a cooking blog to a software landing page won't consolidate neatly.)

301 vs 302 at a glance

Property	301 Moved Permanently	302 Found
HTTP meaning	Resource moved permanently	Resource moved temporarily
Canonical signal to Google	Destination URL becomes canonical	Source URL stays canonical
Passes PageRank?	Yes	Yes
URL Google indexes	Destination (new)	Source (original)
Method preserved on POST?	No (historically flips to GET)	No (historically flips to GET)
When to use	Permanent moves, migrations, HTTPS, consolidation	A/B tests, maintenance, geo routing, campaigns
Reversal cost	High: Google needs time to reprocess	Low: original URL stays indexed

307 and 308: the codes nobody mentions

307 and 308 exist because 301 and 302 have a method-change problem. When a browser follows a 301 or 302 from a POST request, the Fetch spec permits it to switch the method to GET for the redirected request. That can silently break login flows, checkout submissions, and API endpoints.

307 fixes this for temporary redirects. MDN puts it plainly: "307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET." If you're routing a POST-based form temporarily and need the POST to survive, 307 is the correct code.

308 does the same for permanent redirects. It prohibits method change entirely, unlike 301, where clients historically coerced the request to GET. If you're permanently redirecting an API endpoint that receives POST data, 308 is stricter and safer.

For purely GET-based pages (which is most web content) 307 and 302 behave identically, and 308 and 301 behave identically. The method distinction only matters when POST or PUT bodies are in play.

Table showing how Google treats each redirect type: 301 and 308 as permanent with canonical signal to destination; 302, 303, and 307 as temporary keeping source canonical; meta-refresh 0 seconds as permanent; meta-refresh greater than 0 seconds as temporary; JavaScript redirects as slower and less reliable to process than server-side redirects. — How Google's indexing pipeline interprets different redirect types. Source: Google Search Central.

One more thing worth mentioning: meta-refresh redirects and JavaScript-based redirects (window.location) also exist. Google treats a meta-refresh with 0-second delay as permanent (equivalent to 301), and one with any delay as temporary. JavaScript location redirects are a different story: Google can follow them when it renders the page, but they're slower to process, may be missed on crawls without full rendering, and they carry no explicit permanent/temporary signal. Server-side redirects are always the better choice.

The redirect-chain trap

Chains form when you redirect A to B, then later redirect B to C, without updating A. The user and Googlebot follow A to B to C instead of going directly to C.

Side-by-side comparison: BAD shows a redirect chain from old-page to /v2 to /v3 to /final with annotations showing latency and crawl waste at each hop. GOOD shows a single direct redirect from old-page to /final. — Redirect chains vs. direct redirects. Each unnecessary hop adds latency and crawl risk.

Every hop adds latency. Real user latency, measurable in milliseconds, which affects Core Web Vitals on mobile. Every hop is also another point of failure: if any URL in the chain returns a 404, everything behind it breaks.

Google's site-move documentation says Googlebot can follow up to 10 hops in a chain, but also advises redirecting to the final destination directly. John Mueller was more specific: "The only thing I'd watch out for is that you have less than 5 hops for URLs that are frequently crawled." Googlebot tolerates up to 10 before flagging an error; Mueller's practical ceiling is 5; the real target is 1.

Chains pile up quietly over years of migrations. A site that moved from .com to .io to .com again, changed its URL structure twice, and ran A/B tests on category pages can accumulate chains without anyone noticing. (Running audits with SEOJuice, the most common finding is a boring four-hop chain on a high-traffic URL left over from a migration nobody updated. Chains from campaigns and A/B tests are the second most common culprit, usually because the temporary 302 never got cleaned up afterward.) Then someone runs a crawl and finds the homepage is three hops deep.

The fix is always the same: identify the final destination and update the first redirect to point there directly. Collapse it. Don't wait for Google to navigate through.

Loops are the pathological case. A redirects to B, B redirects to A, and the browser throws ERR_TOO_MANY_REDIRECTS. This is usually a misconfigured HTTPS rule or a CMS redirect that creates a cycle. Audit tools catch these immediately.

How to audit redirects on your site

What to look for:

Wrong code for the scenario: a permanent migration served as a 302, or a temporary test that became permanent without being updated to 301
Chains: any A to B to C sequence where you could go A to C directly
Loops: any cycle that produces ERR_TOO_MANY_REDIRECTS
Redirects to 404s: the destination URL no longer exists; you're sending users and bots to a dead end
Stale 302s: content that moved months or years ago and was never promoted to permanent

For a quick manual check, curl -I https://yourdomain.com/old-url shows you the status code and Location header without loading the full page. Browser devtools (Network tab, "Preserve log" checked) shows you the full redirect sequence for any URL. These are fine for spot-checks. For systematic coverage, you need a crawler.

Screenshot of the SEOJuice SEO audit tool showing flagged redirect issues including a redirect chain, a 302 that should be a 301, and a redirect pointing to a 404 page. — SEOJuice's audit tool surfacing redirect issues: chains, wrong codes, and dead-end redirects.

The SEOJuice SEO audit crawls your site and flags redirect chains, loops, wrong-code redirects, and hops to 4xx destinations. It's the fastest way to get a complete picture without manually curling hundreds of URLs. Also worth checking: any high-traffic URLs from your SEO hygiene audit. Those are the ones where a buried chain actually costs you.

Single-page applications need extra attention here. JS-based routing can create redirect-like behavior that server-side crawlers miss entirely. If you're running a React or Next.js site, see the notes on SPA redirect handling. The edge cases with window.location and client-side routing interact with Google's JavaScript execution in non-obvious ways.

Frequently Asked Questions

Does a 302 redirect pass link equity (SEO value)?

Yes. Google has confirmed that PageRank flows through 301, 302, and all 3xx redirects. Gary Illyes stated in 2016 that "30x redirects don't lose PageRank anymore," and John Mueller explained that both 301 and 302 forward signals through canonical consolidation. The redirect type controls which URL Google keeps in the index, not whether equity flows.

Is 301 or 302 better for SEO?

Neither is inherently better. The right code depends on whether the move is permanent. Use 301 when the destination URL is the one you want indexed going forward. Use 302 when the original URL should stay indexed and you genuinely intend to restore it. Getting this wrong doesn't cost you link equity; it puts the wrong URL in Google's index.

How long until Google honors a 301 redirect?

There's no fixed timeline. Google has to recrawl the old URL before it can process the signal, which can take anywhere from a few days to several weeks depending on crawl frequency. Keep the 301 live for at least a year. Removing it early reverts the canonical signal, and you'll need Googlebot to recrawl and reprocess everything from scratch.

Can too many redirects hurt rankings?

Yes, but indirectly. Redirect chains add latency, waste crawl budget, and introduce failure points. Google recommends redirecting to the final destination directly; Mueller's practical guidance is fewer than 5 hops for frequently crawled URLs. The effect is the accumulated result of slower page load, reduced crawl efficiency, and the risk that a broken hop mid-chain takes down the whole sequence — not a direct ranking penalty.

Related reading:

Run a free SEO audit to find redirect chains, loops, wrong-code redirects, and hops to dead pages on your site.

Our powerful suite of automation tools for SEO

Learn, discover, and get inspired by our content