There are more kinds of URL redirect than the 301-versus-302 debate suggests, and picking the wrong one quietly costs you speed or ranking. They split into two families. Server-side HTTP redirects are status codes the server returns before the page loads - 301, 302, 303, 307, 308. Client-side redirects happen in the browser after the page loads - a meta refresh tag or a JavaScript hop. Server-side is faster and cleaner for users and crawlers alike; client-side is slower and weaker, and you only reach for it when the server is out of your hands.
I work on the redirect path, so I will keep this concrete: what each type does on the wire, how search engines read it, and which one to actually use. If you want the deep dive on the two you will use most, 301 vs 302 redirects covers that pair in detail; this post is the full map.
The short version up front: for a permanent move use a 301, for a temporary one use a 302, add method-preserving 308/307 when a POST must survive, and avoid the client-side options unless you have no server to configure.
The Two Families of Redirects
A redirect is just an instruction to go somewhere else, but where that instruction lives changes everything about how it behaves.
A server-side redirect is the server answering "not here, go there" before any page content is sent. The browser gets a status code and a Location header and moves immediately - no content loads at the original URL, so it is fast and unambiguous. A client-side redirect is the opposite: the original page loads fully, and only then does a meta tag or a script send the visitor onward. That means a wasted page load, a visible flicker, and a weaker signal to search engines, which have to load and sometimes execute the page to even notice the redirect. The formal definitions of the server-side codes live in RFC 9110, and the practical browser behavior is documented in the MDN guide to HTTP redirections.
That single distinction - before the page or after it - is why the rest of this post keeps coming back to "use a server-side redirect when you can."
The HTTP Status-Code Redirects
These are the real redirects, returned by the server in the 3xx range. Five matter.
| Code | Meaning | Permanent? | Method preserved? | Typical use |
|---|---|---|---|---|
| 301 | Moved Permanently | Yes | Not guaranteed | A final move, site migration, HTTPS switch |
| 302 | Found | No | Not guaranteed | A temporary move, editable links, A/B tests |
| 303 | See Other | No | Forces a GET | Post-form redirect to a result page |
| 307 | Temporary Redirect | No | Yes | Temporary move on a POST or API endpoint |
| 308 | Permanent Redirect | Yes | Yes | Permanent move where the method must survive |
The two axes that organize the table are permanence and method handling. Permanence is the SEO axis: a 301 and 308 are permanent, so search engines pass ranking signals and treat the target as canonical, while 302, 303, and 307 are temporary and keep the original URL indexed. Method handling is the engineering axis: 307 and 308 strictly preserve the HTTP method, so a POST stays a POST, whereas 301 and 302 historically allowed it to drift to a GET. The 303 is the odd one, built specifically to force a GET after a form submission so a refresh does not resubmit the data. Google's own redirects documentation confirms it treats the permanent codes as canonicalization signals.
For everyday web links, which are GET requests, the method axis disappears and you are really choosing between permanent and temporary - which is exactly the 301 vs 302 decision.
Client-Side Redirects: Meta Refresh and JavaScript
When you cannot configure the server, two browser-level options remain, and both are compromises.
A meta refresh is an HTML tag in the page head that tells the browser to load a new URL after a delay - the "you will be redirected in 5 seconds" pattern. It works, but the page has already loaded before it fires, so it is slow, and search engines read it inconsistently: an instant meta refresh is usually treated as a permanent redirect, while a delayed one is ambiguous and can be read as a soft 404. A JavaScript redirect is weaker still, because it only happens if the crawler executes the script. Google renders JavaScript, but on a delay, and many other crawlers do not run it at all, so the redirect can be missed entirely.
The honest ranking of options is simple: a server-side 3xx first, a meta refresh only if you control the HTML but not the server, and a JavaScript redirect as the last resort when you control nothing else. None of this applies to a managed short link, which always uses a server-side redirect - the client-side techniques are for situations like a static host with no redirect config.
Which Redirect Should You Use
Strip it to a decision you can make in one pass.
- Permanent move, ordinary link:
301. Full ranking transfer, treated as canonical. - Temporary move, ordinary link:
302. Keeps the original indexed and the link editable. - The move involves a POST or API call: use
308for permanent or307for temporary, so the method survives. - After a form submission:
303, so a page refresh does not resubmit the form.
The meta-rule behind all four: match the status code to the truth about the move - is it permanent, and does the method matter. Getting that pairing wrong is how redirects quietly leak ranking or break a form.
What Short Links Use
A managed short link is a server-side redirect, and for good reason - it is the fast, crawler-friendly family. The interesting choice is which code, and the answer for most short links is a 302.
That sounds wrong for SEO until you remember what a short link is for. A 302 keeps the link editable, so you can repoint it after it is printed or shared, and it keeps every click reaching the server, so your analytics stay accurate - both things a hard-cached 301 would cost you. The full reasoning, including the browser-caching trap, is in 301 vs 302 redirects, and the mechanics of how the redirect resolves at the edge are in how URL shorteners work. The one rule that applies regardless of code: keep it to a single hop. A redirect that points at another redirect wastes crawl budget and latency, and it is the fastest way to undo the SEO that short links otherwise preserve.
The whole map fits in a sentence: server-side codes for real redirects, permanent versus temporary for SEO, method-preserving variants for non-GET requests, and client-side tricks only when the server is off-limits. Pick by the truth of the move, keep the chain to one hop, and your redirects do what you meant.
Related on the Blog
- 301 vs 302 redirects: which one should short links use
- Do URL shorteners hurt SEO? The honest answer
- How URL shorteners work under the hood
- Hitting p95 under 15ms for redirects from FRA, ASH, and SGP
- Cache strategy for URL redirects: L1 LRU + L2 Redis
- Open redirect vulnerabilities and how to prevent them
Sıkça sorulan sorular
What are the main types of URL redirects?
There are two families. Server-side HTTP redirects are status codes the server returns: 301 (permanent), 302 (temporary), 303 (see other, forces a GET), 307 (temporary, method-preserving), and 308 (permanent, method-preserving). Client-side redirects happen in the browser after the page loads: a meta refresh HTML tag or a JavaScript location change. Server-side redirects are faster and cleaner for both users and search engines; client-side ones are slower and weaker, and you reach for them only when you cannot control the server.
What is the difference between a 301 and a 308 redirect?
Both are permanent, so both tell search engines the destination is the new canonical URL and pass ranking signals. The difference is HTTP method handling: a 301 historically allowed the method to change (a POST could become a GET on the redirect), while a 308 strictly preserves the method and body. For ordinary links, which are GET requests, they behave the same. The 308 matters for APIs and form submissions where a POST must stay a POST.
What is a 307 redirect used for?
A 307 is the strict temporary redirect. It does the same job as a 302 - send the visitor elsewhere for now, keep the original URL indexed - but it guarantees the request method is preserved, so a POST stays a POST. Use it for temporary moves on endpoints that receive non-GET requests, like an API or a form handler. For a normal temporary link redirect, a 302 and a 307 are interchangeable.
Is a meta refresh redirect bad for SEO?
It is weaker than a server-side redirect and worth avoiding when you have a choice. A meta refresh fires in the browser after the HTML loads, which is slower for the user and a less reliable signal for search engines. Google says it interprets an instant meta refresh as a permanent redirect, but a delayed one is murky and can be treated as a soft 404 or worse. If you can return a 301 or 302 from the server, do that instead.
Do JavaScript redirects work for SEO?
They can, but they are the least reliable option. A JavaScript redirect only fires if the crawler executes the script, and while Google does render JavaScript, it does so on a delay and other crawlers often do not. So the redirect may be missed or counted late. Use a JavaScript redirect only when you control nothing on the server and cannot use a meta refresh either - it is the last resort, not a default.
Which redirect type should I use?
Match the code to the truth. For a permanent move, use a 301 (or 308 if a POST must survive). For a temporary move, use a 302 (or 307 for non-GET methods). For most short links, which are editable GET redirects, a 302 is the right default because it keeps the link changeable and the analytics accurate. Reserve client-side meta refresh and JavaScript redirects for cases where you cannot control the server at all.
Elido'yu deneyin
Bir URL yapıştırın, çalışan bir kısa bağlantı alın
Kayıt gerekmez. Bağlantı 30 gün boyunca yaşar. Sonsuza kadar saklamak için kaydolun.
Ücretsiz, kayıt gerekmez · Günde 2