Route one short link by country, language and device
Build and test smart link rules for localized pages and app stores, with a reliable fallback and clear limits on language and device detection.
One campaign can reach readers in several countries, on phones and computers, with different browser languages. Often a single destination is enough. When it isn’t, a smart link can send each visitor to a better page while you keep sharing the same address.
In Links, destination rules can match country, language, platform and device. Start with a good main destination, then add only the few exceptions that fix a real problem for visitors. Automatic routing works best when people can still pick another language or platform on the page they land on.
Choose a main destination that works for everyone
Use a public HTTPS page that explains the offer and shows the language or download options. Everyone who matches no rule goes here. Open it while signed out and check that someone outside your main market can understand what to do.
For an app campaign, a download page with visible App Store and Google Play buttons is a better fallback than sending every unknown device to one store. For an international workshop, use an overview page with language choices. Prepare and test those pages before you create rules. Links sends people to pages that already exist; it doesn’t translate them.
Understand exactly how rules match
Open the link in the Links app, find its destinations and add a rule. Each rule needs a web address and at least one condition. A link can have up to 20 rules. Links checks them from top to bottom, and the first rule that matches wins.
Inside one category, your choices mean “or”. A rule with France and Belgium matches visitors from either country. Between the categories you fill in, conditions mean “and”. France or Belgium plus French means the visitor must be in one of those countries and use French. A category you leave empty doesn’t limit anything.
Put specific rules above general ones. If a French iOS rule should send people to a localized store page, it must sit above a rule for all iOS visitors. A later rule never overrides an earlier match. Changing the main destination doesn’t change the addresses saved in your rules.
Treat country and language as imperfect signals
Country is worked out from where the visit comes from. It isn’t the person’s nationality, home or preferred shop. Someone using a VPN or travelling abroad can show up in a country you didn’t expect. Don’t use country to decide who is allowed in, and don’t hide every route to your other markets.
Language comes from the first language set in the visitor’s browser, and Links only looks at the main language. Brazilian and European Portuguese both count as Portuguese; Simplified and Traditional Chinese both count as Chinese. So a language rule can’t tell those variants apart, and Links doesn’t look at the visitor’s second or third choice.
Keep a visible language switcher on the landing page, especially for Portuguese and Chinese. If the difference matters, use a neutral page where people choose their language, or share separate, clearly labelled links. A browser setting is a good first guess, not proof of the language someone wants today.
Build a small rule set and a test matrix
For an app launch in two languages, start with three rules in this order: French plus iOS goes to the French App Store page; iOS goes to the general App Store page; Android goes to Google Play. Leave country and device empty unless you need them for something else. Keep the download overview as the main destination.
| Test visit | Expected destination | Why |
|---|---|---|
| iPhone, French first | French App Store page | First rule matches |
| iPhone, English first | General App Store page | Second rule matches |
| Android, French first | Google Play | Third rule matches |
| Computer, English first | Download overview | No rule matches |
| Unknown platform | Download overview | The fallback still works |
For every test, open the short link itself, not just the destination. Test on real phones and in the in-app browsers your audience uses. Note the browser, language order, expected result and actual result. Check the fallback page directly too. Changing your browser language doesn’t test a country rule.
Diagnose wrong destinations before adding more rules
If a visitor reaches the wrong page, check the rule order first, then the conditions of the first rule that could match. If a device condition leaves out tablets and you don’t need it, remove it. Links works out platform and device from what the browser says about itself, so unusual or privacy-focused browsers can be sorted in unexpected ways.
Destinations must start with http:// or https://. An App Store or Google Play web address works; an app’s own link scheme, such as myapp://, doesn’t. Links isn’t an app deep-linking tool: it can’t take someone to a specific screen of your app after they install it, and it doesn’t track installs. Test any app-opening behavior separately. If every link shows as unavailable, check the paying account’s credits: links pause when credits run out and come back on their own shortly after you add more.
Keep the routing plan maintainable
Check your rules whenever a campaign, translation or store page changes. Keep a dated copy of your test table, retest the first matching rule and the fallback, and remove exceptions that no longer help anyone. Statistics show which rules get clicks, but clicks aren’t unique visitors or confirmed installs.
Use Links when one shared address needs several tested destinations. To swap in a single new page, follow the guide to changing a short link’s destination. To measure a campaign, read UTM links and click analytics so you can tell a working redirect apart from a finished action.