Skip to content
Palamedes
CtrlK
Get started

Topic · Routing

Four ways to carry a locale. They are not interchangeable.

Where the locale lives — a cookie, a path prefix, a subdomain, or a separate country domain — decides how search engines index you, how your CDN caches you, and how much infrastructure you have to own. It is one of the earliest decisions in an i18n project and one of the most expensive to reverse.

Try the 5-minute quickstartJump to the questions

01 — The problem

The decision people make by accident

Most teams pick a strategy from whichever tutorial they read first, then discover the consequences at the point where changing it means rewriting URLs that are already indexed. The four options differ on shareability, on how cleanly a CDN can cache each variant, on how much DNS and certificate work you take on, and on whether a search engine can even see the localized versions.

02 — The approach

Headless controls, and your router keeps the URLs

Palamedes deliberately does not own routing. It resolves the locale and gives you the controls; the URL structure stays with the framework you already chose.

Resolution is separate from routing

Locale resolution, the deliberate-choice cookie and canonical URL helpers are headless. That means the same translation setup works whether the locale arrives in a path segment, a subdomain, a domain or a cookie — and changing strategy later does not touch your messages.

Your router stays framework-native

There is no wrapped Link, no proprietary navigation layer and no middleware you inherit from us. You wire slightly more at the start; in exchange you keep your routing knowledge, and moving framework does not mean relearning navigation.

Every strategy is exercised, not just documented

Each of the six server frameworks has an example app for all four strategies. All 25 examples are smoke-checked on relevant PRs and main pushes; 21 browser-capable examples run the real-browser contract weekly or on manual dispatch. The tradeoffs below are written from apps that run, not from a table someone maintained by hand.

03 — Evidence

The four strategies, and what each one costs

All four are implemented for every server framework and smoke-checked across 25 examples. The 21 browser-capable examples run Playwright weekly or on manual dispatch. The differences are real and worth reading before you commit.

Cookie
One URLSimplest to run, but a shared link carries no language and search engines see a single page per route.
Route prefix
/de/…The pragmatic default: indexable, shareable, no DNS work, and it fits inside one deployment.
Subdomain
de.example.comClean separation and per-locale caching, at the cost of DNS records and wildcard certificates.
Country domain
example.deStrongest local signal and the most infrastructure — one domain, one certificate, one deployment target per market.
Read the strategy guide →

04 — Questions

Questions people actually ask

Answered here rather than buried three pages into the documentation.

Which locale routing strategy is best for SEO?
A route prefix or a separate domain, because both give every language a distinct, indexable URL. A cookie-only strategy does not — search engines see one URL per route and cannot index the localized variants separately. Country domains give the strongest regional signal but cost the most to operate.
Subdomain or path prefix?
A path prefix keeps everything in one deployment with no DNS work and is the pragmatic default for most teams. Subdomains buy cleaner per-locale caching and isolation, and cost you DNS records plus a wildcard certificate.
Can I change strategy later?
The translation side is unaffected — messages, catalogs and identity do not depend on where the locale lives. What is expensive is the URLs themselves, since anything already indexed or shared needs redirects. That is why the decision is worth making deliberately.
Does Palamedes provide the routing?
No, on purpose. You get headless locale resolution, a deliberate-choice cookie and canonical URL helpers; your framework's router owns the URLs. If you want localized pathnames as a library feature, next-intl covers that ground and we say so on the page comparing the two.
How do I know these actually work?
Every strategy has a running example app per framework — 25 in total — built and smoke-checked against the workspace packages on relevant PRs and main pushes. 21 browser-capable examples run Playwright weekly or on manual dispatch; 20 UI-adapter examples have versioned screenshots.

05 — Keep reading

Related pages

The verified framework matrix

Read →

Compare with next-intl

Read →

All guides

Read →

Every claim on this page is checked into the repository.

See the proofTry the quickstart