Most explanations of 301 vs 302 redirects stop at four words — “permanent versus temporary” — and leave you to guess which one your situation calls for. That’s not wrong, but it’s the map, not the territory. The word that actually matters to a search engine isn’t “permanent” or “temporary”; it’s which URL Google keeps in its index as the canonical one. Pick the wrong status code and you don’t get a warning — you get the wrong page ranking, or two pages competing, or a browser that refuses to un-redirect for months. This guide covers the real mechanism behind 301 vs 302 redirects, the myths worth ignoring, and a decision rule you can apply fast.
The One-Line Answer
A 301 is a permanent redirect: the resource has moved for good, and every request should now go to the new URL. A 302 (officially “Found”) is a temporary redirect: the resource lives somewhere else right now, but the original URL is still the real home and will return. If the move is forever, use 301. If the original URL is coming back, use 302. Everything else here is about the consequences that flow from that single choice.
What Actually Changes for Google: The Canonical Signal
Here is the part the “permanent vs temporary” framing hides. A redirect isn’t just a routing instruction for browsers — it’s a signal to Google about which URL to keep in the index. When Googlebot follows a 301, it reads it as “consolidate everything onto the destination,” and over subsequent crawls it drops the old URL and indexes the target as canonical. When it follows a 302, it reads “the source is still the real page — keep indexing that one.” Google forwards signals in both cases, but the URL it chooses to show in search results differs.
That distinction is the whole game. If you permanently move a page but serve a 302, Google may keep the old URL indexed for weeks, splitting signals between two addresses and slowing the destination’s ability to rank. Google does eventually reinterpret a long-lived 302 as a de-facto 301 if the move looks permanent — but “eventually” is unreliable and slow, and you don’t want your migration hostage to a heuristic. Distinguish crawling (Googlebot fetching the URL), from indexing (deciding which URL to store and rank). The redirect type steers the second decision, and that’s why it matters far more than “temporary” implies.
Do 302 Redirects Pass PageRank? Killing the Oldest Myth
The most persistent myth in the 301 vs 302 redirects debate is that 302s “leak” or “block” link equity. This was arguably true a decade ago and is false now. Google has stated repeatedly that both 301 and 302 redirects pass PageRank and ranking signals — no equity is lost through the redirect type itself. So the real risk of a 302 on a permanent move is not lost link equity. It’s the indexing confusion above: the wrong URL staying canonical, two versions competing, and a delayed consolidation.
The practical takeaway: stop worrying about “power leaking” through a 302 and start worrying about which URL you want in the index. If the answer is “the destination, permanently,” a 301 tells Google exactly that in the fewest crawls. A 302 makes Google infer your intent, and inference takes time you usually don’t have during a migration.
The Browser-Caching Trap With 301s
This is the gotcha that burns people, and almost no beginner guide mentions it. Browsers cache 301 redirects aggressively — often indefinitely — because “permanent” is a promise the browser takes literally. Once a visitor’s browser has cached /old-page → /new-page as a 301, it stops asking your server entirely and jumps straight to the destination. If you later realize the redirect was a mistake and want to undo it, you can’t reach those users’ browsers to tell them. The only reliable fix is to set up a counter-redirect at the destination, which is ugly.
302s, by contrast, are not cached by default, so the browser rechecks your server each time. This makes the 302 the safer choice whenever there’s any chance you’ll change your mind — testing a layout, running a promotion, routing traffic during maintenance. Reach for 302 not because of SEO, but because a cached 301 is nearly impossible to walk back. If you must ship a 301 you might reverse, at least set a short Cache-Control: max-age so browsers revalidate.
307 and 308: The Method-Preserving Cousins You Should Know
301 and 302 have a quirk baked into the older HTTP spec: clients are allowed to change the request method on redirect — a POST can silently become a GET. For a content page that’s harmless. For a form submission, an API call, or a payment request, it can corrupt the action. That’s what 307 and 308 exist to fix.
- 301 (Moved Permanently) — permanent; method may change to GET. The default for permanent content moves.
- 302 (Found) — temporary; method may change to GET. The default for temporary reroutes.
- 307 (Temporary Redirect) — temporary; method and body are preserved. Use for POST/PUT that must reach the new URL intact.
- 308 (Permanent Redirect) — permanent; method and body preserved. The strict, modern permanent redirect for non-GET requests.
For everyday SEO — moving pages, consolidating duplicates, forcing HTTPS — 301 and 302 are what you want, and Google treats 307/308 the same way it treats their older counterparts for indexing. Reach for 307/308 specifically when preserving the HTTP method matters, most often on forms and APIs. Also note: when you enable HSTS, the browser performs an internal 307 to upgrade HTTP to HTTPS before a request even leaves the machine — a detail worth recognizing in logs so you don’t mistake it for a server-side redirect.
When to Use a 301 (Permanent)
Use a 301 whenever the change is intended to last. Concrete cases:
- Domain migration — moving from
olddomain.comtonewdomain.com, mapped URL-to-URL, not all pointed at the homepage. - HTTP → HTTPS — forcing every request onto the secure version, site-wide.
- URL restructuring — changing a permalink pattern, folding
/blog/postinto/articles/post. - Consolidating duplicates — collapsing
wwwvs non-www, trailing-slash variants, or two near-identical pages into one. - Deleted pages with a close equivalent — retiring an old product page and sending it to its replacement (not to the homepage — a soft-404-style redirect to an irrelevant page can be treated as a 404 anyway).
The rule of thumb: if a user typing the old URL a year from now should land on the new one, it’s a 301.
When a 302 (or 307) Is the Right Call
Use a 302 when the original URL is the permanent home and the detour is genuinely temporary:
- A/B tests — routing a slice of traffic to a variant while the canonical URL stays indexed.
- Geo or language routing — sending a visitor to a localized page while keeping the generic URL canonical (pair with proper hreflang, don’t rely on the redirect alone).
- Maintenance or downtime — pointing a page at a holding notice you’ll remove in hours.
- Temporarily out-of-stock products — routing to the parent category until the item returns, so you don’t lose the product URL’s history.
- Seasonal or campaign pages — sending
/saleto this year’s landing page, then repointing it next year.
The rule of thumb: if the original URL should keep ranking and you plan to lift the redirect, it’s a 302.
How to Implement Them Correctly
The status code lives in the server response header, so implement redirects at the server or edge — not with a meta-refresh tag or JavaScript, both of which are slower, weaker signals and can be missed or delayed in Google’s render queue. A server-side 301/302 is instant and unambiguous.
Apache (.htaccess), a single permanent redirect:
Redirect 301 /old-page /new-page
Nginx, forcing HTTPS permanently:
return 301 https://$host$request_uri;inside the port-80serverblock.
Nginx temporary reroute: return 302 /maintenance;. Whatever the stack, confirm the actual header with curl -I https://yoursite.com/old-page and read the HTTP/… status line and Location value. What you configured and what the server returns after caching, CDNs, and rewrite rules are not always the same thing — verify the wire, not the config file.
Redirect Chains, Loops, and Crawl Budget
A redirect that works still costs you if it’s the third hop in a chain. Chains — A → B → C → D — waste crawl budget, add latency for users, and can dilute or delay signal consolidation; browsers and bots also cap how many hops they’ll follow before giving up. Whenever you add a redirect, update the source to point at the final destination in one hop. After a migration, the classic mistake is layering the new redirect on top of an old one and creating a two- or three-step chain nobody notices.
Redirect loops (A → B → A) are worse: they return a browser error and make the page unreachable for users and uncrawlable for bots. Both problems are invisible from the front end — the page can look fine because your browser cached the first hop — which is why redirects need auditing at the response level, not eyeballing.
How to Find the Redirect Problems Hiding on Your Site
You can catch redirect issues with a manual desktop crawl, and for a deep one-off migration audit a dedicated crawler still earns its place. The gap is continuity: chains and loops accumulate quietly every time someone edits a URL, launches a campaign, or ships a maintenance page and forgets to remove it. SEO Rocket‘s real-crawler site audit runs continuously and flags status-code problems — redirect chains, loops, 302s that should be 301s, and broken links returning 404s — with the fix explained, so you find the two-hop chain before it’s costing crawl budget rather than during your next migration post-mortem. It won’t replace log-file forensics on an enterprise crawl, but as a no-setup layer watching every crawl, it closes the gap manual audits leave.
Pair that with rank tracking to confirm a migration held: if the destination URLs climb and the old ones drop out cleanly, your 301s did their job. It reflects a playbook proven across 1,000,000+ ranking pages — redirects are plumbing, and plumbing fails silently until someone watches the pipes.
Frequently Asked Questions
Is a 302 bad for SEO?
Not inherently. A 302 used correctly — for a genuinely temporary reroute — is exactly right and passes ranking signals just fine. A 302 is only “bad” when it’s used for a permanent move, because Google may keep the old URL indexed instead of consolidating onto the new one. Match the code to the intent and there’s no penalty.
Do 301 redirects lose link equity?
No meaningful loss. Google forwards PageRank and ranking signals through both 301 and 302 redirects. The old “you lose 15% through a redirect” figure is outdated. What actually costs you is chaining several redirects together or pointing links at a URL that then 404s — not the redirect type itself.
How long should I keep a 301 redirect in place?
Treat 301s as effectively permanent — keep them for at least a year, and ideally indefinitely if the old URL still receives any traffic or links. Google needs to recrawl the old URL multiple times to fully transfer signals, and external sites and bookmarks may point at the old address for years. Removing a 301 too early resurrects 404s.
What’s the difference between a 302 and a 307?
Both are temporary. The difference is method preservation: a 302 lets the client change a POST into a GET, while a 307 guarantees the original method and body are preserved. For content pages use 302; for forms, APIs, or any non-GET request that must arrive intact at the new URL, use 307.
The Decision Rule
Strip away the folklore and 301 vs 302 redirects comes down to one question: should the original URL keep ranking, or should the destination take over for good? If the destination should own the ranking permanently, ship a 301 — and double-check it isn’t a mistake you’ll want to reverse, because browsers cache it hard. If the original URL is the real home and you’ll lift the detour later, ship a 302. Get that one judgment right, verify the actual header on the wire, keep every redirect to a single hop, and the plumbing will hold.
