Choose a link shortener for the job
Part 1 of 2. This part covers choosing the service, the redirect to the site, and the chat preview. The practical test is in part 2.
Start with one question: where will you use the link? A message needs simplicity and a correct redirect. A printed QR code needs a known lifetime and a way to change the destination.
A link shortener stores the original address and redirects the visitor there. A short link is easier to share, but it adds a dependency on another service.
What matters to you
Find your scenario. Compare the capabilities you need, not the total number of features.
| Task | What to check |
|---|---|
| Share an address once | Simplicity, a redirect with no extra screens, limits on free access |
| Messaging apps and social networks | Page preview, behavior on a phone, whether bots are counted in the statistics |
| Email newsletter | UTM tags kept intact, a test delivery, automatic requests from mail scanners |
| Ad campaign | Limits, ads, support, statistics you can understand |
| Print and QR codes | Lifetime, changing the destination, control of the domain, a way to move the links |
| A team or automation | Shared access, roles, API, export, and the cost of the volume you need |
Practical step: write down "I need a link for…". Pick several services and mark each one: "yes", "no", or "not found in the rules". Clarify anything important that is still unknown with support before you launch.
Check how a person reaches the site
Create a test link to a known safe page. Open it in a regular browser, on a phone, and inside the messaging app you need.
- Does the correct page open?
- Is there a noticeable delay?
- Do ads, a timer, or a "Continue" button appear?
An intermediate page is a separate property of the service. You cannot tell whether it exists from the plan price or the redirect type alone.
Technical details: 301, 302, and JavaScript
- HTTP 301 — a permanent server redirect. It can be cached, which matters if you change the destination.
- HTTP 302 — a temporary server redirect. This can also be a direct redirect to the site.
- JavaScript — a script in the browser performs the redirect. Check that it works in the apps you need.
Caching also depends on the response headers. The meaning of the status codes is described in RFC 9110. The number 301 or 302 by itself does not guarantee better search rankings: see Google's explanation.
To check, open the developer tools → Network. Turn on Preserve log and Disable cache, then open the short link. Find that request and look at the status and the final URL. A status of 200 by itself proves neither ads nor a JavaScript redirect.
If you plan to change the destination, test that beforehand. After the change, open the link again in a normal window and in a private window: a stored redirect may still lead to the old address.
Look at the preview in the chat
The preview is the card before the click. The intermediate page is the screen after the click. Check them separately.
- Send the short link to yourself in the messaging app you need.
- Wait for the card. Compare the title, the description, and the image with the destination page.
- If the card is empty or wrong, send the original address next to it, without shortening.
- No card in either case: check the page metadata, whether the page can be reached, and the messaging app's rules.
- The problem is only with the short link: a possible cause is the redirect, bot access, or the platform's cache.
- The card is out of date: the platform may have kept an earlier version.
Repeat the test in every channel where you will share the link. A result in one messaging app does not guarantee the same result in another.
Next step
Keep the services that fit your task and that open the page correctly. Then check the statistics, the address parameters, and the lifetime with the checklist in part 2.