Multilingual SEO architecture: subdirectories, subdomains, and standalone sites, plus hreflang
1. How authority flows across the three architectures
Multilingual architecture comes down to one question: how much of the authority you’ve built on your main domain carries over to a new language version. Google treats main domains, subdirectories, subdomains, and standalone domains differently.
| Architecture | Example | Authority flow | Maintenance cost | Best stage |
|---|---|---|---|---|
| Subdirectory | example.com/de/ | Inherits 100% of main domain authority | Lowest, one template | Most B2B companies |
| Subdomains | de.example.com | Partial, must be rebuilt | Medium, cookies/CDN need reconfiguring | Needs technical isolation |
| Standalone ccTLD | example.de | Starts from zero | Highest, backlinks and content duplicated | Strong local brand |
| Multiple gTLD sites | example-es.com | Starts from zero, no local signals | Highest | Not Recommended |
Subdirectories are the default answer because they put every language version under one domain, so the main domain’s backlinks, content depth, and crawl budget are all shared. Adding a German version doesn’t mean registering a new Search Console property or rebuilding backlinks; you just publish content under the /de/ path. For the multilingual launch process, see Multilingual Content Publishing Process.
2. Decision framework: choose by market stage and constraints
Don’t pick an architecture based on preference. Answer three questions. The order is: is the main domain mature, is there a need for technical isolation, and is local brand strength sufficient.
| Question | Yes | No |
|---|---|---|
| Has the main domain run for 2+ years with organic traffic? | Choose subdirectories | Build up the main domain first; no rush on multilingual |
| Does a market need its own payments/compliance/tech stack? | Use a subdomain for that market | Stick with subdirectories |
| Strong local brand recognition and yearly budget ≥200,000 RMB? | A standalone ccTLD is viable | Keep using subdirectories |
| Same language, different countries (English for US/UK/AU)? | Just add hreflang tags | No need for standalone sites |
Here’s a scenario: you run an industrial equipment company selling overseas. Your main English site has been live for 3 years, pulling in 8,000 organic visits a month, and now you want to add German and Spanish versions. The right move is example.com/de/ and example.com/es/ — within 6 months you can see German keywords break into the top 50. If you instead buy example.de and example.es from the start, just building up authority takes 12 to 18 months.
Another scenario: a Middle East market needs its own payment gateway and locally compliant hosting, and your main domain template can’t be modified. In that case, using the me.example.com subdomain is a reasonable trade-off. But accept that authority passes to subdomains at roughly 70 cents on the dollar compared with the German-speaking region.
The cost comparison is also worth running. A subdirectory setup costs almost nothing extra per year beyond translation and content production. A subdomain requires an additional SSL certificate, CDN cache rules, and a Search Console property — about 3 to 5 person-days of one-time setup. A standalone ccTLD means domain registration fees plus separate link building and a local content team, and first-year costs typically run 2 to 3 times those of the subdirectory approach. For budget-conscious B2B teams, run the numbers before you decide.
3. How Hreflang Differs Across the Three Architectures
Whichever architecture you choose, you must implement Hreflang — otherwise Google won’t know which version maps to which country and language. The rules are the same across all three; only the URL format changes.
| Architecture | hreflang example | Placement | Watch out for |
|---|---|---|---|
| Subdirectory | href=”https://example.com/de/” | head link 或 sitemap | Least error-prone |
| Subdomains | href=”https://de.example.com/” | Full URL across subdomains | SSL certificate must cover the subdomain |
| Independent Site | href=”https://example.de/” | Full URL across domains | Both sites must reference each other |
| x-default | href=”https://example.com/” | Required in every group | Points to the default English page |
There’s one hard rule: every hreflang group must reference both directions. The English page tags the German page, and the German page must tag the English page too — miss one side and the whole group fails. Use ISO 639-1 for language codes (de, fr) and ISO 3166-1 for country codes (de-DE, de-AT). German in Germany and German in Austria are different, so tag them separately. For the full syntax and common mistakes, see Hreflang for multilingual sites.
On WordPress sites using WPML or Polylang, the plugin outputs hreflang automatically — but the generated tags often miss x-default or lack bidirectional references. After launch, you must spot-check with the International Targeting report in Search Console. For tech stack selection, see crater Tech Stack.
A common dilemma: you already have a US version in English, so should you build a separate /en-gb/ for the UK? If the UK page just swaps dollars for pounds and American spellings for British ones, with everything else identical, don’t build a separate page — share /en/ and tag it with hreflang en-GB. Only when the UK has its own pricing, compliance, or case studies is a differentiated page worth building.
4. Migration and Common Mistakes
Picking the wrong architecture is expensive to undo, so here are the most common mistakes in one place.
| Mistake | Consequence | The right way |
|---|---|---|
| Buying a ccTLD for a new market right away | Ranking behind a subdirectory for the first 12 months | Test the market with a subdirectory first, then decide |
| Writing hreflang on only one side | The whole tag set stops working | Add reciprocal references and x-default to every set |
| No SSL on the subdomain | hreflang fetch fails | Cover every subdomain with the certificate |
| Building doorway pages by country | Triggers a manual action | Give every page real local content, see Build landing pages by country |
| Sharing one page across countries with the same language without annotation | Google shows the wrong version | Use en-GB/en-AU to tell them apart |
Moving from a subdirectory to a standalone site is the single biggest loss of authority you can take on. You need a 301 redirect map and a link rebuilding plan to go with it, and ranking swings for 4 to 8 weeks after the move are normal. For the migration method, see Site rebuilds and domain changes. Translation quality itself affects rankings too, so machine translation must go through post-editing, otherwise local users bounce and Google reads the content as low quality.
One last quick rule for choosing: if your team is one person or two marketers, pick a subdirectory without a second thought. If your engineering team explicitly says a market needs its own deployment, move up to a subdomain. Only consider a standalone site when local resellers or customers already search for you on a ccTLD and you are ready to fund a dedicated content team for that market. Once the architecture is set, leave the URLs alone for three years. Switching often hurts more than choosing wrong.
This call does not change with company size. Small teams should concentrate authority on one main domain, not spread it across several new domains.
FAQ
Subdirectory, subdomain, or standalone site: which one?
Does a .de domain get a natural ranking boost in German-speaking markets?
Do I need separate sites for the same language in different countries, like US, UK, and Australian English?
Why do subdomains lose link equity?
WPML for WordPress writes hreflang automatically. Do I still need to check it manually?
I already built a multilingual site with subdirectories. Can I switch to standalone sites later?
Final thoughts
Choosing a multilingual architecture is fundamentally a trade-off between link equity efficiency and localization needs. For every option other than subdirectories, you should be able to name a reason you absolutely must use it. Otherwise you are just adding maintenance overhead. For the vast majority of B2B going-global sites, subdirectories plus correct hreflang are enough.
Three steps to get started: this week, use Search Console to confirm your root domain is mature enough to expand into multiple languages; next week, pick an architecture for each new market using the decision tree, with subdirectories as the priority; within two weeks of launch, spot-check hreflang bidirectionality with the International Targeting report. For localizing charts and numbers in German and Spanish versions, see Charts and tables on multilingual sites.
One line to remember: get subdirectories right first for multilingual architecture. ccTLDs are for those who have already won their local market, not for those just going global who want to save time.