Multilingual Websites: URL Structure, hreflang and Common Mistakes

Subfolders or subdomains, configuring hreflang without conflicts, handling the default language, and why machine translation hurts rankings.

Pavlo2 December 202510 min read

A company adds an English version, and a month later Search Console shows something strange: the original-language pages are being served to British visitors, the English ones to local visitors, and half the new URLs never made it into the index at all. Translation quality has nothing to do with it. The same three things break almost every time — URL structure, reciprocal hreflang tags, and a "helpful" redirect based on browser language. Here is how to choose an address structure, implement hreflang so it does not contradict itself, and what a second language really costs.

+20%

added to the build budget per language

2–8

weeks before a new version is fully indexed

100%

of pages need reciprocal hreflang tags

automatic redirects by browser language

Subfolders, subdomains or separate domains

You make this decision once and live with it for years — changing address structure later is a full migration with a temporary ranking dip attached. Decide it before design starts, not after launch.

Option	Example	Strength	What it costs you
Subfolders	site.com/en/, site.com/de/	All domain authority accumulates in one place	Effectively nothing — this is the default choice
Subdomains	en.site.com, de.site.com	Versions can live on separate servers and teams	Search signals build up separately for each one
Separate domains	site.co.uk, site.de	Strongest local signal, independent brand per market	Three sites instead of one: SSL, hosting, links, upkeep
URL parameter	site.com/page?lang=de	Quick to bolt onto a legacy site	Indexes badly, breaks caching and reporting — avoid

The fourth row is listed only so you recognise it in someone else’s proposal and decline.

Default to subfolders. Separate country domains are justified in exactly two cases: a legal entity per country, or markets so different they are effectively separate businesses. Subdomains are a compromise for organisations where each market has its own team. If you expect regional variants rather than plain languages — British versus American English — commit to /en-gb/ from the start. Adding a region to an existing /en/ later means a redirect on every page, which is a full site migration.

hreflang: what it really does, and how to not break it

hreflang does not affect rankings. It solves exactly one problem: once Google already has several versions of a page, it tells Google which one to show to a given user. The markup goes in the <head> of every language version of the same page:

<link rel="alternate" hreflang="en" href="https://site.com/en/services" />
<link rel="alternate" hreflang="de" href="https://site.com/de/services" />
<link rel="alternate" hreflang="de-at" href="https://site.com/de-at/services" />
<link rel="alternate" hreflang="x-default" href="https://site.com/en/services" />

<link rel="canonical" href="https://site.com/en/services" />

1Reciprocity is mandatory. If page A points at B, B must point back at A. One-way references are ignored entirely, not partially.
2Self-reference is mandatory too. Every page lists all versions including itself. Without it the cluster counts as incomplete.
3Absolute URLs only, with protocol and host. Relative paths do not work here.
4Codes are strict: language per ISO 639-1, region per ISO 3166-1, joined with a hyphen. en-gb, never en-uk (no such code) and never en_GB.
5hreflang must point at the canonical. If /en/services canonicalises to /en/service while hreflang references /en/services, the whole cluster is discarded.
6Pick one implementation. <head> tags, the XML sitemap or HTTP headers — one of them. Two in parallel will drift apart eventually, and they always do.

Default language and the automatic redirect trap

The most expensive mistake in multilingual projects is redirecting by IP address or the Accept-Language header. The logic looks considerate: German visitor detected, German page served. But Googlebot crawls predominantly from US addresses, so it only ever sees the English version and treats the rest as unreachable — one indexed language out of four, and months of confusion about why.

Offer, never force. Show a dismissible banner — "this page is available in German" — instead of a 302 redirect.
Remember the choice in a cookie and respect it. Someone who switched to English once should not see the banner again.
The switcher must lead to the same page in the other language. One that always dumps people on the home page is the most common UX failure here, and a direct cause of bounces.
The root `/` must resolve somewhere definite: a permanent 301 to the primary language, or a dedicated language-choice page. An empty root with a JavaScript redirect is invisible to crawlers.
Point `x-default` at the "everyone else" version — usually English or the choice page. With only two local languages and no international traffic expected, omitting it is fine.

Translation, localisation, and why raw machine output fails

Machine translation is not penalised as such — pages without value are. The real problem with auto-translation is subtler: it faithfully carries across your wording and completely misses the wording the new market actually searches with. A literal translation of a services page routinely produces a headline nobody types into a search box.

Translating a page is not localising it. Localisation starts where you rebuild the keyword set in the language of the market you are entering.

So the order is: a separate round of keyword research for the new language, then a page map built around that demand, then copy. Sometimes the English structure ends up differing from the original — some pages are redundant, others have to be added. That is normal, and far cheaper than translating pages nobody searches for. Machine output works as a first draft, provided a human rewrites the headings, subheadings and meta tags after it.

Localise these; do not translate them literally

Title and description — written for target-language demand, within length limits
URL slugs — meaningful in the target language, never a transliteration of the original
Currency, date format, thousands separator, phone input mask
Legal pages: privacy policy, payment terms, delivery and returns
Image alt text and any text baked into the images themselves
Structured data: names, prices, currency codes, area served
Interface copy: validation errors, form confirmations, automated email replies
Case studies and testimonials — a buyer in another market needs examples from that market

What a second language costs and how to avoid doubling upkeep

The real risk of going multilingual is not the launch budget. It is that you permanently double your editor’s workload. The only way out is architecture: one site with a language layer, not two sites sharing a domain.

1
One content model across all languages
In the CMS a page is one entity with language fields, not a separate tree per language. Otherwise the structures diverge within a year and you get pages that exist in one language only, with no hreflang counterpart.
2
Interface copy lives in dictionaries
Buttons, labels and error messages belong in translation files, never hardcoded in components. Adding a third language then means one new file instead of rewriting every template.
3
Generate the sitemap automatically
hreflang entries in sitemap.xml should be assembled from data at build time. A hand-written XML covering 200 pages across 3 languages goes out of sync with the very first publish.
4
Finish one language before opening the next
Launching both versions half-complete is worse than launching one properly. A second language full of empty pages drags down the perceived quality of the whole domain.
5
Run technical checks before allowing indexation
hreflang reciprocity, canonicals, no geo-redirects, a correct lang attribute on <html>. These are standard items in a technical SEO audit and far cheaper to fix before release.

Cost item	One-off	Ongoing
Language layer, routing, hreflang, sitemap	+15–25% of build cost	—
Translation and copy adaptation	$8–20 per 1,000 characters	Scales with news and case-study volume
Localising meta tags, slugs, structured data	$5–15 per page	—
Running two content versions	—	+30–50% of editor time

Benchmarks for a 20–40 page site; on large catalogues translation is priced per product record.

Frequently asked questions about multilingual websites

Subfolders or subdomains for language versions?

For most businesses the right answer is subfolders in the form site.com/en/. Domain authority, inbound links and technical configuration stay shared, and everything is administered in one place. Subdomains and country domains are justified only when each market runs through its own legal entity or its own team with a distinct catalogue and pricing.

Does a multilingual site count as duplicate content?

No. The same text in different languages is not duplication and carries no penalty. Problems only appear when the same language is duplicated across several addresses — for example English for the UK and the US with identical copy. That case is solved with correct region-coded hreflang tags and a canonical pointing to the primary version.

How long before a new language version brings traffic?

Indexation usually takes two to eight weeks, depending on domain authority and whether internal links point at the new section. First rankings on long-tail queries appear within two to three months, and meaningful traffic closer to six. An accurate sitemap, links from existing pages and a few external mentions in the new market all speed this up.

Can machine translation be published without editing?

Technically yes, and there is no outright prohibition, but the result rarely earns traffic. Automation translates your phrasing rather than the phrasing the market searches with, so headings and meta descriptions land beside actual demand. The workable compromise is machine output as a body-copy draft, plus human work on headings, meta tags and slugs.

What should the default language do on the home page?

The site root should either serve a specific language version via a permanent 301, or be a dedicated language-choice page. What it must not do is redirect on IP address or browser language, because crawlers request pages predominantly from one region and will never see the other versions. Language detection is acceptable only as a dismissible suggestion to switch.

In short

Subfolders are the default structure. Subdomains and country domains only make sense with separate entities or teams per market.
hreflang must be reciprocal, self-referencing, absolute, and implemented exactly one way.
Automatic redirects by IP or browser language hide most versions from crawlers. Offer the language in a banner and remember the choice.
A second language is not a translation — it is its own keyword set, meta tags, slugs and page structure.
Budget +15–25% on the build once, and +30–50% of editor time forever.

multilingual
hreflang
SEO

WebEngine