Before writing a single line of hreflang, a multilingual site has to decide where its different versions live. The choice of URL structure is hard to change later: every subsequent change is a migration, with all the risks that entails. It is therefore worth thinking it through at the start, weighing the costs, the management effort and the signals each option sends.
The possible options
| Structure | Example | Main notes |
|---|---|---|
| Subfolders | example.com/it/ |
one domain, simple management |
| Subdomains | it.example.com |
technical separation, more complex setup |
| Country-code domains (ccTLD) | example.it, example.de |
strong geographic signal, high costs |
| Parameters | example.com/?lang=it |
not recommended |
Subfolders
This is the most widespread choice for small and medium sites. All languages share the same domain, so links earned by one version strengthen the whole site. One certificate, one DNS configuration, one property to monitor, with the option of filtering data by folder.
The downside is that the separation is only logical: if you want to host one language on different infrastructure, you have to route requests at the proxy or CDN level.
Subdomains
They allow the versions to be separated technically, for instance when each country has its own team, CMS or provider. On the other hand, each subdomain has to be configured, monitored and secured separately, and engines may treat it with some autonomy from the main domain.
Country-code domains
A domain such as .it or .de clearly communicates the target country, and in some markets users trust a local extension more. Costs grow, however: registering and renewing several domains, possible residency requirements for some extensions, links and authority split across separate sites.
Remember that a ccTLD indicates a country, not a language. A .ch site can have versions in Italian, French and German; an .it site is not the right place to serve the Swiss market.
Some two-letter domains, such as .io or .co, are used as generic extensions, and engines often treat them as such, without associating them with the original country.
Parameters
?lang=it works technically, but it is fragile: the parameter is easily lost in links, gets confused with tracking parameters and makes it hard to analyse the versions separately. Better to avoid it.
Language or country?
Before choosing the structure, be clear about what you are segmenting:
- language only: same products and same conditions for everyone, only the translation changes.
/it/,/en/,/de/are enough; - country: different prices, currencies, availability or regulations. You need versions such as
/it-it/,/it-ch/,/de-ch/, or country-code domains.
Mixing the two levels without a rule produces inconsistent structures, with /en/ next to /uk/ and /us/, which are hard to maintain and to annotate.
The problem with automatic redirects
Many sites redirect users based on their IP address or the browser's Accept-Language header. It looks like a courtesy, but it causes serious problems:
- crawlers often come from addresses in a single country and without language preferences: if they are always redirected to the same version, the others risk never being crawled;
- users who travel, expats or anyone on a VPN end up in the wrong language with no way out;
- shared links no longer lead to the page the sender meant to show.
The most robust solution is:
- each URL always serves the same language, regardless of who requests it;
- if the user's language does not match, a non-intrusive banner suggests the appropriate version;
- the user's choice is remembered, for example with a cookie, and respected on later visits;
- any automatic redirect applies at most to the site root, with a temporary response, and the root is marked as
x-default.
Content that really needs translating
A perfect structure won't save half-translated pages. The parts that often stay in the original language are:
- titles and meta descriptions;
- image alternative text;
- navigation labels, buttons and error messages;
- URL slugs, which can and usually should be translated;
- structured data, which must reflect the visible text in the page's language.
In my work, when I check a multilingual site, I look first at the shared templates: that is where the untranslated phrases that end up on hundreds of pages tend to hide.
In short
- Decide the structure at the start: changing it later is a migration.
- Subfolders are the simplest and cheapest choice for most sites.
- Country-code domains signal a country, not a language, and multiply costs.
- Avoid automatic redirects by IP or browser; suggest the version with a banner.
- Also translate titles, slugs, alt text, interface and structured data.
