301 vs 302 Redirects: What Link Shorteners Actually Do

Every shortened link is, mechanically, a redirect — a tiny HTTP response that tells a browser "the thing you want is over there." But not all redirects are the same. The difference between a 301 and a 302 status code looks like trivia until it decides whether your link passes SEO value, whether a browser re-checks the destination on the next click, and whether your click counts stay accurate.

This post explains what those codes actually mean, why link shorteners choose one over the other in different situations, and what happens under the hood when we redirect a click. No prior HTTP knowledge required, but we won't dumb it down either.

Redirects are just HTTP responses

When a browser requests a URL, the server answers with a status code. You know some of them already: 200 means "here's the page," 404 means "nothing here." The 3xx family means "what you want is at a different URL," and the response includes a Location header telling the browser where to go. The browser then automatically requests that new URL — usually in a few milliseconds, invisibly.

The relevant members of the family:

Code	Name	Meaning	Browser caching
301	Moved Permanently	The resource lives at the new URL from now on	Cached aggressively, often indefinitely
302	Found	The resource is temporarily elsewhere	Not cached by default
307	Temporary Redirect	Like 302, but the request method must not change	Not cached by default
308	Permanent Redirect	Like 301, but the request method must not change	Cached like a 301

The 307/308 variants exist because of a historical ambiguity: some old clients would turn a POST request into a GET when following a 301 or 302. For link shortening this rarely matters — clicks are GET requests — so the meaningful choice is between "permanent" (301/308) and "temporary" (302/307).

What "permanent" versus "temporary" actually changes

The words describe intent, but two systems act on that intent: search engines and caches.

Search engines and link equity

When a search engine crawler encounters a 301, it concludes the old URL is obsolete: it transfers indexing signals — the accumulated value of links pointing at the old URL, often called link equity or PageRank — to the destination, and eventually drops the old URL from its index. Google has stated for years that 301s pass essentially full PageRank; the old belief that redirects "leak" some fixed percentage of equity is outdated.

A 302 tells the crawler the move is temporary, so it keeps the original URL indexed and is slower to consolidate signals onto the destination. In practice, search engines treat long-lived 302s as de facto 301s eventually, but you should not rely on a crawler inferring your intent when you can just state it correctly.

For a shortened link, the practical upshot: if someone links to your short URL from their site, a 301 ensures that link's SEO value flows through to your destination page. This is the main reason serious shorteners default to 301s, and it is why the common worry that "short links hurt SEO" is mostly unfounded — a point we also address in our overview of what URL shortening is.

Browsers and caching

A 301 is a promise, and browsers hold you to it. Once a browser sees a 301, it may cache the mapping and skip asking the server the next time — the address bar jump happens locally, with no network request. That is great for speed and terrible for two things link shorteners care about:

1. Click counting. A click served from browser cache never reaches the server, so it can't be counted.
2. Editability. If you repoint the short link, users with a cached 301 keep going to the old destination until their cache expires.

Servers can soften this with a Cache-Control header on the redirect response — for example, Cache-Control: max-age=90 limits how long a browser may reuse the cached redirect. This is the knob that lets a service offer permanent-redirect SEO semantics without giving up analytics accuracy entirely.

When each code is the right choice

A quick decision guide, applicable well beyond shorteners:

• Use 301 when a page has genuinely moved for good: domain migrations, HTTP-to-HTTPS upgrades, restructured URLs, and short links whose destination will never change.
• Use 302 when the destination might change: short links you plan to repoint, A/B tests splitting traffic between variants, geo-based routing where different visitors should land on different pages, and temporary campaign pages.
• Use 308/307 when redirecting endpoints that receive POST requests (form handlers, APIs) and the method must be preserved. Irrelevant for typical link sharing.

Notice the pattern: the more you value the shortener's dynamic features — editing destinations, routing, precise counting — the more a 302 fits. The more you value SEO pass-through on a fixed destination, the more a 301 fits.

How UrlShorter handles redirects

Our defaults follow directly from the trade-offs above. Standard UrlShorter links use permanent-style redirects with a short cache lifetime, which gives destinations full link-equity pass-through while keeping analytics accurate and links editable. Links you have flagged as editable or that use routing rules respond with temporary redirects, because promising "permanent" and then changing the destination is exactly the misbehavior caches punish.

A single click on one of our links goes through this sequence:

1. The request arrives and the short code is parsed from the path.
2. The code is looked up — first in an in-memory cache, falling back to the database for cold links.
3. Safety checks run: links pointing at destinations flagged for phishing or malware are blocked rather than redirected. This protects visitors and, just as importantly, the domain reputation every customer's links share.
4. The click event (timestamp, coarse geolocation, device class, referrer) is queued for asynchronous processing — it never blocks the response.
5. The redirect response goes out with the appropriate status code and cache headers.

Steps 1–5 complete in a few milliseconds of server time; the visitor-perceived delay is dominated by network round trips, not our processing. If you're curious about the analytics this produces, the documentation shows what each link's dashboard reports.

Latency: what a redirect hop really costs

A redirect adds one HTTP round trip before the destination request starts. How much wall-clock time that costs depends almost entirely on geography and connection reuse:

• DNS lookup for the shortener's domain: typically 0–30 ms (often cached).
• TCP + TLS handshake: one to two round trips to the nearest server.
• The redirect response itself: single-digit milliseconds of processing.

The dominant variable is the distance to the server answering the redirect. A shortener serving all traffic from one region can add 200+ ms for visitors on the other side of the world; one answering from edge locations near the visitor keeps the whole hop in the tens of milliseconds. When evaluating any shortener — ours included — test a link from a phone on cellular data in your actual target market rather than from your office. It is one of the checks we recommend in our Bitly alternative comparison.

For context: a hop of 50–100 ms is well below the threshold most users perceive, and far smaller than the variance introduced by the destination page itself.

Redirect chains: the thing to actually avoid

One redirect is cheap. Redirect chains — short link → tracking domain → regional domain → final page — are where real problems live:

• Each hop adds its full latency cost, and on mobile connections three hops can add a visible pause.
• Search engines follow a limited number of hops before giving up (Google documents up to ten, but consolidates signals less reliably across long chains).
• Every additional domain in the chain is another opportunity for a spam filter or corporate firewall to object.

Practical rules: point short links directly at final destinations, not at other shortened or tracking-wrapped URLs; when a destination page moves, update the short link instead of stacking a redirect on the old destination; and audit anything important with curl -I (follow the Location headers) to see the real chain. Long, parameter-heavy URLs are fine as destinations — the parameters survive the redirect untouched, as explained in our breakdown of URL anatomy.

Frequently asked questions

Does using a URL shortener hurt my SEO?

Not when the shortener issues permanent-style redirects, which pass link equity through to your destination. The genuine SEO risks are elsewhere: chains of multiple redirects, or a shortener domain with a poor spam reputation.

Why do my browser and my analytics show different click counts?

Usually caching. If a browser cached a permanent redirect, repeat clicks may never reach the server to be counted. Bot filtering works in the other direction — raw server logs include crawlers that a good dashboard excludes. Short cache lifetimes and sane bot filtering keep the numbers close to reality.

Can I change where a 301 short link points?

Yes — the mapping lives in the shortener's database and can be updated anytime. The caveat is that visitors whose browsers cached the old 301 may see the old destination until their cache expires, which is why editable links are better served with temporary redirects or short cache lifetimes.

Is a 302 bad for SEO?

Not bad, just weaker at consolidation. Search engines keep the original URL indexed longer and take more time to attribute signals to the destination. For short links whose value is clicks rather than accumulated backlinks — most marketing links — the difference is negligible.

Wrapping up

The 301/302 distinction boils down to one question: is this mapping a permanent fact or a current setting? Permanent facts deserve 301s and get full SEO pass-through; current settings deserve 302s and stay accurately measurable and editable. A well-built shortener chooses per link rather than forcing one answer on everything. If you want to see the behavior firsthand, create a link at UrlShorter and inspect it with curl -I — and for the practical basics of creating links, start with how to make a URL short.