301 vs 302 Redirect: Two Differences Decide It, and Four Follow

Does that old address have a future? Answer that and you have chosen. See both answers, and what each wrong one costs you.

Mason ReidStartup Growth ConsultantSeptember 16, 2026 · 7 min read

/ On this page7 sections

Does that old address have a future? No future means a 301, a future means a 302.

Six things separate the two codes, and four of them follow from that one answer.

Which leaves the one case that stalls people, when the honest answer is that you cannot say yet.

The Two Differences That Decide It

Everything turns on what you are claiming about the old address, and on which of the two addresses you want search to put in front of people. Those are the same decision seen from two sides.

A 301 claims that address is done.

Search is being asked to treat the new one as its replacement, not as a stand-in.

A 302 claims it is standing by.

Something else is taking the traffic for a while, and the original keeps its place.

So the choice is a prediction about one URL, and making the prediction decides the code for you.

And yes, a 301 is a permanent redirect in the ordinary sense of the word. You are asserting that nothing will ever live at that address again.

The Four That Follow

The remaining four are worth knowing and none of them is worth deliberating over, because each follows from the answer you already gave.

What differs	301	302
What you are claiming	That address is done	That address is standing by
Which URL search puts in results	The new one	The old one
What search counts the redirect as	A signal for the destination	Not a signal for it
What a browser may remember	The redirect, on an expiry it picks	Nothing, unless you say otherwise
How hard it is to reverse	Hard, and not fully in your hands	Easy
What happens to your internal links	Repoint them at the destination	Leave them where they are

The top two rows are one answer asked two ways. The four beneath them are the bill that arrives with it.

A two tier ledger of the six differences between a 301 and a 302. At the top, in an orange panel, sits the one question the whole thing reads off: does that old address have a future, with the note that no future means a 301 and a future means a 302. An arrow leads down to a block headed the two you answer, holding the only two rows that are a decision: what you are claiming, which is that the address is done for a 301 and standing by for a 302, and which URL search puts in results, which is the new one for a 301 and the old one for a 302. A second arrow leads down to a quieter block headed the four that follow, holding the rest: what search counts the redirect as, a signal for the destination or not a signal for it; what a browser may remember, the redirect on an expiry it picks or nothing unless you say otherwise; how hard it is to reverse, hard and not fully in your hands or easy; and what happens to your internal links, repoint them at the destination or leave them where they are. A closing line says the top pair is the decision and the four beneath it are the bill that arrives with it. — Neeraj Jivnani · The split between the two differences that decide and the four that follow is ours. The search results row restates Google Search Central's redirect documentation; the browser row restates the HTTP specification, RFC 9110.

What Moves, and What Does Not

What moves between the two addresses does not decide this. What search shows does.

Take the reading most generous to the temporary code, and suppose nothing at all is lost in transit.

A 302 on a move that is finished still leaves you stuck, because search is deliberately holding the old address as the real one.

Nothing has been destroyed. It is sitting on a URL you no longer want anybody to land on, which is the same outcome as losing it and harder to notice.

The half that does decide something is where search points people, and Google publishes that plainly in its redirect documentation: a permanent redirect puts the destination into search results, and a temporary one leaves the source page there. Only the permanent kind counts toward deciding which of the two addresses is canonical, the one search files as real.

So no, a 302 is not bad. It is wrong for a move that is finished, which is a fact about your situation rather than a property of the number.

What Each Wrong Answer Costs

Both wrong answers are recoverable on paper. In practice only one of them is, and the gap between them is the reason this choice is worth making deliberately.

One costs you time you can count. The other costs you something you cannot reach.

You Said Temporary and the Move Was Finished

Search keeps the old URL in its results, the new one never takes over, and the move you announced everywhere else does not land. Nothing breaks. It stalls, quietly, with no error anywhere to tell you.

Correct the code on the old address and search reprocesses the pair the next time it crawls it.

You lose the weeks the wrong number was live, and nothing else.

While you are in there, edit the rule you already have instead of adding a second one in front of it.

You Said Permanent and the Move Was Not

The search half unwinds the same way. Take the redirect off, search reprocesses, the old address recovers.

Slow, and entirely inside your control.

The browser half is not inside your control.

The HTTP specification lets a client store a permanent redirect and pick its own expiry, and grants no such permission for a temporary one. That is RFC 9110, the 2022 edition of it.

You never see that decision, so you cannot withdraw it.

A visitor who met the old address while your permanent redirect was live may keep being sent away for weeks after you delete the rule. Their browser is obeying something you told it and can no longer untell.

That asymmetry is the argument for being slower about permanent than about temporary. Guessing temporary is a scheduling problem. Guessing permanent is a problem in somebody else's software.

A diagram split by a dashed orange boundary reading the edge of what you can reach. Above the line, inside your reach, two cards sit side by side. The first, you said temporary and the move was finished, notes that search keeps the old URL in its results and the new one never takes over, that nothing breaks and it stalls quietly with no error, and that the repair is to correct the code on the old address so search reprocesses the pair the next time it crawls it, costing only the weeks the wrong number was live. The second, you said permanent and the move was not, the search half, notes that a permanent redirect puts the destination into search results and that taking the redirect off lets search reprocess and the old address recover, slow and entirely inside your control. Below the line, alone in an orange panel, sits the browser half: the HTTP specification lets a client store a permanent redirect and pick its own expiry and grants no such permission for a temporary one, so a visitor may keep being sent away for weeks after you delete the rule. Two closing lines read: guessing temporary is a scheduling problem, guessing permanent is a problem in somebody else's software. — Neeraj Jivnani · The asymmetry and the reading are ours. The permission a client has to store a permanent redirect, and the absence of it for a temporary one, is from the HTTP specification, RFC 9110.

When You Cannot Answer It Yet

When you cannot answer the question yet, that is a real state and not a failure to think hard enough.

It is also the one that stalls people, because both codes feel like a commitment.

Only one of them is. A 302 comes off your own server on your own afternoon and leaves nothing behind in anybody's browser.

So when the honest position is that you have not decided, say temporary and write down the date you will decide.

That date is the whole of the discipline.

A move you have not decided about is not the same thing as a move whose return nobody can date: the first is a decision pending, and the second is a finished move that nobody has relabeled yet.

The same distinction is what to read for in a redirect you inherited. It is somebody else's prediction about the future, and it is worth knowing which prediction it was before you overwrite it.

Which is why the advice to default to permanent when unsure has it backwards. Unsure means it might come back, and that is the definition of the other code.

The Three Cases That Look Undecided

Three situations are where this comes up, and only one of them is genuinely open.

A rebrand you are nervous about. Announcing it was the decision. Hedging does not keep your options open, it delays the new name taking over while you are already using it everywhere else.
A page you replaced but might restore. Might is the operative word. If restoring it is a live possibility and not a comfort, the old address has a future.
A domain you are trying before committing to it. This is the open one. Nothing has been announced, the trial has an end, and the code should say so.

The first is a decision you have already made and are avoiding writing down. The second is worth asking somebody about. Only the third is undecided, and it is the one that gets a date.

Where 307 and 308 Come In

307 and 308 are the same two answers again, for requests that carry a body.

Both a 301 and a 302 let a client drop what was being submitted and fetch the destination as a plain page instead.

The specification names 307 as the version that forbids it, and names 308 as the permanent code to reach for instead.

That turns two codes into a grid of four.

301 and 308 both say finished. 302 and 307 both say standing by.

The only difference inside a pair is whether the original request survives the hop, and Google treats both members of a pair the same way when it decides which address to show.

Which answers the practical version of the question. Use a 308 in place of a 301 when a form or an API call goes through the redirect, and a 307 in place of a 302 in the same situation.

One caution on the permanent side. RFC 9110 records 308 as "much younger" than its sibling codes and warns it "might not be recognized everywhere", which is a small risk and a real one.

Put your own case in and the code gets written rather than weighed.

Say what you are claiming about the old address

Permanent and temporary are claims about that address, so this asks for the claim and writes the code for you. Then it tells you what that claim costs if it turns out to be wrong, which is the part that is not the same in both directions.

What is true of the old address from here on

Answer that first. Both of the differences that decide anything are this one question asked twice, so nothing else can be worked out until it has an answer.

If you are auditing instead of choosing, ask the server for the old address and read the number it replies with before any page loads. A redirect you inherited is somebody’s prediction about the future, and it is worth knowing which prediction you are about to overwrite.

A two by two grid turning the two answers into four status codes. The rows are your answer: finished, meaning that address is done, and standing by, meaning that address keeps its place. The columns are what happens to the request: it may be dropped, so the client may fetch the destination as a plain page instead, or it must survive the hop, where dropping what was being submitted is forbidden. Finished and droppable gives 301, permanent, the permanent answer for an ordinary page request. Finished and kept gives 308, highlighted in orange, the one to reach for when a form or an API call is going through the redirect. Standing by and droppable gives 302, temporary, for an ordinary page request. Standing by and kept gives 307, temporary with the original request kept intact. Two notes beneath say that the only difference inside a pair is whether the original request survives the hop, that Google treats both members of a pair the same way when it decides which address to show, and that RFC 9110 records 308 as much younger than its sibling codes and warns it might not be recognized everywhere. — Neeraj Jivnani · The grid is ours. The permission to drop what was being submitted, the fact that 307 is the code that forbids it and 308 the permanent code to reach for instead, and the caution on 308, are all from the HTTP specification, RFC 9110; the pair treatment is from Google Search Central's redirect documentation.

The Call

Decide whether that old address has a future.

No future means 301. A future means 302. Not decided yet means 302 and a date, because deferring is a temporary state and temporary is the honest name for it.

The part worth carrying past the decision is that neither code is the strong option. You are describing a situation, and the only way to get this wrong is to describe it inaccurately.

/ The Two Differences That Decide It

/ The Four That Follow

/ What Moves, and What Does Not

/ What Each Wrong Answer Costs

/ You Said Temporary and the Move Was Finished

/ You Said Permanent and the Move Was Not

/ When You Cannot Answer It Yet

/ The Three Cases That Look Undecided

/ Where 307 and 308 Come In

/ The Call

/ More on SEO