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#
Try Elido
Paste a URL, get a working short link
No signup. Link lives for 30 days. Sign up to keep it forever.
Free, no signup required · 2 per day