The address of a foreign-language version gets decided in five minutes. Then you live with it for years. There are three options: a folder on your existing site, a subdomain, or a brand-new domain for each country. At first glance, all three look equally reasonable, and two of them will saddle you with extra work.
This question comes up on every project where a language gets added. And almost every time, someone decides it in passing, mid-conversation, because it looks like a technical detail. A year later, they wonder why nobody can find the English version and why everything gets done twice.
You pick the address once, and it stays with your site for years
This decision is harder to undo than it looks. You can rewrite the text on a page anytime. But moving an entire language version means redirecting every address, reconfiguring your analytics, and accepting that your site will drop in search for a while.
Subfolder
An address like yourcompany.com/en/, where the English version lives as a folder on the same domain as the original. For visitors, it’s still one website. And for search engines, analytics, and the tools you use to manage the site, it’s also still one website, just with more sections.
You can rewrite the text on a website in an afternoon. The years of links pointing to that address can’t be rewritten at all.
Three options, and only one adds no extra work
A folder looks like yourcompany.com/en/. A subdomain looks like en.yourcompany.com. And a country domain is an entirely different address for each country, usually with that country’s domain ending.
The difference between them lies in how many times you’ll do the same thing, not in how the address looks. A subdomain and a new domain each require their own setup, their own analytics, their own verification, and their own management. One extra is still bearable. By the third and fourth, you’re running a second website next to the first.
That’s why subfolders won for my client. All the languages sit on one domain, get deployed with the same prompt, and get added as new sections rather than new websites. As a result, the fifteenth language behaves no differently than the second.
The same applies when your website is built on sales pages and funnels inside a marketing platform. There, too, the language version should be another branch of the same site. Once it starts living somewhere else, your analytics split apart and nobody can tell where orders are coming from.
What adds up on one domain, and why it matters
On one domain, pages help each other. A link from abroad to your English article strengthens the whole domain, including your main-language pages. If that article lives on a subdomain, most of the effect stays there, and your main site gets the crumbs.
The work you’ve already done adds up the same way. A website that’s been running for a few years has history and links behind it. A language moved in under the same roof gets its share of that right away. A new domain starts from zero, as if the company had been founded yesterday.
You notice it in your analytics, too. One website means one dashboard where you see all the languages side by side and immediately spot which one is growing. Scattered subdomains give you the same answer in pieces, and then nobody puts it back together.
If you’re in the middle of moving your website from another tool, decide on the language addresses before the move. One extra redirect is still cheaper than two in a row.
How to tell search engines it’s the same page in another language
A search engine can mix up language versions and treat one of them as a pointless duplicate. There’s a simple tag for this, and you set it up once.
hreflang
A tag in the page source that tells search engines: this page is the same as that one, just in another language. Thanks to it, the versions don’t compete with each other, and people get offered the one in their language. You add to it with each new language, and it takes minutes if the versions are organized sensibly.
What to ask before you add a language
Three questions that will save you six months. Can my website or builder handle language versions in subfolders? Can each version be measured separately and also seen together? And what happens to the addresses that exist today when a language gets added under them? If you don’t know the answer to any of these, hold off on translating.
Most ready-made builders can handle this today. But check before you start translating. And after launch, you need to go through the links, redirects, and internal navigation. AI can do that boring check by itself, so there’s no reason to skimp on it.
When a separate domain makes sense
None of this applies when the foreign market is a separate business rather than a language version: a different product range, different prices, its own team, its own support. There, a separate domain is right, because it also separates what really is different. The telltale sign is simple: if you sell the same thing in the other country, it’s a language. If you sell something different there, it’s a different company.
There’s a second case, and we ran into it with a client. The home market stayed on the Czech domain that local customers have known for years, and the language versions moved to one shared address, each in its own subfolder. It’s a deliberate choice: a brand people know at home is an asset, and you don’t move it for convenience.
The whole decision in a nutshell
- Decide on the address before the first translated page exists.
- For a language version of the same product, choose a subfolder, meaning a folder on your existing domain.
- Check that your website or builder supports it before you start translating.
- Add hreflang tags so search engines don’t mix up the versions.
- After launch, go through the links and redirects so nothing gets lost along the way.
- Save a separate domain for a market that’s a business of its own, not just another language.
The address looks like a detail, and that’s why it gets rushed. Yet it deserves half an hour of calm thinking: you’re choosing the address for your fifth language, not your second.
