Strip a short link down and there is very little left. A browser asks for acme.inbo.to/spring, the server answers with a status code and a Location header, and the browser goes there instead. That answer is the whole product.
Here is what it looks like on the wire, trimmed to the parts that matter:
curl -sI https://acme.inbo.to/springHTTP/2 302
location: https://example.com/spring-sale?utm_source=sms
cache-control: no-storeThree lines. The interesting one is the first, because the status code is a promise about how long this answer stays true.
The four redirect codes
| Code | Name | What it promises | Keeps a POST a POST? |
|---|---|---|---|
301 | Moved Permanently | This address has moved for good | No |
302 | Found | Go there for now, ask me again next time | No |
307 | Temporary Redirect | Same as 302 | Yes |
308 | Permanent Redirect | Same as 301 | Yes |
The 307 and 308 codes exist because, historically, browsers turned a redirected form submission into a plain page request. 307 and 308 forbid that. A short link is almost always clicked, never posted to, so for links 302 and 307 behave the same, and so do 301 and 308.
That leaves one real decision: permanent or temporary.
Why "permanent" is a strong word
A permanent redirect tells everyone who sees it that the old address is finished. Browsers are allowed to believe you. Unless the response says otherwise, a browser may store a 301 and, next time someone opens the short link, skip the server entirely and go straight to the destination it remembers.
For a short link, that has three consequences:
- The click isn't counted. The request never reaches the link server, so there is nothing to record.
- Edits don't reach that browser. Change the destination tomorrow, and anyone whose browser kept the old answer keeps going to the old page.
- Rules stop applying. Sending visitors to different pages by country or device, or splitting traffic between two pages, only works when every visit is asked about afresh.
A 302 makes no such promise, so browsers come back to the server every time. That is what a link you might want to measure or change needs.
What about SEO?
Google follows both kinds. Its guidance treats a permanent redirect as a strong hint that the destination is the page to show in search results, and a temporary one as a weaker hint. Both pass the link's value along.
For links shared in posts, messages, emails and print, this rarely matters: nobody wants the short link itself to rank. It starts to matter when a short link stands in for a page for good — an old campaign URL that now points at its permanent home, say, and that other sites link to. That is the case for a 301.
When a link does more than redirect
The redirect type only decides the plain hop from the short link to its destination. A link with extra settings doesn't always answer with that hop, and when it doesn't, the setting has nothing to apply to. On tinbo:
| Setting | What the visitor gets | Redirect type applies? |
|---|---|---|
| Country, device and A/B rules | A redirect to whichever destination the rules picked | Yes |
| Password protection | A password page first; once it's unlocked, the redirect | Yes, after the password |
| Open in app, on a phone | Android: a hand-off straight into the app. iPhone: a small page that opens the app, with a browser fallback | No |
| Open in the default browser, in Android in-app browsers | A hand-off that reopens the page in the visitor's own browser | No |
| A custom social preview, for crawlers | The preview card itself; no redirect at all | No |
| Expiry, once the link has expired | A temporary redirect to your "expired" page, or a plain "gone" | No, always temporary |
Everyone else — computers, and phones when the destination isn't an app tinbo knows — gets the plain redirect, with the type you picked.
Every row also depends on the request reaching the server. A browser holding on to a stored permanent redirect would walk straight past the password page, never be offered the app, and keep following the link after it expired. Passwords, app opening and expiry are three more reasons for a link to be asked about afresh on every visit.
How tinbo handles it
New links on tinbo redirect with a 302. You can switch any link to 301, 307 or 308 under Advanced → Redirect type if you need to.
Every redirect tinbo sends also carries Cache-Control: no-store, whatever the code. It asks browsers not to keep the answer at all, so even a link set to 301 is looked up on each visit by browsers that respect the header, which modern ones do. Counting, edits, rules, passwords and app opening keep working; the 301 still tells search engines that you mean it.
One response, three lines. It's worth getting the first one right.