301 vs 302 Redirects: Which Should a Short Link Use?

Most advice about redirect status codes was written for a different job: moving a page permanently and wanting browsers and search engines to update their records. For that job a 301 (or its stricter sibling, 308) is right, and the advice is sound.

A short link is a different job. It is an address that exists only to send people somewhere else, and the service behind it needs to stay able to answer for it. That changes the calculation. This piece explains what each code actually means according to the HTTP specification, what browsers and proxies do with them in practice, and why LinkMint answers every short link with a 302 even though its links are never edited.

What the four codes actually say

HTTP semantics are defined in RFC 9110, which replaced the older RFC 7231 in 2022. It describes four redirect codes that matter here, and they differ on two independent questions: is the move permanent, and may the client change the request method when following it?

The definitions of all four, and the list of status codes that are heuristically cacheable, are in RFC 9110 sections 15.1 and 15.4. Read RFC 9110

There is also 303 See Other, which explicitly tells the client to fetch the new address with GET whatever the original method was. It is the right answer after a form submission and rarely relevant to short links.

What "cacheable" really means

This is where most explanations get vague, so it is worth being exact. Whether a response is stored is governed mainly by its caching headers: Cache-Control and, in older setups, Expires. The status code matters when those headers are absent.

RFC 9110 lists certain status codes as heuristically cacheable. 301 and 308 are on that list; 302 and 307 are not. A heuristically cacheable response with no explicit freshness information may still be stored, and the cache gets to guess how long it stays fresh. A 302 or 307 with no caching headers should not be reused without asking the server again.

• •A 301 with no caching headers: browsers and shared caches may store it and reuse it, and in practice browsers often keep such redirects for a long time.
• •A 301 with Cache-Control: no-store: it should not be stored at all. The status code does not override an explicit instruction.
• •A 302 with no caching headers: not reused from cache; the client asks again each time.
• •A 302 with Cache-Control: max-age=86400: it can be cached for a day, exactly like any other cacheable response. "302 is never cached" is a common simplification, and it is wrong.

Two kinds of cache are involved. The browser's own cache lives on the visitor's device. Shared caches, such as a corporate proxy or a CDN sitting in front of a site, sit between many users and the server. Both follow the same rules, and both are outside the control of the person who made the link. Once a long lived 301 is stored on someone's laptop or in their office proxy, there is no message you can send to remove it. It stays until it expires or the cache is cleared.

Method preservation, and when it matters

When the original request was a POST, a client following a 301 or 302 is permitted to switch to GET for the next request. Early browsers did exactly that, sites came to rely on it, and the specification now documents the behaviour rather than forbidding it. 307 and 308 were introduced so that a server could say "redirect, and keep the method and body as they are".

For short links this almost never comes up. Someone tapping a link sends a GET, and a GET stays a GET under all four codes. Method preservation matters when software sends other methods through a redirect: an API client posting JSON, a webhook, a form whose action points at a redirecting address. None of those are sensible things to route through a public short link, which is why the 302 versus 307 question is mostly academic here.

When destinations can change: the classic argument

On services where the owner can edit a link's destination, the case for 302 is straightforward. Suppose a 301 with no caching headers points a link at a spring sale page, and later the owner edits it to point at the summer range. People who have never visited go to the summer page. People whose browser stored the 301 may keep going to the spring page, because their browser never asks again. The owner sees the change applied; the visitor's browser disagrees, and nobody can see who is affected.

Services with editable links therefore default to 302 (or 307), usually with headers that forbid caching, so that a change takes effect for everyone on their next visit. That is the argument most articles on this topic make, and it is correct for those services.

When destinations never change: why LinkMint still uses 302

LinkMint links cannot be edited. The destination saved when a link is created is the destination it keeps for good. So the stale destination problem above cannot happen here, and it would be fair to ask whether a cached 301 would be harmless, or even slightly faster for repeat visitors.

It would not be harmless, because the destination is not the only thing that can change. Whether the link should be followed at all can change. If a link is reported at /report and a moderator disables it after review, the server stops redirecting and shows a notice page instead. That only works if visitors' browsers actually ask the server. A browser holding a cached 301 would skip the server entirely and keep sending its owner straight to a destination that has been judged harmful. For a phishing page or malware download, that is precisely the visitor you most need to reach.

• •Moderation needs every visit to reach the server, so disabling a link protects everyone at once.
• •A 302 with no-store says honestly what is happening: the server decides on each request.
• •The cost is one small request to the short link service per visit, which a person on a normal connection will not notice.
• •Nothing is recorded during that request, so asking again each time does not mean being counted each time.

So the reasoning for LinkMint is not "we might change our mind about the destination". It is "we must be able to stop a link". The status code follows from that.

But what about search engines?

The usual argument for 301 is ranking. Search engines treat a permanent redirect as a strong signal that the target should be the indexed, canonical address, and a temporary one as a weaker signal. If public pages link to a short URL and you want the destination to benefit, a permanent redirect is the conventional choice.

Look at where short links are actually used, though: social profiles, emails, printed material, QR codes, slides, chat. Very little of that is crawled, and links in those places typically carry little or no ranking value to begin with. If you want a page to rank, link to that page directly from public web pages. A short link is a tool for humans who need to read, type or scan an address, not a tool for search engines.

Which code for which job

Checking what a link really returns

You can see the status code and headers of any link without following it. This is worth doing on anything important before it goes to print.

curl -sI https://linkmint.org/k7Rmz

HTTP/2 302
location: https://shop.example/spring/boots?utm_source=print
cache-control: no-store, max-age=0

Look at three things: the status code, the Location (it should be the address you intended, query string intact), and the caching headers. A 301 with no caching headers on a link you expected to be temporary is worth discovering now rather than after the flyers are printed. On LinkMint, putting a plus sign in front of the code shows the destination in a browser without following it, which answers the second question without a terminal.

Redirect chains matter more than the code

A subtler problem than choosing the wrong code is choosing the right one several times in a row. A short link points at a campaign address, which redirects to add a trailing slash, which redirects to a regional version, which redirects from http to https. Each hop is defensible on its own and the visitor waits for all of them.

• •Each hop is a full request and response, and on a slow mobile connection each one is noticeable.
• •Browsers stop after a limited number of redirects, and a loop fails completely.
• •A hop that answers with a long lived 301 pins the visitor's browser to everything after it.
• •Every hop is another server that has to be up for the link to work.

The fix is simple: before shortening, open the address in a browser, let it settle, and shorten the final URL from the address bar. Because LinkMint links cannot be edited, this check matters even more. Get the destination right before you create the link.

Where 301 is the right answer

This piece argues for 302 on short links, so it is worth being plain about where the opposite holds. If you are moving pages on your own website for good, during a restructure, a domain change or a move from http to https, use 301 or 308. There you want browsers, proxies and search engines to remember the new address and stop asking. Caching is the feature.

The distinction is not really about the numbers. A permanent redirect is a statement that the old address is finished. A short link is an address that a service keeps answering for, and as long as it is answering, it needs every request to reach it.

The short version

1. 01301 and 308 are permanent and heuristically cacheable; 302 and 307 are temporary and are not reused from cache without explicit headers.
2. 02Caching headers override the status code's default in both directions.
3. 03301 and 302 allow POST to become GET; 307 and 308 do not. Short links are followed with GET, so this rarely matters.
4. 04Services with editable links need 302 so edits take effect for everyone.
5. 05LinkMint links never change, but they can be disabled after an abuse review, so they redirect with 302 and no-store to make sure a disabled link stops for everyone.