For one brand with one editorial operation, we would usually start with language subfolders. They make a shared publishing process easier to maintain. A subdomain or separate domain becomes worth the added work when it reflects a real operational boundary, such as independent releases, teams or country businesses. None of these structures fixes weak translations or makes every page rank.
Decide whether you are separating languages or markets
Google distinguishes multilingual sites from sites aimed at different countries. A French translation may serve readers in several countries. Separate Canadian and French offers may need different local information even though both use French. Give each intended version a stable URL, and name its audience before choosing the host structure.
| Structure | A sensible fit | Work to account for |
|---|---|---|
| Language subfolders | One brand, shared CMS and shared release process | Locale routing, translated navigation, shared templates and language-specific publishing checks |
| Language or market subdomains | Separate apps or releases within a recognizable parent brand | DNS, certificates, cross-host navigation, monitoring and deployment ownership |
| Separate domains | Independent country businesses, brands or strong local-domain requirements | Domain renewals, separate site maintenance, links between versions and coordinated migrations |
That comparison is an operating recommendation. A subfolder can still run through a separate backend, and a subdomain can still share a CMS. Check what your actual platform supports before deciding that a URL shape requires an entirely new publishing stack.
Keep discovery and language mapping coherent
A separate domain does not prevent you from connecting translations. Google’s localized-version guidance permits alternates on different domains and requires complete URLs. Whichever structure you choose, maintain a page-to-page language map, including return links. A language selector should take a reader to the matching article when it exists, rather than silently substituting a vaguely related page.
- Write down the languages and any genuinely different country offers. Do not infer a country from a language alone.
- Confirm who owns translation, approval, deployment, analytics and incident response for each version.
- Check whether the CMS can publish and update a complete locale set without changing existing URLs.
- Use visible language navigation and keep language URLs stable. Avoid relying on a visitor’s cookie or automatic location redirect as the only way to reach a version.
For an existing blog, include the migration bill
We would keep a working structure unless a concrete constraint outweighs the move. Changing hosts or paths means mapping old article URLs to their new counterparts, preserving useful translations, updating internal links and language annotations, checking redirects and monitoring the destination pages. Budget for editors’ and developers’ time as well as domain and hosting charges.
For example, a company already publishing English and German articles in subfolders gains little from moving German to a new domain merely because that sounds more local. If its German subsidiary needs independent legal notices, offers and release control, the operational case is stronger. The decision starts with that requirement, then tests whether the existing platform can meet it.
Choose the smallest structure you can maintain well
Use a shared structure when the people, content and publishing workflow are shared. Split hosts or domains when the business needs a durable separation and can operate it. Before launch, test one complete translated article, its language switcher and its later update. That reveals more than a general claim that one URL pattern always wins.
