301 vs 302 Redirects: Which One Your Short Links Should Use
You edit a short link to point somewhere new. Then a colleague clicks it and lands on the old page. Your server is fine. The old redirect is stuck in their browser.
Use a 301 when you want Google to index the destination, and send a Cache-Control: max-age with it. Use a 302 when the link must stay editable, and send no cache headers at all. The code is an SEO choice. The header is a control choice.
That second half is the part most 301 vs 302 guides skip. The biggest shortener in the world does not skip it.
What does each redirect code mean?
A redirect is a short reply that says "go here instead". The code explains why.
- 301 Moved Permanently — this moved for good.
- 302 Found — this lives somewhere else for now.
- 307 Temporary Redirect — like a 302, but the method must not change.
- 308 Permanent Redirect — like a 301, but the method must not change.
The current rulebook is RFC 9110, from June 2022. It is also STD 97. It replaced RFC 7231 and RFC 7538. A guide that still cites RFC 7231 has not been checked since then.
One line in it does most of the work. Section 15.1 lists the replies a cache may store on its own guess. Of the redirect codes, only 300, 301 and 308 are on that list. 302, 303 and 307 are not.
So a 301 can sit in a browser cache with nothing telling it to. A 302 has to be told.
One point of history, because it gets muddled. 307 arrived in RFC 2616 in June 1999. 308 arrived in RFC 7538 in June 2014. They are a pair by design, not by date.
Do 302 redirects lose link juice?
No. Google's own docs say otherwise, in plain words.
Google's site move guide says this: "Don't worry about link credit. 301 and other permanent redirects don't cause a loss in PageRank."
There is no matching line about a 302 losing PageRank. Google has never published one.
What Google does document is trust. Its HTTP status codes page calls a 301 a strong signal that the target should be used. It calls a 302 a weak one. It also says a 308 behaves like a 301, and a 307 like a 302.
So the real difference is which URL Google shows you, not how much value flows through. With a 301 that is usually the destination. With a 302 it is usually the short link itself. We go deeper on that in our piece on whether short links hurt your SEO.
The "you lose 15% on every redirect" line has no source either. That 15% is the damping factor from the 1998 PageRank paper. It applies to ordinary links, and someone pinned it to redirects.
How long does a browser cache a 301?
Here is where most guides go wrong. "Browsers cache 301s forever" is true of one browser.
We read the source code of all three engines.
Chrome keeps a bare 301 with no end date. In net/http/http_response_headers.cc, a 300, 301, 308 or 410 is given lifetimes.freshness = base::TimeDelta::Max(). The comment beside it reads // It should never be stale. Chrome writes it to disk, so it lives through restarts.
Safari keeps it for exactly one year. WebKit's CacheValidation.cpp returns 24_h * 365 for a 301, and nothing longer.
Firefox barely keeps it at all. Only a 410 gets the endless branch there. A 301 falls past it and is stale the moment it lands. Since 2024, Firefox will not even write a plain http: 301 to disk.
No RFC gives any number here. RFC 9111 says outright that it "does not provide specific algorithms". A guide claiming the spec says one year is quoting Safari's source code.
You cannot take a cached redirect back
A cached 301 lives in someone else's browser. While it is fresh, that browser never asks your server again. Your server is not wrong. It is simply not consulted.
There is no way to reach into that cache and clear it. No header, no API, no purge button. It goes when the user clears their own cache, or never. In Chrome, "never" is the honest answer.
The header that fixes it
All three engines check Cache-Control before falling back to their own guess. RFC 9111 requires that. So Cache-Control: max-age=90 caps the stale window at ninety seconds in every one of them, and you pick the number.
One caveat, honestly sourced. In Chromium's code, the must-revalidate check sits only on the branch for 200-style replies. Read as written, a 301 with must-revalidate and no max-age still looks fresh forever. That is what the source says. We have not watched it happen in a live browser. Use max-age.
What do the big shorteners actually send?
We tested this ourselves on 19 September 2026, with curl, from one machine. Here is the headline.
Bitly returns a 301, and caps it with Cache-Control: private, max-age=90. Five separate bit.ly links gave the same answer. So did amzn.to and apple.co. A fourth domain, dlvr.it, sent the same 301 and the same ninety-second cap.
Read what that means. Bitly takes the strong search signal a 301 gives. Then it refuses to pay for it, by holding the browser cache to ninety seconds. An edited link goes stale for a minute and a half, not forever.
Nobody agrees on this, though. Our test found 301s, 302s, a 303, a 307, and pages that were not redirects at all.
Two rows are worth a second look.
The is.gd and ow.ly links we tested sent a bare 301 with no cache header. That is the stuck-redirect case, live in the wild. The flip.it link did the opposite: a 302 held in caches for an hour. So a 302 is not automatically safe, and a 301 is not automatically dangerous. The header decides.
One oddity we will report but not recommend. The t.co link we tested returned a plain page to a browser and a 301 to curl and to Googlebot. Serving crawlers something different is close to cloaking, so treat it as an observation.
Behaviour also varies by link, not only by service. Two lnkd.in links disagreed with each other in the same test. Say "the link we tested", never "LinkedIn returns".
Does the redirect code change what the destination sees?
No. The referrer and the query string are decided elsewhere.
Shorteners do meddle with the referrer, though, using a separate header. The bit.ly, amzn.to, apple.co and tinyurl links we tested sent Referrer-Policy: unsafe-url. That hands the destination the full page address the click came from, which is more than a browser gives by default. The cutt.ly link sent same-origin, which hands over nothing.
Query strings only survive if your redirect writes them into the new address. HTTP does not carry them across for you.
301 vs 302: which should a short link use?
Now the honest part, including our own choice.
clik.so's redirector answers a plain short link with a 302, and sends no caching headers on it. A 302 is not cacheable by guesswork, so no browser holds on to an old destination after you edit the link. The cost is real: Google reads a 302 as the weak signal, so it tends to keep showing the short link rather than your destination. If that matters, put the link on a domain you own, so the URL being shown is still yours.
Bitly made the other trade. A 301 with max-age=90 earns the stronger signal, and pays for it with a ninety-second window where a fresh edit has not reached everyone yet.
Neither choice is wrong. A permanent move wants a 301; a pointer you may edit wants tight cache control. Pick by asking whether the destination can change.
How many redirects can you chain?
Twenty, in every current browser. The WHATWG Fetch Standard sets that limit, and Chrome, Safari and Firefox all match it in code.
The "five redirects" figure still quoted online is a recommendation from RFC 1945, the 1996 HTTP/1.0 spec. It was dropped from the standard long ago.
curl is different again. It follows up to 50, and it follows none at all unless you pass -L. That is why curl -I is the cleanest way to see what a short link really returns.
Googlebot follows up to 10 hops, and Google advises keeping chains to "ideally no more than 3 and fewer than 5". Chains also age badly, which is part of how short links rot.
Common questions
Does a 301 or 302 turn a POST into a GET?
It may. RFC 9110 says a user agent "MAY change the request method from POST to GET". It is permitted, not required, so you cannot rely on it either way. Use 307 or 308 when the method must survive. Short links are plain GET clicks, so this rarely applies to them.
Do browsers break the spec by doing that?
Not any more. RFC 1945 in 1996 said some agents would "erroneously" change a POST into a GET. Browsers kept doing it. By RFC 9110 in 2022, the standard had changed to allow it. Calling it a violation today is out of date.
Is a 308 better for SEO than a 301?
No. Google's status codes page says a 308 is "equivalent to 301" and a 307 is "equivalent to 302". The pairs differ on whether the request method is preserved, not on search treatment. Pick on method behaviour, never on rankings.
Can I undo a 301 I already sent?
Not for anyone who already cached it. There is no server-side way to clear a redirect out of a stranger's browser. You can only bound the damage in advance, by sending a Cache-Control: max-age before the link goes out.
Does a long-lived 302 eventually become a 301 to Google?
Google's documentation does not say so anywhere. It says the indexing pipeline does not use a temporary redirect as a signal for the canonical URL. Treat the claim as folklore until someone at Google documents it. If you want permanence, send a permanent code.
Check what your own links return
Run curl -I against any short link you use and read the status line and the Cache-Control header. It takes seconds and it settles the argument.
If you want links you can edit later, clik.so's free plan covers 50 new links a month and one custom domain, with no card needed. New to the topic? Start with what a URL shortener actually does.