How to build a multilingual website: URL structure and hreflang
Building a multilingual website means making four decisions in order: which pages exist in which language, and whether their text is translated or adapted; which URL structure each language lives in; how the language versions are linked with hreflang tags; and how the content will be kept current over time. Google recommends a separate URL for each language, and advises against redirecting visitors automatically based on their language.
Below we walk through those four decisions, using the Turkish and English structure of our own site as an example.
How a multilingual site differs from a translation plug-in
A multilingual site gives each language version its own address, its own text and its own headings. A tool that translates the page on the fly in the visitor’s browser does not offer search engines a separate page. Someone searching in that language will not find your site in it.
Google makes two points here. First, each language version should have its own URL; switching language with cookies or browser settings is not recommended. Second, translating only the boilerplate — menus, footer — whilst leaving the main content in one language can create a bad user experience. Source: Google’s guidance on managing multi-regional and multilingual sites.
Translation or adaptation?
Translation carries a text from one language to another. Adaptation rewrites it for the context of the reader who speaks that language. For most business sites, adaptation is the right answer.
An example makes the difference clear. If a Turkish page says “KVKK-compliant forms”, the abbreviation means nothing to an English reader. In an adaptation, one sentence explains that KVKK is Türkiye’s personal data protection law. Or a line on a service page such as “we reply within two working days” can stay as it is, whilst a reference to a local holiday is taken out.
| Translation | Adaptation | |
|---|---|---|
| What happens | The text is carried across as it stands | The text is rewritten for the reader’s context |
| Abbreviations and local institutions | Kept as they are | Explained, or given an equivalent |
| Examples | The same examples are used | Familiar examples are chosen where needed |
| Tone | The source language’s tone is kept | The target language’s writing habits are followed |
| Where it fits | Legal texts, technical documents | Marketing, service and journal pages |
Legal texts are the exception. In privacy notices or terms of use, shifts in meaning are unwelcome, so their translation should be checked by a lawyer.
Machine translation can serve as a first draft. But the published text should be read by someone who knows the language well. A wrong term or an awkward sentence undermines trust in the rest of the site.
On our own site, English articles are written as adaptations of the Turkish ones. Each English article is linked to its Turkish pair. Where a Türkiye-specific rule comes up, it is explained with its context for the English reader. We write in British English.
Which URL structure should you choose?
Where each language version lives is a decision to make at the very start; changing it later turns into a site migration. Google’s guidance lists four options.
| Structure | Example | In its favour | What to watch |
|---|---|---|---|
| Country-code domain | example.de | The target country is clear | A domain per country, separate registration rules, more upkeep |
| Subdomain | en.example.com | Easy to set up; can sit on different servers | Visitors may not grasp the target from the address |
| Subdirectory | example.com/en/ | Easy to set up and maintain; one domain | All languages sit on the same server |
| URL parameter | example.com?lang=en | Very little | Google does not recommend it |
For most business sites, a subdirectory is the simplest option: one domain, one hosting account, one Search Console property. Country-code domains make sense for companies with separate teams and separate content in separate countries. We cover the registration rules for domain extensions in domain, hosting and business email.
On our site, Turkish sits at the root and English under /en/. The paths change with the language too: Turkish /yazilar/ becomes /en/journal/ in English. When the address itself is in the reader’s language, a shared link says what it is about before anyone opens it.
What is hreflang, and how is it set up?
hreflang is a tag that tells search engines which versions of a page exist in other languages. Google uses it to show searchers the version in their own language.
According to Google’s documentation on localised versions, these are the rules to follow:
- Choose one of three methods. Tags can go in the page’s HTML head, in the HTTP response header or in the sitemap. Google treats all three as equivalent; one is enough.
- Each version lists itself and the others. The Turkish page should point to itself and to its English counterpart, and the English page should do the same.
- The relationship must run both ways. If two pages do not point to each other, Google ignores the tags.
- Use full addresses. Complete URLs, starting with
https://. - Write language codes correctly. The language code follows ISO 639-1 (
tr,en), with an optional region code (en-GB). A region code cannot be used on its own. - Add
x-defaultfor unmatched languages. This is the page shown when a visitor’s language matches none of the versions.
Two further notes in the same documentation matter. Google determines a page’s language with its own algorithms, rather than from hreflang or the HTML lang attribute. And localised pages count as duplicates only when the main content has been left untranslated.
In our structure, every page points to its own language and, where one exists, its pair in the other language. x-default points to the Turkish version. If a Turkish article has no English adaptation, that page does not claim an English counterpart. This last point looks like a small detail. But pointing a page with no counterpart at the other language’s home page makes the hreflang information wrong.
How should a language switcher work?
Google advises against automatically redirecting visitors to another language version based on their assumed language, and against adapting content by IP address. Instead, it suggests linking from each page to its other language versions.
For a good language switcher, we recommend these points:
- It is visible. Usually in the header or footer, in the same place on every page.
- Language names appear in their own language. “Türkçe” and “English”. Our view is that flags are best avoided, because one language is spoken in many countries.
- It leads to the same page’s counterpart. Someone reading an English article who clicks “Türkçe” should reach that article’s Turkish pair, not the home page.
- It is honest when there is no counterpart. If the page has no version in that language, the switcher goes to that language’s home page, and the visitor knows it.
- It works with a keyboard and a screen reader. The language of each link is set correctly in the code.
How do you keep content current over time?
The real difficulty of a multilingual site starts after launch. When a policy, an address or a service changes on the Turkish page, the English page can be left with the old information. Visitors then see two different facts in two languages.
To prevent that, we suggest this routine:
- Choose a primary language. Changes are made there first, then carried to the others.
- Keep a list of page pairs. Which page has a counterpart in which language, and when was it last updated?
- Close a change together with its pair. When a page changes, the job is not done until its counterpart is updated too.
- Measure each language separately. In Search Console, look at performance by language folder. If one language version gets no traffic, either the content is lacking or the audience searching in that language is smaller than expected.
- You do not have to translate every page. Some content only makes sense in one language. What matters is that the pages you do publish are complete and current.
Not every page on our own site has an English counterpart either. Our cultural archive has English listing pages, but its detail pages are in Turkish only. Links from the English listings to those pages say in the code that the target is Turkish. Some of our Turkish articles also have no English adaptation yet.
Common mistakes on multilingual sites
- Keeping every language on one address and switching language with a cookie
- Forcing visitors to a version based on their browser language
- Setting up hreflang in one direction only
- Pointing pages that have no counterpart at the other language’s home page
- Translating the menu and leaving the content
- Forgetting to translate page titles and descriptions
- Leaving text in images, and alt text, in the primary language
- Launching a language and then never updating it
Most of these are noticed after launch. We gather the other technical items in our technical SEO checklist. If you are adding a language to an existing site or changing its URL structure, the redirect steps in redesigning a website without losing SEO apply as well.
Frequently asked questions
Does every page need translating on a multilingual site?
No. Some pages only make sense to readers of one language. What matters is that pages published in a language are complete in it, and that pages without a counterpart are not presented as if they had one.
Does hreflang improve rankings?
Google uses hreflang information to show searchers the version in their own language. Set up correctly, it stops someone searching in English from landing on your Turkish page, and the other way round.
Can a multilingual site be built with machine translation?
Technically, yes. But we recommend that every published text is read by someone who knows the language well. Machine translation often misses terms and tone, and in legal texts a shift in meaning creates risk.
Is a subdirectory or a subdomain better?
For most business sites, a subdirectory is simpler and easier to maintain: one domain, one hosting account and one Search Console property. If separate teams run separate content in different countries, a subdomain or a country-code domain may suit better.
If you would like a multilingual site built properly from the start, have a look at our web design process, and at our SEO and maintenance service for keeping language versions monitored after launch. To tell us about your project, write to us; we reply within two working days.