Every link you share makes a promise: click me and you’ll land in the right place. The trouble is that “the right place” isn’t the same for everyone. An iPhone owner scanning your poster wants the App Store, not Google Play. A visitor from Berlin wants the German page, not the English one. A customer clicking your support link at 2 a.m. shouldn’t be promised live chat that went home at five.
Smart link routing solves this by letting one short link make that decision per visitor, at the moment they click. You print one URL, share one QR code, put one link in your bio — and every visitor is sent to the destination that fits their device, location, language, referrer, or the time of day.
What is smart link routing?
A normal short link is a fixed pointer: 302.sh/launch always redirects to the same target URL. A smart-routed link adds a small set of rules that are evaluated before the redirect fires. If a rule matches the visitor, they’re sent to that rule’s destination; if nothing matches, they get the link’s default target, exactly as if no rules existed.
The crucial detail is where this happens: on the server, during the redirect itself. There’s no JavaScript snippet on a landing page deciding where to bounce people next, no flash of the wrong page, and nothing for the visitor’s browser to run. The routing decision is finished before the destination page even starts loading — which is also why it works from places where you can’t run code at all: QR codes on packaging, links in email and SMS, print campaigns, and social bios.
The five rule types
On 302.sh a link can route on five different signals, and you can combine them freely on the same link:
| Rule type | Matches on | Classic use |
|---|---|---|
| Device | Bot, tablet, iOS phone, Android phone, desktop | One QR code → the right app store |
| Geo | Country, with region/city overrides | Country-specific stores or offers |
| Language | Browser language (BCP-47 tags) | Localized landing pages |
| Referrer | Where the click came from | Platform-specific landing pages |
| Time | Weekday/hour windows, scheduled start/end | Office-hours support, launch windows |
Device routing: the app-store classic
The single most common smart-routing job is the one every app developer knows: you have one download link — on a poster, in a podcast description, on the back of packaging — and two app stores. With device routing you set an iOS destination (your App Store page) and an Android destination (your Play Store page). iPhone visitors land on the App Store, Android visitors on Play, and desktop visitors fall through to your website, where they can read more or send the link to their phone.
302.sh distinguishes five device classes: bot, tablet, iOS phone, Android phone and desktop. The most specific class wins — a bot rule beats a tablet rule, which beats the phone rules, which beat desktop — and any class you leave empty simply falls through to the default target. The bot class deserves a special mention: link-preview crawlers and scrapers can be routed to a stable public page so your campaign-specific destinations aren’t what gets cached in a chat app’s unfurl.
Geo and language: one launch, every market
Geo rules match the visitor’s country — send German clicks to example.de, US clicks to your dollar-priced checkout, everyone else to the international page. When you need finer control, region- and city-level rules override the country rule wherever they’re more specific.
Language rules complement geo rather than duplicating it: they match BCP-47 language tags like en, de or pt-br against the visitor’s browser Accept-Language header. That distinction matters — a French speaker in Montreal and an English speaker in Montreal are in the same country but want different pages. Geo answers “where are they?”; language answers “what do they read?”
Referrer routing: meet traffic where it came from
Referrer rules look at where the click came from and pick a destination per source — first matching pattern wins. Clicks arriving from twitter.com can land on a page whose headline and social proof speak to that audience, while clicks from your newsletter land on a version that skips the introduction they already read. It’s the cheapest form of message matching: instead of running separate links per channel (and reprinting them everywhere), you run one link that adapts.
Time routing: links that keep office hours
Time rules come in two flavors. Recurring rules match weekday-plus-hour windows in a timezone you choose: Monday to Friday, 9:00–17:00 in Europe/Berlin, route the support link to live chat; outside that window, the default target serves the contact form. Scheduled windows are one-off: give the link a start and an end, plus an optional “before” URL (a coming-soon page while the campaign hasn’t started) and an optional “after” URL (a recap page once it’s over). Your launch link can be printed weeks early and retired gracefully, without anyone editing anything on launch morning.
How rules combine
You rarely need to think about precedence, but the model is simple: device rules are checked first, then geo, then language, with the most specific match winning — and anything that matches nothing falls back to the default target. Rules only ever override the destination for visitors they match; they can never break the link for everyone else. A link with a single iOS rule behaves exactly like a normal short link for every non-iPhone visitor.
Routing rules are editable at any time — and because every 302.sh link answers with a temporary redirect, a rule change is live on the very next click. No caches to flush, no QR codes to reprint.
That instant-edit property comes from the same design decision that gives 302.sh its name: short links use 302 redirects rather than 301s, so browsers re-check the destination on every visit instead of caching it forever.
Smart routing vs. A/B split routing
Smart routing is deterministic: the same visitor, in the same context, always goes to the same place. Its sibling feature, A/B split routing, is probabilistic — it divides traffic between destination variants by weight so you can compare how they perform. Use smart routing when the right destination is a fact about the visitor; use a split when finding the right destination is the experiment. (Smart routing is available from the Creator plan; splits are a Pro feature.)
Setting it up on 302.sh
Smart routing lives in the Smart routing section of the new-link form (and can be added to any existing link later). Fill in only the rules you need: five optional device slots, geo and language tables, referrer pattern rows, recurring hour windows, and the scheduled start/end window. Everything you leave blank falls through to the default target.
Smart routing is included on the Creator plan ($9/month) and above. As with every 302.sh feature, the fundamentals don’t change: redirects are unlimited on every plan, and every link — routed or not — comes with 90-day click analytics, so you can see exactly how much traffic each audience segment actually sends.
Frequently asked questions
Can one short link send iPhone and Android users to different app stores?
Yes. Set a device rule with your App Store page as the iOS destination and your Google Play page as the Android destination. iPhone visitors land on the App Store, Android visitors on Play, and everyone else falls through to the link’s default target — all from one short link or QR code.
Does smart routing work on QR codes?
Yes. Routing happens on the server at the moment of the redirect, not in the destination page’s JavaScript, so it works anywhere the link can be opened — QR codes on packaging or posters, email, SMS, social bios and print. The QR code encodes the short URL, and the routing decision is made fresh on every scan.
What happens when no rule matches a visitor?
The visitor is redirected to the link’s default target URL. Rules only override the destination for visitors they match, so a link with only an iOS rule still works normally for everyone on desktop or Android. You can never strand a visitor by adding routing rules.
Can I route visitors by their country or language?
Yes, both. Geo rules match the visitor’s country, with more specific region or city rules taking precedence when you add them. Language rules match BCP-47 tags like en, de or pt-br against the visitor’s browser Accept-Language header. Together they let one link serve localized landing pages worldwide.