301 vs 302 redirect: which code Google keeps, and when each one is right

The 301 vs 302 redirect choice is a choice about which address ends up in the index, not about where visitors land. Both send the browser to the same place. Only the permanent one tells Google that the new address should become the canonical one. Send a temporary code for a permanent move and the old address stays in search results, quietly, for as long as you leave it that way.

301 vs 302 redirect: what Google does with each code

Google's redirect documentation sorts every redirect method into two buckets and gives each bucket one sentence of behaviour. Permanent redirects "show the new redirect target in search results". Temporary ones "show the source page in search results". That is the whole difference, and it is a difference in the indexing pipeline, not in the browser.

The longer version from the same page: for a permanent redirect, "Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical". For a temporary one, "Googlebot follows the redirect, but the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical". Notice that Googlebot follows both. Nothing is blocked either way; only the canonical signal changes.

Two rows in that table surprise people. An instant meta refresh counts as permanent, and a delayed one counts as temporary, so the number of seconds you typed into a tag five years ago is deciding a canonical signal today. And 308 sits beside 301 rather than beside 307, even though 307 and 308 are the pair that preserve the request method.

Which code to send, by situation

The rule Google states is short: "Use permanent redirects when you're sure that the redirect won't be reverted." Everything below is that sentence applied to the moves a site actually makes.

Between 301 and 308 there is no search difference to report — Google's own table lists them on the same row. The difference is in HTTP itself: 308 keeps the request method, so a POST stays a POST, while a 301 lets clients turn it into a GET. For an ordinary content page you will not notice. For a form endpoint or an API path you will.

The one to avoid is a JavaScript redirect. Google's guidance is to "only use JavaScript redirects if you can't do server-side or meta refresh redirects", because "rendering may fail for various reasons". A server-side code is decided before a single byte of your page is parsed; a JavaScript one depends on the render succeeding.

How to check what your redirect really returns

What a redirect returns and what the config file says are two facts, and only one of them is checkable. Three commands, in this order.

1. Read the first hop on its own. curl -sI http://yourdomain/ prints the status line and Location without following anything, so you see the code your own origin chose rather than the code at the end of the chain.
2. Then walk the whole chain. curl -sIL http://yourdomain/ | grep -iE '^HTTP/|^location:' lists every hop in order. More than two hops on a homepage is worth a look; every hop is a request a crawler pays for.
3. Spot-check ten real URLs, not the homepage. Old article addresses, an old category path, a URL with a trailing slash and the same one without. The homepage redirect is usually the one that got tested; the rest usually were not.

A short paste-ready version of step two, so the shape of the output is fixed and comparable across sites:

for u in / /blog /blog/ /old-post-slug; do
  printf '%s  ' "$u"
  curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}\n' "https://yourdomain$u"
done

Read the column of status codes first. Any 302 in that column belongs to a page you can name a reason for, and if you cannot name the reason within a few seconds, it is a 301 that somebody typed wrong.

A redirect code is a promise about the future, and 302 is the promise that you will change your mind.

The three ways this goes wrong

Each of these has a symptom you can see before you touch anything.

The last row is worth a sentence on its own, because it is the only one that hides from the tool most people reach for. A browser follows a JavaScript redirect happily, so the page looks fine to whoever is testing it, while curl and anything else reading the raw response sees a 200 and a page of markup. That gap is the point of checking with a request rather than with your eyes.

The middle one is the quiet one. Redirect rules accumulate because nobody deletes the old rule when adding a new one, and each layer is individually correct: http to https, then non-www to www, then old path to new path. Three correct rules and a crawler makes four requests to read one page. The hop counts measured across a real panel are in HSTS and http to https redirects on 27 homepages, and the collateral damage a URL change causes beyond the redirect itself is in does changing a URL affect SEO.

Where this stops applying

Three boundaries, and the first one catches most people.

1. A redirect cannot fix a page that was never indexed. If the source address never ranked for anything, changing 302 to 301 moves a signal that was worth nothing. Check the old address in Search Console before you spend an afternoon on this.
2. Google does not publish how long it takes for a permanent redirect to be reflected, and neither will this page. What is documented is the direction of the signal, not its speed, so do not treat an unchanged result after two weeks as proof that the code is wrong.
3. Redirects are not the right tool for content you want removed. That is a different decision with different codes, and sending a removed page to the homepage is the most common way to get it treated as a soft error instead.

One more limit worth stating plainly: none of this is a ranking technique. Getting the code right stops you from losing an address you already earned. It does not add anything. What a crawler and an answer engine can do with the page once they arrive is what QueryWin works on.

Common questions

Is a 301 redirect better than a 302 for SEO?

Better for a permanent move, wrong for a temporary one. Google's documentation ties the choice to canonicalization: a permanent code makes the target canonical, a temporary code keeps the source in results. Neither is stronger in the abstract.

Does a 302 redirect pass link value?

Google's documentation does not describe redirects in terms of passing value; it describes which address becomes canonical. A temporary redirect keeps the source page as the indexed address, so the address you kept is the one that carries whatever it had.

What is the difference between 301 and 308?

For search, nothing that Google documents — they appear on the same row of the same table. In HTTP, a 308 preserves the request method and a 301 permits clients to change POST to GET.

How long should I keep a redirect in place?

Longer than you think, because the old address stays in other people's links forever. There is no documented expiry, so treat removal as a decision you make on purpose rather than a cleanup task.

Can I use a meta refresh instead?

Google treats an instant one as permanent and a delayed one as temporary, so it works, and it also means a stray delay value silently changes the meaning. A server-side code cannot be edited by accident from a content editor.