When you build a multilingual site, the first decision is “where do the different languages live”: separate country-code domains, subdomains, or subdirectories? This choice directly affects authority accumulation, ops cost, and how hard hreflang is to implement — pick wrong and you’ll spend several times the effort fixing it later.
Many teams rush to register a pile of country-code domains, only to find each domain is a new site building authority from zero — a small team simply can’t feed them all. This article lays out the pros and cons of the three approaches, helping you pick the right starting point between cost and SEO. For the overall site-level planning, see the flat-navigation site architecture article.
The essential difference among the three approaches is where authority concentrates. ccTLD (country-code domain), subdomain, and subdirectory — authority concentration rises in that order. Small and mid-size sites should prefer subdirectories (/de/, /fr/) because authority concentrates on the main domain, making it easiest to build up. Whichever approach you choose, use hreflang to annotate the language/region versions against each other and avoid being judged as duplicates. And one often-overlooked point: don’t use pure JS redirects for language switching — give crawlers a crawlable, stable entry.
How to choose among the three URL approaches
ccTLD (like .de, .jp) has the strongest signal and highest local trust, but each domain is a standalone site that has to build authority from zero, plus local qualifications to obtain separately — high cost and ops overhead, suited to big sites genuinely investing heavily in multiple countries. Subdomains (de.site.com) are slightly weaker than the main domain but share a bit of it, with medium configuration.
Subdirectories (site.com/de/) put all authority onto the main domain, easiest for accumulating rankings, and the cheapest to operate — one site, one content set to manage. For the vast majority of small and mid-size sites, subdirectories are the best value, unless you have a clear local ops team and budget to support standalone domains.
How hreflang works with URLs
hreflang tells search engines “these URLs are different language versions of the same content,” preventing them from being treated as duplicates and letting the right-language page appear in the right region’s search results. It’s orthogonal to the URL approach: whether you use subdirectories or subdomains, hreflang still needs to be configured.
One hard rule: hreflang must be “mutually annotated” — if A annotates B, B must annotate A too, and each must include itself (with x-default pointing to the default version). Annotating only half gets ignored by search engines. The technical handbook has complete code examples for the details — copy them and you won’t go wrong.
Figure: Multilingual URL Strategy — Core Points (compiled by YunyingGO)
| Approach | Authority concentration | Best for |
|---|---|---|
| ccTLD | Lowest (each independent) | Heavy multi-country investment |
| Subdomain | Medium | Has regional teams |
| Subdirectory | Highest | Small/mid sites, starting out |
Why subdirectories are steadier
Subdirectories let all language versions share the main domain’s authority — new language pages borrow the main domain’s trust the moment they go live, indexing and rankings both faster. ccTLDs, by contrast, need the new domain to be recognized and trusted by search engines again, with a long cold-start period; even great content has to wait.
Subdirectories are also cheaper to operate: one CMS, one sitemap, one monitoring setup. Subdomains at least need per-site configuration; ccTLDs are multiple deployments. For multilingual projects with limited resources, saving that effort to invest in translation quality is far better value than spreading authority thin across multiple domains.
Don’t switch languages with JS redirects
A common mistake is using JS to detect the browser language and auto-redirect, where the redirected URL has no crawlable entry. Crawlers don’t execute that JS, so they stay stuck on the default-language page forever and the other language versions are never discovered. The switcher must be real links that crawlers can click into.
The right approach: place visible language-switch links on the page pointing to the corresponding subdirectory or subdomain URLs, so both crawlers and users can choose actively. Auto-detection can stay as an enhancement, but it can’t replace a crawlable static entry — otherwise the multilingual architecture leaks from the root.
How to verify multilingual configuration
After launch, submit each language version’s sitemap in GSC and check that each version’s indexing and display region match expectations. Then run an hreflang checker over it to confirm there are no “missing annotation” or “self-reference error” warnings — these issues can invalidate the entire annotation group.
Also spot-check which version appears in different regions’ search results: a German user should see /de/, not /fr/. Mismatches usually mean hreflang is written wrong or x-default isn’t set — go back and check the annotation rules one by one, rather than waiting until traffic goes abnormal to notice.
Where should x-default point
x-default is the “fallback version” in hreflang, for users who don’t match any specific language (like English users with unknown region). Common practice is pointing it at the site’s default-language homepage or language-selection page rather than a specific article, so mismatched users don’t get stranded in an unfamiliar language.
One pitfall: x-default must also be a real, accessible page that itself includes the full hreflang back-annotation. Many sites omit x-default, so when search engines can’t match, they randomly pick a language version to show — an experience that feels random, and traffic drifts along with it.
How to submit multilingual versions for indexing
Submit a separate sitemap per language version, or annotate them mutually in the sitemap with <xhtml:link rel=”alternate” hreflang=…>, so search engines get all the language relationships in one shot — steadier than relying on single-point discovery via on-page tags.
After submitting, check each language version’s indexing volume and display region in GSC, confirming German users really see /de/ rather than another version. When mismatches occur, check the hreflang syntax and x-default first, then whether the language-switch entry is crawlable — these are the two most frequent failure points.
Translation quality is the real bar
No matter how correct the technical setup, machine-translation smell won’t keep users, and high bounce rates drop rankings anyway. The real bar for a multilingual site is content quality: consistent terminology, natural local expression, and a native-speaker review when needed — don’t put machine translations live directly.
Same-topic versions across languages can be equivalent without being word-for-word translations; adapt wording and examples to local search habits so each version feels written for that locale. This works hand in hand with hreflang: the config handles “don’t judge as duplicate,” and quality handles “actually rank” — both lines need to be in place to be steady.
To get started, first decide the URL approach — small and mid-size sites prefer the /language/ subdirectory structure; configure mutually annotated hreflang for each language version with x-default included; make language switching real crawlable links instead of JS redirects. After launch, submit each language version’s sitemap separately, sweep the annotations with an hreflang tool, and spot-check search results in different regions to confirm versions match languages. Once this flow is done, the multilingual site’s technical skeleton stands — what remains is the competition of translation and content quality itself.
