Most people treat the types of redirects as a trivia question — memorize that 301 is permanent, 302 is temporary, and move on. That framing is why so many migrations quietly bleed rankings. A redirect isn’t a label; it’s an instruction to two audiences at once — a browser rendering the right page for a human, and a crawler deciding whether to move a URL’s accumulated authority, keep the old one indexed, or wait. Pick the wrong code and it’s not a cosmetic mistake. You’re telling Google to do the opposite of what you intended, and it will comply.
This guide skips the status-code glossary and gives you what actually matters: a decision rule that picks the right redirect in about ten seconds, the mechanisms behind why each code behaves the way it does, and a worked migration example where the choice changes the outcome. By the end you’ll understand not just which of the types of redirects to reach for, but why the wrong one costs you.
The Three Questions That Pick the Right Redirect
Before you look up a single status code, answer three questions in order. They collapse the entire decision tree down to one branch.
- Is this move permanent? Will the old URL ever serve its own content again? If no, you want a permanent redirect and you want authority to transfer. If the change is temporary — a maintenance page, a limited campaign, geo-testing — you want the old URL kept in the index.
- Does the request method need to survive? Almost all page redirects are GET requests, so this rarely bites you. But if a redirect can fire on a form submission (a POST), the wrong code silently converts it to a GET or drops the payload.
- Can the server issue it, or are you stuck client-side? Server-issued 3xx redirects are the gold standard. Meta-refresh and JavaScript redirects exist for when you genuinely can’t touch server config — not as a default.
Answer those three and the correct redirect is nearly always obvious. The rest of this article explains why each answer maps to a specific code, so you trust the rule instead of memorizing it.
301 vs 308: The Permanent Pair
A 301 Moved Permanently is the workhorse of SEO. It tells crawlers the old URL is gone for good and that the destination should inherit the ranking signals — links, authority, relevance — the old page earned. Google has confirmed that permanent redirects pass PageRank without a systematic “decay tax,” so a clean 301 is close to a lossless transfer of equity. This is the code for a domain move, an HTTP-to-HTTPS switch, a consolidated pair of duplicate pages, or a retired URL that has a genuine successor.
The lesser-known twin is 308 Permanent Redirect. It means the same thing to search engines but adds one guarantee: the browser must preserve the original request method. A POST stays a POST; a GET stays a GET. For a plain content page that’s irrelevant, and a 301 is the safe, universally understood default. Reach for a 308 only when a permanent redirect might catch a non-GET request — an API endpoint that moved, or a form action URL — and you cannot afford the method to silently change. For the pages redirect guides are actually about, 301 is the answer.
302 vs 307: The Temporary Pair
A 302 Found says “the real content lives here for now, but keep indexing the original URL.” Use it when the move is genuinely short-lived: a product page swapped for a “back in stock soon” notice, A/B testing, a country-splash page, or a maintenance window. Because Google keeps the original in the index, you don’t want a 302 for a permanent move — leave one in place for months and Google may eventually treat it as a de facto 301 and transfer signals anyway, but you’ve spent that whole window in ambiguity you didn’t need.
307 Temporary Redirect is to 302 what 308 is to 301: same temporary meaning, but it strictly preserves the request method. There’s a second, quieter reason 307 appears in your logs — HSTS. When a site enforces HTTPS via HTTP Strict Transport Security, the browser issues an internal 307 to upgrade HTTP to HTTPS before a request ever leaves the machine. That’s not something you configured page by page; it’s the security layer doing its job. For deliberate temporary moves of ordinary pages, 302 remains the conventional choice.
303 See Other: The One Almost Nobody Configures on Purpose
The last of the common redirect status codes, 303 See Other, solves a specific problem: what happens after a user submits a form? You don’t want a page refresh to re-submit the payment or the comment. A 303 tells the browser to fetch the result page with a fresh GET, deliberately dropping the POST. This is the Post/Redirect/Get pattern, and frameworks handle it for you. You’ll rarely hand-write a 303 for SEO reasons — but knowing it exists explains behavior you’d otherwise find baffling in server logs, and stops you from “fixing” a redirect that’s working as intended.
Client-Side Redirects: Meta Refresh and JavaScript
Everything above is server-side: the server returns a 3xx status and a destination before any page renders. The other family among the types of redirects runs in the browser after a page loads.
- Meta refresh — a
<meta http-equiv="refresh">tag that sends the user elsewhere after a delay. Google can follow an instant (zero-second) meta refresh and may treat it like a permanent redirect, but it’s slower, flashes the intermediate page, and passes signals less reliably. A timed one (the classic “redirecting in 5 seconds”) is worse and should be avoided for anything you care about ranking. - JavaScript redirects —
window.locationchanges the URL after the script runs. Modern Googlebot renders JavaScript, so it can follow these, but only after the render queue gets to the page — which can lag crawling by days. Signals transfer inconsistently, and any crawler or user with JS disabled never arrives.
The rule is blunt: use client-side redirects only when you physically cannot issue a server redirect — a static host with no server config, a CMS that locks you out of the response layer. In every other case, a server-side 3xx is faster, cleaner, and clearer to crawlers. Client-side redirects are a fallback, never a strategy.
A Worked Example: Consolidating Two Blog Categories
Rules are easy to nod along to and hard to apply, so here’s a concrete case. Say you’re merging two overlapping blog categories — /blog/link-building/ and /blog/backlinks/ — into one canonical hub at /blog/backlinks/, because they’ve been cannibalizing each other for years.
Run the three questions. Permanent? Yes — /link-building/ is never coming back. Method preservation? No — these are GET requests to content pages. Server-side possible? Yes. That answers it: a 301 from every /link-building/ URL to its closest match under /backlinks/. Not a blanket redirect of the whole category to one landing page — Google reads mass redirects to a single URL as soft-404 signals. Each retired post maps to its most relevant survivor, one to one.
Then the part people forget: update the internal links. Every internal link still pointing at a /link-building/ URL now fires a redirect on every crawl, and internal links pointing at redirects are pure waste — crawl budget spent and signal diluted to reach a page you could link to directly. Fix the source links, keep the 301s permanently as a safety net for external links you don’t control, and the consolidation transfers cleanly. Skip the cleanup and the merge “works” while quietly underperforming for months.
Redirect Chains, Loops, and Hops
The most common way a correct redirect goes wrong is stacking. A redirect chain is A → B → C → D. Each hop adds latency, and while Google will follow a handful, every extra one risks lost signal and crawl efficiency. Chains accumulate innocently: you move a page, rebrand, then switch to HTTPS, and now one old URL wanders through four redirects before landing. The fix is to flatten — point A directly at the final destination D, so every legacy URL is one hop from home.
A redirect loop is the pathological version: A → B → A. The browser gives up and throws “too many redirects,” and the page is inaccessible to users and crawlers alike. Loops usually come from conflicting rules — an HTTPS rule and a trailing-slash rule fighting, or a plugin redirect colliding with a server-level one. When you see that error, look for two systems issuing redirects on the same URL pattern.
Redirect Hygiene That Actually Costs Rankings
Choosing the right code is half the job. The other half is keeping the redirect map clean over time, where large sites quietly rot. The failures that cost real traffic:
- Removing old 301s too early. A permanent redirect isn’t a one-time event — it has to stay in place as long as external links or old bookmarks point at the source. Delete it after “the migration is done” and you 404 every link you worked to preserve.
- Redirecting to irrelevant destinations. A 301 to an unrelated page reads as a soft 404 and transfers almost nothing. Relevance between source and target is what makes the signal move.
- Chains from repeated migrations. Audit periodically and flatten multi-hop paths to single hops.
- Internal links pointing at redirects. The cheapest win in most audits: repoint them straight at final URLs.
At any real scale you can’t eyeball this. You need a crawler that flags redirect chains, loops, mixed HTTP/HTTPS hops, and internal links resolving through a 3xx. That’s the deterministic layer SEO Rocket’s site audit runs — a real crawler, not a checkbox estimate — surfacing the redirect problems that leak equity before they show up as a slow ranking decline. Pair it with rank tracking and you watch a migration’s recovery curve instead of guessing whether the 301s took.
Honest Caveats: What Redirects Can’t Fix
A redirect moves signals; it doesn’t create them. If the destination is weaker than the source — thinner, less relevant, worse than the current page-one results — a flawless 301 just hands authority to a page that can’t hold the ranking. Migrations that “lose traffic despite perfect redirects” are usually ones where the new pages are genuinely worse, or where intent shifted and nobody re-checked what the query now wants.
Recovery also isn’t instant. Even with clean permanent redirects, Google has to recrawl the old URLs, process the moves, and re-evaluate the destinations — typically several weeks, longer on large or slowly-crawled sites. Expect a dip-then-recover shape, not a seamless handoff. The redirect is necessary infrastructure, but durable ranking still comes from the page being the best answer. That’s the order of operations behind the playbook proven across 1,000,000+ ranking pages: make the destination genuinely deserving first, then let the redirects carry equity to it. SEO Rocket’s competitor gap analysis and AI keyword research help ensure the page you redirect to actually earns the traffic it inherits.
Frequently Asked Questions
Does a 301 redirect pass all the link equity?
Close to all of it. Google has stated that permanent redirects don’t lose PageRank the way an old “15% decay” myth suggested. In practice the transfer is near-lossless when the destination is relevant to the source — but relevance is the condition. A 301 to an unrelated page behaves like a soft 404 and transfers little.
How long should I keep a redirect in place?
A permanent redirect should stay indefinitely — as long as anything external could still link to or request the old URL, which is effectively forever. Temporary redirects (302/307) should be removed once the temporary situation ends. The rule of thumb: you retire a redirect only when you’re certain nothing still points at the source.
Is a 302 bad for SEO?
Not when it’s used correctly for a genuinely temporary move — that’s what it’s for. It’s only a problem when it’s used for a permanent change, because it tells Google to keep the old URL indexed and delays the signal transfer you actually want. Match the code to the intent and a 302 is exactly right.
Which redirect should I use for HTTP to HTTPS?
A site-wide 301 from each HTTP URL to its HTTPS equivalent, ideally reinforced by HSTS so browsers upgrade internally (that’s the 307 you’ll see in dev tools). The move is permanent and equity should transfer, so 301 is the correct base code.
