301 vs 302 redirects: which should you use?

HTTP status codes are dry infrastructure until the day you pick the wrong one and spend hours explaining to your CTO why an email campaign of 200,000 people is all landing on a broken signup page. Understanding the practical difference between 301 and 302 redirects is one of the most directly useful pieces of knowledge a marketer or growth engineer can have when working with short links.

This article explains the mechanics, when each code applies, what can go wrong, and why Nimriz defaults to 302 for all short links.

What redirects actually do

When a browser or bot visits a short URL, it sends an HTTP request to the server. The server does not return the page content - instead it returns a short response with a status code and a Location header pointing at the actual destination. The browser then immediately fetches the destination.

The difference between redirect types lives entirely in how long the browser (and any caches between it and the server) are supposed to remember that mapping.

302 Found - the temporary redirect

A 302 response means: "the resource is currently at this other location." The word "currently" is doing a lot of work here. Clients - browsers, mobile apps, email link scanners - are told they should not cache this mapping as permanent. Every time someone clicks the link, the client should check back with the short link server to find out the current destination.

This is the correct default for link shortening because it preserves flexibility. Campaign destinations change. A/B tests change. Broken landing pages need swapping. With a 302, updating the destination URL takes effect immediately for everyone - not just for users who have never visited before.

Nimriz defaults to 302 for all short links.

301 Moved Permanently - and why it's dangerous in the wrong hands

A 301 response tells clients the resource has permanently moved. The intent is clear: don't bother asking again. Browsers and infrastructure caches take this seriously. Many browsers will store a 301 mapping in local cache and bypass the short link server entirely on repeat visits. Corporate proxies and mobile carrier caches may store it and share it across users.

The consequence: once a browser has cached a 301 redirect, changing the destination URL in your short link dashboard may have no effect for users who already visited. They skip the server entirely and go straight to the cached destination - even the wrong one.

There are legitimate uses for 301. If you are permanently canonicalizing a URL for SEO purposes and you never, ever intend to change the destination, a 301 is the correct signal. But for campaign links, growth experiments, and anything you might update, 301 is a trap.

The A/B test disaster: a real-world scenario

Imagine this sequence of events. A product team launches a major feature. They send a blast email to 200,000 subscribers with a short link pointing to a landing page. They use 301 because someone read that it "passes more SEO authority."

Within the first hour, the team notices the signup button on that landing page has a broken JavaScript error - no one can actually complete the form. They immediately update the short link in the dashboard to point at a fixed landing page. Crisis averted.

Except it isn't. In the first hour, roughly 60,000 people clicked the link. Many of them are now trying to forward the email to colleagues. Others saved the link in a note-taking app. Corporate mail gateways pre-fetched the link. Mobile operating systems cached the preview.

Every one of those 60,000 users - and the link-preview caches they went through - stored the 301 as permanent. They will never ask the server again. They will land on the broken page, possibly for days, possibly until they clear their browser cache manually.

If a 302 had been used, none of this would have happened. The server stays in the loop on every visit. The update takes effect the next click.

Visualizing the difference in cache behavior

sequenceDiagram
    participant Browser as User's Browser
    participant ShortLink as Nimriz Short Link Server
    participant Dest as Destination Page

    rect rgb(200, 230, 210)
        Note over Browser,Dest: 302  -  Destination updated after first click
        Browser->>ShortLink: GET /spring-launch (1st click)
        ShortLink-->>Browser: 302 → Destination A
        Browser->>Dest: GET Destination A
        Note over ShortLink: Admin updates destination to B
        Browser->>ShortLink: GET /spring-launch (2nd click)
        ShortLink-->>Browser: 302 → Destination B ✓
        Browser->>Dest: GET Destination B
    end

    rect rgb(240, 210, 210)
        Note over Browser,Dest: 301  -  Destination update ignored by browser
        Browser->>ShortLink: GET /spring-launch (1st click)
        ShortLink-->>Browser: 301 → Destination A (cached!)
        Browser->>Dest: GET Destination A
        Note over ShortLink: Admin updates destination to B
        Browser->>ShortLink: GET /spring-launch (2nd click  -  browser skips this!)
        Note over Browser: Browser uses cache → sends to A
        Browser->>Dest: GET Destination A (wrong!)
    end

What about Google and SEO?

A common argument for using 301 is that it "passes link equity" to the destination URL. This was truer in the early days of PageRank. Modern search engines, including Google, treat 302 redirects very similarly for the purposes of passing signals. The practical SEO difference between 301 and 302 through a well-configured short link is negligible for the vast majority of marketing use cases.

If you are specifically doing permanent canonical migrations - moving an entire domain, merging two sites, or permanently retiring a URL - 301 is the appropriate choice. For campaign links, 302 is not just acceptable; it is actively the better choice.

Checking what redirect type your links use

In Nimriz, the redirect type is configurable per link. The default is 302. You can verify or change it in the link editor. If you have a specific use case where a permanent redirect is appropriate, you can set 301 explicitly.

Before deploying 301 on any link:

• Confirm you will never need to change the destination.
• Confirm the destination page is stable and will not be restructured.
• Understand that browser caches may ignore subsequent updates for hours or days.

The short summary

Related

• Features - routing and experiments where your plan allows
• Link creation and slugs - how to configure per-link redirect type
• Offline-to-Online Growth Strategies - why 302 is critical for printed QR codes