What Is a 301 Redirect and When to Use It

A 301 redirect is a permanent redirect: it tells browsers and search engines that a URL has moved for good to a new address, automatically forwards visitors to the new page, and consolidates the old URL's ranking signals onto the new one. That last part is why 301s matter so much for SEO — done correctly, the destination inherits the equity the old page built up. The short rule is this: use a 301 for anything permanent, and a 302 (or 307) only when the move is genuinely temporary. This guide explains the difference between the redirect types, when to reach for each, the chains and loops to avoid, and how to implement and test redirects so they behave the way you intend.

Redirects are a core part of technical SEO, so this pairs naturally with what is technical SEO and how to audit it.

What a redirect actually is

When a browser or crawler requests a URL, the server replies with an HTTP status code. A normal, working page returns 200 OK. A redirect returns a 3xx code along with a Location header naming where to go instead, and the browser then requests that new URL. To the user it usually looks seamless — they typed or clicked one address and landed on another — but underneath, the status code is carrying important meaning about why the redirect happened and whether it is permanent.

That meaning is the whole point. A redirect is not just a convenience that moves people around; it is a signal to search engines about how to treat the old and new URLs. Choosing the right status code tells Google whether to update its index, which URL to keep, and where to send the ranking signals. Choosing the wrong one quietly works against you even though users notice nothing.

301 vs 302 vs 307 vs 308

There are four redirect codes you are likely to meet, and the differences come down to two questions: permanent or temporary, and does the request method change.

• 301 Moved Permanently. The URL has moved for good. Search engines should update their index to the new URL and pass ranking signals across. This is the standard SEO redirect for permanent moves.
• 302 Found (temporary). The move is temporary; the original URL will return. Search engines should keep the original URL indexed and not transfer signals to the destination. Use it for short-lived situations only.
• 307 Temporary Redirect. The strict, modern equivalent of a 302 that preserves the HTTP method (a POST stays a POST rather than potentially becoming a GET). Behaviourally for SEO it is treated like a temporary redirect.
• 308 Permanent Redirect. The strict, modern equivalent of a 301 that also preserves the request method. It signals a permanent move like a 301 does.

For the everyday job of moving a web page — where the request is a simple GET — the choice is almost always between 301 (permanent) and 302 (temporary), and 301 is the one you want for anything lasting. The 307/308 pair matter most when method preservation is important, such as redirecting form submissions or API endpoints; for ordinary content pages, a 301 remains the conventional, well-understood choice.

Here is the comparison at a glance:

Code	Meaning	Permanent?	Preserves method?	Typical use
301	Moved Permanently	Yes	Not guaranteed	Permanent page/site moves, HTTPS, consolidation
302	Found	No	Not guaranteed	Genuinely temporary moves (promo, maintenance)
307	Temporary Redirect	No	Yes	Temporary moves where method must be kept
308	Permanent Redirect	Yes	Yes	Permanent moves where method must be kept

When to use a 301: the scenarios

A 301 is the right tool whenever the old URL is not coming back. These are the situations that come up most often.

Scenario	Use this redirect
Moving to a new domain (rebrand, merger)	301 every old URL to its new-domain equivalent
Switching HTTP to HTTPS	301 all HTTP URLs to their HTTPS versions
Consolidating www and non-www	301 to your single chosen host
Changing URL structure (e.g. /p?id=9 to /shoes)	301 old URLs to the new clean URLs
Merging duplicate or thin pages	301 the weaker pages into the stronger one
Removing a page that has a close alternative	301 to the most relevant remaining page
Retiring an old blog post for a newer one	301 the old slug to the replacement
A genuinely temporary outage or promo page	302 (or 307) — not a 301

A few of these deserve emphasis. Site migrations are the highest-stakes use of 301s: mapping every old URL to its closest new equivalent, one-to-one wherever possible, is what carries your hard-won rankings across to the new site. Moving to HTTPS should always be a 301 from every HTTP URL, paired with consistent canonical tags so all your signals point the same way. And when you remove a page, redirecting it to a relevant alternative is far better for users and signals than letting it 404 — provided the alternative really is relevant.

The one case where a 301 is wrong

It is just as important to know when not to use a 301. If a move is genuinely temporary — a page is down for maintenance, you are running a two-week promotion, you are A/B testing two versions, or you are geo-routing visitors for a short campaign — a 301 is the wrong choice. A 301 tells Google "this is permanent; update your index and drop the old URL," which is precisely what you do not want when the original is coming back. In those cases use a 302 or 307 so engines keep the original URL indexed. Misusing a temporary redirect for a permanent move wastes signal; misusing a permanent redirect for a temporary one confuses your index. Match the code to reality.

Redirect chains and loops: what to avoid

Two failure patterns cause real damage, and both are common after years of accumulated changes.

A redirect chain is when a URL redirects to another that redirects again before reaching the final page: A to B to C. Chains hurt in three ways. They slow users down, since each hop is a round trip. They waste crawl budget, because a crawler must follow every step. And they can weaken the signals passed along the way. The fix is to flatten the chain so every old URL points directly to its final destination in one hop — update A to point straight at C. After any migration, audit for chains and collapse them.

A redirect loop is worse: A to B to A, an infinite cycle that never resolves. Browsers eventually give up with an error, and the page becomes unreachable for users and crawlers alike. Loops usually come from conflicting rules — for example, an HTTPS rule and a trailing-slash rule fighting each other. They must be fixed immediately because they take the affected URLs completely offline.

The healthiest pattern is always the simplest: one redirect, one hop, landing on a live 200 page. Anything more is a smell worth investigating.

How to implement a 301 redirect

Where you set up a redirect depends on your stack, but the principle is the same: configure the server or platform to return a 301 status with a Location header pointing at the destination.

• Apache uses the .htaccess file or virtual-host config, typically with Redirect 301 or RewriteRule directives.
• Nginx uses return 301 (or rewrite ... permanent) inside the server block.
• CDNs and edge platforms (Cloudflare, Vercel, Netlify and similar) offer redirect rules in their dashboards or config files, which is often the cleanest place to handle site-wide rules like HTTP-to-HTTPS.
• CMS platforms such as WordPress provide redirect plugins or built-in tools that write the rules for you, which is convenient for one-off page moves.
• Application frameworks can issue redirects in code, useful for dynamic logic.

Whichever you use, prefer server-side redirects over client-side hacks. A meta refresh tag or a JavaScript redirect can move a user, but they are slower and weaker signals than a true server-issued 301, and search engines handle them less cleanly. For permanent moves that need to pass ranking signals, a proper server-level 301 is the right tool.

A practical implementation tip for migrations: build a complete URL map (every old URL to its new equivalent) before you flip anything, redirect one-to-one rather than dumping everything on the homepage, keep redirects in place for a long time (months at least, often indefinitely) so engines and inbound links fully catch up, and update your internal links and sitemap to point at the new URLs directly rather than relying on the redirects forever.

How to test a redirect

Never assume a redirect works — verify it. There are two quick, reliable ways.

The command line with curl. Running curl -I https://example.com/old-page returns just the response headers, where you can read the status code and the Location. A correct permanent redirect shows HTTP/... 301 and a Location: header pointing to the destination. To follow the whole path and confirm there are no chains, curl -IL follows each hop and prints every status in sequence — you want to see a single 301 followed by a 200, not a string of 301s and 302s.

The browser's developer tools. Open the Network tab, enable "preserve log," and load the old URL. Each request appears with its status code, so you can see the 301 and the final 200, and spot any intermediate hops or loops. This is the easiest way to inspect a redirect visually and to confirm the user ends up on the right live page.

What you are checking for in both cases is the same: the right status code (301 for permanent), a single hop to the correct destination, and a 200 OK at the end. If you see a 302 where you expected a 301, a chain of multiple redirects, or a 404 at the destination, you have a problem to fix. At scale, an SEO crawler or a broad site audit — StackOptic included — will flag redirect chains, loops, and redirects landing on errors across the whole site so you do not have to test URLs one by one.

Common redirect mistakes

• Using a 302 for a permanent move, which keeps the old URL indexed and withholds signal from the destination.
• Redirect chains left behind by years of changes, slowing users and wasting crawl budget.
• Redirect loops that take pages completely offline.
• Redirecting everything to the homepage instead of to relevant equivalents, which Google may treat as soft 404s rather than genuine moves.
• Redirecting to irrelevant pages, which frustrates users and undercuts the relevance the destination needs.
• Relying on meta-refresh or JavaScript redirects for permanent moves instead of a true server 301.
• Removing redirects too soon after a migration, before engines and inbound links have caught up.

Where to start

If you have inherited a site with a tangle of redirects, start by crawling it and listing every redirect with its status code and final destination. Fix the dangerous patterns first: collapse any chains into single hops, break any loops, and re-point redirects that land on 404s or on the homepage so they reach a relevant live page. Then confirm your permanent moves use 301, not 302, and that HTTP-to-HTTPS and host consolidation are handled site-wide. Finally, update internal links and your sitemap to reference the destination URLs directly. That sequence — inventory, fix chains and loops, correct the status codes, then update internal references — resolves the overwhelming majority of redirect problems and keeps your signals flowing to the right pages.

Go deeper

• The wider picture: what is technical SEO and how to audit it.
• Fix what redirects can leave behind: how to fix crawl errors in Google Search Console.
• Keep your preferred URLs clear: what are canonical tags and how to use them.
• Point engines at the new URLs: how to create an XML sitemap and submit it.

Want redirect chains, loops and broken destinations flagged automatically? Analyse any URL with StackOptic — one report covering technical SEO, performance and more, free, no sign-up.