301 vs 302 redirects: what is the difference?

Every time you change the address of a page (because you reorganise the menu, switch platforms or fix a name), the old URL lives on somewhere: in Google, in links from other sites, in your customers’ bookmarks, in a PDF doing the rounds by email. A redirect is the instruction that tells the browser and the search engine “this lives over there now”.

It looks like a minor technical detail, and it is, until it is done badly. Then it turns into traffic that vanishes after a redesign without anyone being able to explain why.

How a redirect works

When someone requests a URL, the server answers with an HTTP status code, a three-digit number summing up what happened. Codes starting with 3 are redirects: the server does not deliver the page but a Location header with the new address, and the browser requests it automatically.

It all happens in milliseconds and the visitor rarely notices. The search engine does: it reads the code and, depending on which one it is, decides which URL to keep in its index.

What each code means

There are four redirect codes that matter for a website:

Code	Name	Meaning	Request method
301	Moved Permanently	It has moved for good	May change to GET
302	Found	It is somewhere else for now	May change to GET
307	Temporary Redirect	It is somewhere else for now	Preserved
308	Permanent Redirect	It has moved for good	Preserved

The method column only matters in specific cases, such as a form sending data with POST: with 301 or 302 some browsers repeat the request as GET and the data gets lost on the way, while with 307 or 308 it does not. For ordinary pages, which are requested with GET, 301 and 308 are equivalent, and so are 302 and 307.

The difference that really counts is the other one: permanent or temporary.

Permanent versus temporary, as Google sees it

With a permanent redirect (301 or 308), you are telling Google the new URL replaces the old one. Google carries the accumulated signal over to the new one (links, history, relevance) and, in time, stops showing the old one in results.

With a temporary redirect (302 or 307), you are telling it the old URL is still the right one and the detour will pass. Google tends to keep the original URL in the index, because it expects it to come back.

Hence the practical rule:

• Use 301 (or 308) when the change is final: a new domain, a new URL structure, moving from http to https, merging two pages into one, a discontinued product with a clear replacement.
• Use 302 (or 307) only when you genuinely intend to undo it: a page under maintenance, a seasonal promotion taking over the home page for a few weeks, an A/B test.

The most common mistake is the reverse: a 302 put in “for now” during a migration and never revisited. Google may eventually treat a long-lived 302 as permanent, but it takes considerably longer, and meanwhile the signal does not settle where it should.

There is a caveat in the other direction: browsers cache 301s very persistently. If you get the destination of a permanent redirect wrong, anyone who has already followed it may keep landing in the wrong place even after you fix the rule. It is worth testing them before publishing.

Chains and loops

A chain is a redirect that leads to another redirect. It happens mostly when migrations pile up: one moved /services.html to /services, another moved /services to /services/, and the latest moved /services/ to /what-we-do/. Anyone arriving with the oldest address makes three hops.

Each hop is one more round trip to the server, which the visitor pays for in loading time, especially on mobile. Google follows up to 10 hops and then gives up; below that it follows them, but takes longer to process them, and the odds of something breaking along the way go up.

A loop is a chain that comes back on itself: A leads to B and B leads to A. The browser stops it with an error (“too many redirects”) and the page is unreachable for everyone. It usually appears when two rules clash, for example a server rule adding the trailing slash and a CMS rule removing it.

The fix in both cases is the same: every old URL should point straight at its final destination, in a single hop. When you add a new rule, check whether any earlier rule pointed at the URL that now redirects, and update it.

Hops nobody thinks of as redirects count too: http to https, www to non-www, and the URL without a trailing slash to the one with it. Ideally they are all resolved in a single rule that goes straight to the canonical version.

Why not redirect everything to the home page?

It is the temptation of every rushed migration: hundreds of old URLs with no obvious equivalent, and one rule that sends them all to the home page. It seems that way nobody sees an error.

Google reads it differently. If someone was looking for a page about a specific product and lands on the home page, the redirect does not answer what they asked for. Google treats it as a soft 404, an error in disguise: no signal is passed on and the old URL may keep showing. For the visitor it is even worse, because they arrive somewhere that does not explain where the thing they wanted went.

The right approach is to redirect each page to its closest equivalent: a discontinued product to its replacement or its category, an old article to the one covering the same topic. And if there really is nothing equivalent, it is more honest to respond 410 (gone for good) or a 404 with a helpful error page.

Deciding what happens to each URL sits at the heart of any migration that keeps its rankings.

How long to keep a redirect

Longer than you might think. Google recommends keeping them for at least a year, which is how long it takes to consolidate the signal on the new URL. But the old URL lives on in links from other sites, in old emails and in printed material, so in practice the prudent course is never to remove them as long as they are not in the way.

A redirect rule takes one line. Losing the links that pointed at that address costs a great deal more.

It also helps if your sitemap lists only final URLs: an address that redirects should not appear in it.

Checking yours

The redirect checker follows the full chain of one or more URLs (up to twenty per batch) and shows each hop with its code, all the way to the final page. It flags what this article describes: temporary hops where there should be permanent ones, chains of more than one hop, loops, stray www or trailing-slash hops, and deep URLs that end up on the home page. It also shows the headers of the final response, such as caching or a noindex sent as a header.

It is especially useful right after a migration: paste a sample of the most visited old URLs and check that each one reaches its place in a single hop. If you do not have that list yet, the old URLs finder helps you rebuild it.

---

A good redirect is invisible: a single hop, permanent if the change is, and towards the page the person expected to find. Anything that strays from that ends up costing visits, even if it takes a few weeks to show.