How Link Redirects Actually Work: 301, 302, and the 50ms Hop

Fifty milliseconds. That's roughly how long a short link takes to do its job. The browser asks a server where to go, the server answers, and the browser moves on. From the visitor's side it's nothing, a flicker before the page loads. But from your side, that flicker is the whole game. Every piece of link intelligence you'll ever collect, the device, the country, the campaign that earned the click, gets captured inside that hop or not at all.

Which raises a question worth sitting with before you build anything on top of links. What actually happens in there? Most marketers treat redirects as plumbing. You paste a destination, you get a short link, it works. But the redirect is the one moment where you control the conversation between the visitor's browser and your infrastructure. Choose the wrong redirect type and browsers stop reporting clicks to you entirely. Misunderstand what survives the hop and your UTM parameters arrive mangled or missing.

Think of the redirect less as a forwarding address and more as a checkpoint. This page walks through that checkpoint in slow motion, from the status codes to the measurement to the stripping. It's one piece of the larger picture we cover in our complete link tracking guide, but it's the piece everything else stands on.

The journey of one click

Every measurement you'll ever pull out of a short link happens in the narrow gap between the tap and the page. So it's worth slowing that gap down. Once you can see the individual steps, everything else about link tracking stops being mysterious.

First, the browser resolves the short domain and sends a request. Not to the destination — to the short link's server. This is the detail people miss. A short link isn't a nickname the browser expands on its own; it's a real address that a real server answers. The browser says, in effect, "I want /q7x2, what is it?"

Second, the server records what it can see about that request before answering. And what can it see? Quite a lot, as it turns out. The user agent string reveals the device and browser, and the IP address maps to a country and often a city. The referrer header, when present, says which page the click came from. A timestamp lands on all of it. None of this requires JavaScript or a pixel or the destination's cooperation. The click itself is the data source.

Third, the server decides where to send the visitor. For a simple link there's nothing to decide, the destination is fixed. But this is the moment where a decision could be made, and later in this guide we'll look at what happens when it is.

Fourth, the server answers with a redirect. Not the page, just a status code (a 301 or 302, which we'll unpack next) and a Location header carrying the destination URL. The whole response is a few hundred bytes.

Fifth, the browser reads that header and makes a second request, this time to the actual destination. The page loads. The visitor never saw any of this, and on a decent connection the detour cost tens of milliseconds.

Notice what that sequence means for your analytics. The click was counted before the destination even started loading. If the visitor's connection drops mid-load, if the landing page errors out, if they close the tab in frustration, the click is already in your data. That's why click counts and landing page sessions never quite match. The gap between them is itself a signal, because it tells you how many people tried to arrive and didn't make it.

One request in, one small answer out, one hop forward. That's the whole machine. The interesting differences live in which status code the server chooses, and that's where we go next.

301 vs 302 vs 307 — and why trackers avoid permanent

Every redirect answers with a status code, and that code is really a policy decision. Should the browser come back next time, or is it allowed to remember the shortcut? For a normal website migration, "remember it" is exactly what you want. For a tracked link, it's the one thing you can't afford.

A 301 says "this move is permanent." Browsers take that seriously. Chrome, Safari, and Firefox all cache a 301, so the next time someone opens the same short link, the browser skips your server entirely and jumps straight to the destination. No request, no log entry, no click recorded.

From the visitor's side, nothing changed. From your dashboard's side, that person stopped existing. And because the cache lives on each visitor's device, you can't flush it when you notice. One 301 on a popular link and your click counts drift quietly downward, undercounting exactly the people who click most often, your returning audience.

A 302 says "temporarily somewhere else, ask me again next time." That "ask me again" is the entire business model of link tracking. Every click makes the round trip through the server, so every click gets counted, and, just as important, the destination stays editable. You can repoint a 302 link tomorrow and every visitor follows the new path immediately. A cached 301 keeps sending people wherever it pointed on the day their browser first saw it.

Where does 307 fit? It's the stricter sibling of 302. Both are temporary; the difference is that a 307 forbids the browser from changing the request method along the way. For a link someone clicks, which is always a plain GET, the two behave identically. You'll see 307s from tools that want to be pedantically correct, and there's nothing wrong with that. What matters for measurement is the temporary/permanent split, not 302 versus 307.

The usual objection is SEO. Doesn't a 301 pass more link equity? Years ago, yes, and the advice calcified. Google has since said 301 and 302 pass equity the same way once it understands the redirect, and a short link isn't the page you're trying to rank anyway. The destination earns its rankings from real links pointing at it directly.

So the tradeoff is honest but lopsided. A 301 buys the visitor one skipped hop, maybe 50 milliseconds, at the cost of your data and your ability to change the destination. That's why Acturity, like every tracker that takes measurement seriously, answers with a temporary redirect.

The hop is the product.

What survives the hop and what gets stripped

Think of the redirect as a handoff. The short link carries a payload, the destination URL plus whatever context rode along with the click, and the handoff is where pieces can fall off. Some of that loss is your own configuration. Most of it, these days, is deliberate cleaning by browsers, apps, and privacy tools. Knowing which is which tells you what you can fix and what you have to design around.

Query parameters are the part you control. A well-configured redirect passes them through intact. Someone clicks your short link with ?utm_source=newsletter appended, and the redirect answers with the destination URL carrying the same parameters, merged with any that were already baked into the destination. If your campaign reports show traffic arriving untagged, check the redirect configuration before blaming the email tool. Parameter pass-through is table stakes, and when it silently fails, every downstream report inherits the gap. What each of those tags actually does, and where the data lands, is its own topic, covered in the complete UTM guide.

Referrer information is a different story. The referrer is the browser volunteering "I came from this page", and browsers have spent years volunteering less. Cross-origin hops routinely trim the referrer down to just the domain, or drop it entirely. Email clients and messaging apps often send no referrer at all. So the hop itself becomes the reliable witness. The short domain sees the click directly and records the source before any of this trimming happens, which is a large part of why routing traffic through a tracked link beats trusting the destination's analytics to reconstruct where visitors came from.

Then there's a third force, tools that actively strip tracking parameters. Private browsing modes, content blockers, and privacy-focused browsers remove known ad-platform identifiers from URLs on principle. The platform-appended click IDs, gclid and fbclid and their cousins, are the primary targets, and when they vanish, the thread connecting a click to a later sale vanishes with them. First-party alternatives hold up better, for reasons worth understanding before you depend on either — how click IDs work walks through the whole mechanism.

So treat anything riding in the URL as probable, not guaranteed. Measure what you can at the hop, where nothing has been stripped yet.

Redirects that do more than forward

Step back for a moment and consider what a redirect actually is. Every single visitor passes through it, one at a time, milliseconds before they see anything, which makes it a decision point. Most teams treat that moment as plumbing. Point A to point B, done. But if the server is already inspecting the request to log a click, it already knows the visitor's device, their country, their language. Why should everyone get the same answer?

That question changes what a short link is for. A link that reads the request can send iPhone visitors to the App Store, Android visitors to Google Play, and everyone else to a landing page, all behind one printed URL. It can route German visitors to the German checkout and keep a regional promotion from leaking into markets where it doesn't apply. With branded short links, those routing rules live on the link itself, so one QR code or one bio link behaves differently for every audience without anyone maintaining separate URLs.

The same mechanism carries experiments. Because the server chooses the destination per request, it can split traffic, sending half your clicks to one page and half to another, and record which half converts. Running that as a split-traffic test at the redirect layer has a quiet advantage over testing on the page. The decision happens before any page loads, so there's no flicker, no client-side script swapping content after render, and no dependence on the destination site's tooling. The visitor never sees the fork in the road.

There's a tradeoff worth naming. Every rule you add is logic a future teammate has to understand, and a link with six conditions is harder to reason about than a link with none. Route by device or country when the destinations genuinely differ. When they don't, a plain redirect is still the right answer. The point isn't cleverness. It's that the hop is the one place you control completely, and it can do more than forward.