Choose a structure from ownership and audience needs
An international URL structure is a long-term publishing and operating decision. Start with the languages and markets the organisation can support, the teams responsible for them and the infrastructure they need. A folder pattern that looks tidy on a slide may fail if regional teams cannot publish safely or keep shared resources consistent.
Document constraints before comparing options: domain ownership, local registration requirements, authentication, legal separation, release cadence, analytics access and existing inbound addresses. Distinguish genuine requirements from preferences inherited from an earlier platform. Estimate the cost of maintaining certificates, redirects, monitoring and content relationships across each proposed boundary.
The structure should give each intended edition a stable, shareable address and preserve a clear user choice. It does not establish language simply by containing a code. Use the international SEO audience model to decide which editions exist before deciding whether they belong on country domains, subdomains or subdirectories.
Assess country domains as an explicit regional commitment
A country-code domain such as example.de provides a geographical signal and clear operational separation. It may suit a business with an established German entity, independent catalogue and dedicated local ownership. It is less suitable as a generic container for all German speakers when the intention is not country-specific.
Account for registration restrictions, availability and the ongoing cost of operating several sites. Domains need certificate management, renewal ownership, security controls, monitoring and coordinated migrations. A regional team can gain autonomy, but a shared product identifier or translation registry still needs to cross that boundary if pages are to form useful alternate relationships.
Google treats some country-code domains as generic, so verify the status of the actual domain rather than assuming every two-letter ending provides the same geographical signal. Do not choose a new domain solely on a presumed ranking advantage. Compare business clarity and sustainable ownership against the work required to maintain another public host over the site's expected lifetime.
Use subdomains where the infrastructure boundary helps
A subdomain such as de.example.com can separate applications or publishing teams while retaining a common parent domain. That may suit regional platforms with different release schedules, support tooling or catalogue systems. The label de is ambiguous by itself: it could mean German language or Germany, so document the meaning explicitly.
Operational separation brings additional checks. Inspect each host's robots file, certificates, caching, access policies and response reliability. A global template fix may never reach a regional application owned by another team. Search reporting and analytics permissions should reflect the actual host boundary so a monitoring gap does not conceal a local publishing failure.
A subdomain is not a shortcut to automatic audience selection. Maintain appropriate content, explicit language relationships and usable links. Compare the cost of independent deployment with the coordination required for shared resources. If every release still requires synchronised changes across all hosts, the apparent independence may offer less practical benefit than a simpler directory-based structure.
Evaluate subdirectories for shared publishing systems
Subdirectories such as example.com/fr/ or example.com/en-ca/ often fit a shared application with central routing and common deployment controls. They can simplify host management and make central publication checks easier. Their success depends on clear route ownership and reliable locale data, rather than the directory syntax itself.
Decide whether each prefix represents a language, a market or a combined locale. Avoid using /fr/ to mean France in one part of the platform and generic French elsewhere. If French for Canada needs different conditions, give that edition a distinct supported identity and document how the generic French edition relates to it.
Shared infrastructure also shares failure modes. A routing expression, canonical helper or cache key can affect every language at once. Require template fixtures from several locales and include non-ASCII slugs, missing translations and regional availability exceptions. A directory system is maintainable when the publishing model is explicit, not when developers infer the locale from arbitrary string positions throughout the codebase.
Define route and fallback behaviour for real visitors
Prefer distinct stable URLs for language editions rather than relying on cookies or browser preferences to change the main content at one address. Locale parameters can identify content, but Google does not recommend parameter-based regional segmentation as the standard structure. Consider migration and application constraints before replacing an established working system simply for aesthetics.
Translated words in paths are acceptable. Choose a consistent encoding and escaping policy, and avoid treating visually similar Unicode strings as interchangeable without checking their actual routes. Keep stable content identifiers behind the route model so a translated slug change does not break the relationship with other editions.
Define missing-resource behaviour separately from missing-language behaviour. A visitor requesting a retired French guide may need a genuine replacement or a useful error, rather than an automatic jump to the English homepage. The hreflang guide explains alternate mapping; visible selectors should preserve resource context where an equivalent exists and label broader destinations accurately.
Compare options with evidence and competing hypotheses
Collect an evidence checklist before approving change: current URL inventory, business locale matrix, host ownership, publication permissions, release dependencies, access rules, response performance, duplicate routes, canonical policy, alternate coverage and migration capacity. Review real resource journeys rather than only homepages. Include a new translation, a discontinued product and a renamed article.
Test competing explanations for any current performance concern. Regional visibility might reflect untranslated content or poor service suitability rather than the use of subdirectories. Slow delivery could come from uncached application work rather than a distant server alone. A failed language launch may originate in forced redirects rather than the domain format.
Do not treat changing URL architecture as the default remedy for unexplained search differences. Verify the defect a proposed move is expected to resolve. The international audit method provides a way to separate routing, content and annotation failures before taking on the cost and processing uncertainty of a migration.
Illustrative worked example: shared platform with regional autonomy
Illustrative worked example: a fictional parts supplier operates one catalogue and payment platform, with local editors in Britain, France and Canada. Management considers separate country domains because regional pages receive different search traffic. An audit finds that French product descriptions are incomplete and Canadian delivery rules are hidden behind a cookie.
The competing explanations are URL structure and incomplete audience delivery. Requests without cookies show the same British conditions at the Canadian address, while French pages contain English specifications. Moving domains would not repair either defect. The proposed design retains locale subdirectories, completes the French content and gives Canadian conditions a stable direct URL.
Regional editors receive scoped publication permissions, while a central registry maintains equivalent product relationships. Acceptance tests cover direct requests, local availability and translated content across representative products. These fictional decisions illustrate how evidence can support keeping a structure. They are not a claim that subdirectories universally outperform domains or that the proposed changes would guarantee search growth.
Treat an address change as a controlled migration
If the evidence supports changing addresses, build a resource-level old-to-new map for each locale. Preserve meaningful language and market destinations; do not redirect every retired regional URL to one global homepage. Update internal links, canonical declarations, alternate relationships and sitemap inventories in coordination with the routing change.
Use website migration checks to prepare redirects, access and monitoring. Google recommends server-side permanent redirects where appropriate and retaining them for at least a year, with longer retention useful for visitors and old references. A domain move also needs the relevant Search Console property and Change of Address considerations; a path-only move has different requirements.
Acceptance should name the expected final destination for every mapped resource and test a representative set of edge cases before launch. Check request chains, query handling, unpublished destinations and cross-locale mistakes. Record removed resources without replacements explicitly rather than forcing them into an irrelevant redirect merely to avoid an error response.
Set launch gates, rollback controls and review limits
Launch gates should require stable URLs, clear locale semantics, correct local content, successful direct access and consistent metadata. Test language changes without cookies, hosts with independent infrastructure and cache behaviour after publication. Verify that intended editors can update their own content without accidentally changing another region's routing or service details.
Rollback risks include redirect loops, duplicate live structures and links generated from mixed route registries. Retain old routing configuration and a versioned mapping, but plan how new content published after launch will remain reachable. Reversing DNS alone cannot restore canonical, alternate and sitemap consistency. Use the migration monitoring workflow to detect those mismatches promptly.
No structure guarantees rankings, complete crawling or indexing. A move can create temporary search fluctuations and ongoing operational costs. Review the chosen structure when business boundaries or platform ownership change, using evidence from actual publishing and user journeys. Stability is valuable when the existing model remains understandable, accessible and maintainable.
Frequently asked questions
Are subdirectories always the best choice?
No. They often suit a shared platform, but country domains or subdomains may fit genuine ownership and infrastructure boundaries. Compare the audience model, maintenance costs, publication autonomy and migration risk. No format supplies a universal ranking advantage regardless of implementation and content.
Does a country domain target everyone speaking that language?
A country domain expresses a geographical association, which differs from language. German speakers live in several countries, and Canadian audiences may need English or French. Model market and language separately and verify how Google treats the specific top-level domain.
Should translated slugs match the original wording?
They can use appropriate local words. Maintain consistent encoding and reliable content identifiers behind the routes so translated renames do not break equivalent-page mappings. Clear user-facing addresses and robust implementation matter more than forcing every language to use an identical slug.
Is changing folders a minor SEO update?
It changes published addresses and needs migration controls: resource mappings, suitable redirects, updated internal references, canonical preferences and alternate relationships. Test the final delivered routes and plan monitoring and rollback. A visually small path change can affect many independent publishing systems.