How to Build a Multilingual Website That Ranks

Adding a second language sounds like a translation task. It is mostly a structural one. The translation is the visible part and the decisions underneath it are what determine whether the second language earns traffic or quietly competes with the first.

Subfolder, subdomain or separate domain

Three options and they are not equivalent.

Subfolder, as in yoursite.com/en. Everything lives under one domain, so authority built anywhere on the site benefits every language. Simplest to run. This is the right default for most businesses.

Subdomain, as in en.yoursite.com. Treated as a more separate property. Useful if the two sites are genuinely run by different teams with different infrastructure.

Separate domain, as in yoursite.co.uk. Strongest local signal in a specific country, and the most expensive. You are building authority twice from scratch.

Unless there is a concrete reason, use the subfolder. We did on our own site for exactly this reason.

Language is not country

People conflate the two constantly. English is not one country. Spanish is spoken across two continents.

If you are targeting a language, use the language code alone. If you are genuinely targeting a country with different pricing, currency or legal terms, use language plus region.

Do not create country variants you cannot maintain. Three near-identical English pages for three countries is duplication with extra steps.

hreflang has to be reciprocal

This is where most implementations break. hreflang tells search engines that two pages are versions of the same content in different languages.

Three rules and all three are required.

Every page must declare itself as well as its counterparts. A page that lists only the other language is incomplete.

The declarations must point both ways. If the English page names the Turkish one, the Turkish page must name the English one. One-way declarations are ignored entirely.

Include an x-default pointing at whichever version should serve someone who matches neither.

Get one of these wrong and the whole thing is dropped silently. There is no error message, it simply does not work.

Addresses should not be literal translations

Translating a URL word for word produces an address nobody searches for.

Our own Turkish services page is /hizmetler and its English counterpart is /en/services, because that is what an English speaker actually types. The frequently asked questions page is /sss in Turkish and /en/faq in English. Same page, different words, because the words people search with are different.

Pick the term with search demand in each language, not the dictionary equivalent.

Do not detect and redirect

Automatically sending visitors to a language based on their browser or their IP address feels helpful and causes two problems.

Crawlers usually arrive from one location. Redirect based on location and you may show every crawler a single language while hiding the rest.

People travel and people have preferences. A Turkish speaker abroad gets pushed into English and cannot easily get out.

Offer the choice, remember nothing in a way that overrides the address, and let the URL decide the language. A link somebody shares should open in the language it was shared in.

Where the language switch belongs

Somewhere visible without crowding the main navigation. Top right works and is what people expect.

Also put it in the footer. Someone who has read to the bottom should not have to scroll back up.

One detail matters more than placement. Switching language should take you to the same page in the other language, not to the home page. Landing back on the home page from a service page is a small thing that feels broken.

Avoid flags. A flag is a country, and language is not country.

Partial translation is worse than none

If half the site is translated and half is not, you have three bad options and you have to choose one deliberately.

Show the untranslated page in the original language, which produces a mixed-language experience.

Hide it, which produces broken navigation.

Mark it as not for indexing until it is translated, which is usually the right answer.

What you must not do is auto-translate the gaps and publish them. Machine output published at scale as if it were finished work is exactly the pattern search engines penalise.

Legal pages are not translations

This one is missed often. A privacy notice is written to a specific legal regime. Translating it does not make it compliant elsewhere.

Turkey has its own data protection regime. The UK and the EU have theirs. The correct approach is to treat legal pages as separate documents rather than translated ones.

We do this on our own site. The Turkish side has a notice written to Turkish law and the English side has one written separately. They are not translations of each other and they carry no hreflang pair, because hreflang is for the same content in another language.

Currency, dates and formats

Translation stops at the words and localisation continues past them. A price shown in the wrong currency, a date written in the wrong order, a phone number in a format nobody local recognises. Each one is small and together they signal that the page was not really written for this reader.

Dates are the sharpest example. The same eight digits mean two different days depending on which side of the Atlantic you are on, and there is no way for the reader to tell which you meant.

Decide early where these values come from. Hardcoding them into translated text guarantees they drift apart later.

Search Console per language

If you use subfolders, set up a separate view for each language folder. You can then see which language ranks for what.

Looking at a single combined report hides the smaller language behind the larger one. Turkish traffic will drown out English if you never separate them.

Sitemaps should declare both languages too, with each address naming its counterpart, so the sitemap and your hreflang tags tell the same story.

What translation memory saves you

If the site will keep growing, decide early where translated strings live. Scattering them through templates means that in a year nobody can tell what has been translated and what has drifted.

Keeping them in one place per language makes the gaps visible. A missing key shows up as a missing key rather than silently falling back and looking finished.

It also makes review possible. A translator can work through one file instead of hunting through a codebase.

Who writes the second language

Machine translation has got good enough to be dangerous. It produces text that reads acceptably and misses the register completely.

The practical middle ground is machine translation as a first pass, then a native speaker editing for tone and for the terms your market actually uses. That is much cheaper than translating from scratch and avoids publishing something nobody checked.

What does not work is publishing the raw output across a whole site. It reads like every other site that did the same thing, which is precisely the signal search engines have learned to spot.

Before you start

• Decide subfolder, subdomain or domain, and do not change it later
• Choose search-driven URLs per language rather than literal translations
• Plan reciprocal hreflang including self-reference and x-default
• Decide what happens to untranslated pages before there are any
• Treat legal pages as separate documents
• Put the language switch where people expect it and keep them on the same page

Get the structure right and translation becomes an ordinary content task. Get it wrong and the best translation in the world will not rescue it.