Building a multilingual website: hreflang, i18n architecture and content upkeep
Adding a second language is an architectural decision, not a translation job. URL strategy, hreflang setup, preventing translation debt, and the seven mistakes that break multilingual SEO.
Adding a second language usually starts as "let's get the copy translated" and, six months later, becomes two sites that no longer match. Multilingual support is an architectural decision: unless the URL structure, routing, content model and publishing process are built for it from the start, translation debt accumulates.
This article walks through the decisions that keep a three-language site standing — including this site's own setup.
Summary
- Multilingual support is a URL and content architecture decision, not a translation job.
- For most corporate sites the right URL strategy is the subdirectory (site.com/en/).
- hreflang works on three rules: reciprocity, self-inclusion, x-default.
- Listing a language in hreflang when the page has no counterpart is an error.
- The only thing that prevents translation debt is an automated check that fails the build.
First decide: which languages, and why
Languages are not free. Each one adds translation, editorial review, update synchronisation and measurement overhead. So the list should be built from data, not from "it would be nice to have".
| Signal | Where to look | What it tells you |
|---|---|---|
| Language split of current traffic | Analytics — browser language, country | An audience already arriving and not understanding |
| Search volume | Key terms in the target language | Whether a market exists |
| Source of sales | CRM / inbound enquiries | Which language the money comes from |
| Competitive picture | How many languages rivals run | A gap or an obligation |
| Operational capacity | Is there someone to reply in that language | Can you serve the demand |
That last row is the most-skipped and most expensive. If you open a Russian page and cannot answer an enquiry in Russian, what you have gained is disappointment.
URL strategy: three options, one usual answer
| Strategy | Example | Pro | Con |
|---|---|---|---|
| Subdirectory | site.com/en/services | Authority on one domain, simplest setup | Weaker geo-targeting |
| Subdomain | en.site.com/services | Separate hosting possible | Authority splits, setup more complex |
| Separate domain | site.co.uk | Strong local signal | Every domain builds authority from zero |
| Parameter | site.com?lang=en | — | Crawlability problems; do not use |
For the vast majority of corporate sites the answer is the subdirectory. A separate domain is only justifiable with a distinct legal entity, price list and team per country.
Translating the path segments too
If you chose subdirectories, one more decision follows: should path names be translated? On this site
they are — /tr/hizmetler, /en/services, /ru/services — because for a Turkish-speaking user a
Turkish URL is both more readable and a mild relevance signal.
// Pathname mapping with next-intl — the language switcher lands on the right counterpart
'/services': { tr: '/hizmetler', en: '/services', ru: '/services' },
'/projects': { tr: '/projeler', en: '/projects', ru: '/projects' },A caveat: translating individual project or service slugs is usually needless complexity. Translate
the segment (/services), keep the record identifier (/seo-geo) stable.
hreflang: three rules
hreflang tells a search engine "this page has counterparts in these languages". Set up wrong, it either does nothing or promotes the wrong language. Three rules are enough:
- Reciprocity. If page A points at B, B must point back at A. One-way tags are ignored.
- Self-inclusion. Every page must list its own language as well.
- x-default. Specify which version to use when no match applies.
<link rel="alternate" hrefLang="tr" href="https://site.com/tr/hizmetler" />
<link rel="alternate" hrefLang="en" href="https://site.com/en/services" />
<link rel="alternate" hrefLang="ru" href="https://site.com/ru/services" />
<link rel="alternate" hrefLang="x-default" href="https://site.com/tr/hizmetler" />On this site blog posts are matched through a translationKey field and hreflang is emitted only
for languages that genuinely exist. We covered the SEO counterpart of the same logic in
the SEO to GEO article.
Translation debt: this is where the cost lives
The real problem with multilingual sites is not the first translation but the second year. The Turkish page gets updated, the English one does not; a new service is added, its Russian version is forgotten. Six months later you have three different sites.
The fix is not complicated: a check that catches missing translations before they ship. On this
site pnpm content:check does exactly that — it compares 210 content fields across three languages
and exits with code 1 if anything is missing. That script is what found two missing translations the
first time it ran.
$ pnpm content:check
tr: works 49/49, stories 6/6, servicesList 15/15 ✓
en: works 49/49, stories 6/6, servicesList 15/15 ✓
ru: works 49/49, stories 6/6, servicesList 15/15 ✓
Total checked: 210 — Problems: 0Content model: what to translate
Translating everything is unnecessary and usually wrong.
The thing to watch on the blog side: a post does not need a counterpart in every language, but the
counterparts that do exist must be translations of one another. Matching different articles under
the same translationKey misinforms hreflang.
Seven common mistakes
- Automatic language redirection. Force-redirecting by browser language breaks both crawlers and users. Suggest a language; do not impose one.
- Using flags for languages. A flag represents a country, not a language. A German-speaking Austrian should not have to click a German flag.
- Translating only the home page. A site with untranslated inner pages is invisible in that language's search results.
- Not updating the
langattribute.<html lang="en">must change per language — accessibility tools and screen readers rely on it. - Forgetting to translate metadata. If title and description stay in Turkish, the page shows up in Turkish in search results even when the content is English.
- Hard-coding date, currency and number formats.
1.500,00 ₺and€1,500.00are not the same number; formatting must follow the locale. - A language switcher that dumps you on the home page. A user switching language on a service page should land on that same service in the new language.
The seventh needs pathname mapping in technical terms — on this site, switching language across the service pages keeps you on the same page.
Measurement: look per language
Total traffic is a misleading metric on a multilingual site. Each language is a separate market and should be reported separately.
Set a separate filter per language in Search Console and make language the primary segment in analytics. If one language converts at half the rate of another, the problem is either translation quality or offer fit in that market — looking at the total hides it.
An example
On Nexos Investment, multilingual support was not a layer added later
but part of the architecture: routing with next-intl, automated multilingual proposal generation
from listing data, and per-language content management in one system. The same need surfaces on real
estate projects aimed at international audiences, such as
Homes in Mediterranean and
Arslan Estates.
Conclusion
The hard part of a multilingual site is not translating it but keeping the translations in sync over time. A correct URL strategy, rule-compliant hreflang and a check that catches gaps at build time — with those three in place, a second and third language become extra markets rather than extra maintenance.
If you want to talk through how many languages to start with, write to us; we handle the technical side as part of our SEO & GEO service.
Frequently asked questions
- Subdirectory, subdomain or separate domain?
- For most corporate sites the subdirectory (site.com/en/, site.com/tr/) is right: it accumulates authority on one domain, is the simplest to set up, and makes hreflang least error-prone. Separate domains only make sense when each country has its own legal entity, its own pricing and its own team.
- Can I use machine translation?
- Publishing raw machine translation harms your visibility in that language; both search engines and language models can tell low-quality translation apart. The model that works is machine translation as a draft, reviewed by a native-speaking editor — noticeably cheaper than translating from scratch.
- Do I have to translate every page into every language?
- No, and usually you should not. Service, reference and contact pages should exist in every language; blog content can legitimately differ by language. What matters is not listing a language in hreflang when no counterpart exists — a tag pointing at a missing translation is an error.
- How do I know my hreflang is wrong?
- Three classic symptoms: language targeting errors in Search Console, the wrong language ranking for a query, and two languages cannibalising each other. The technical check is simple — every page must list all languages including itself, tags must be reciprocal, and an x-default must exist.
- How much upkeep does a multilingual site add?
- The real burden is not translation but synchronisation: a change made in one language that never reaches the others builds translation debt over time. The cheapest way to prevent it is a check script that reports missing translations as a build error.