An international website needs a plan for the customers it will serve before it needs a new domain structure. A business entering another market may require different services, language, pricing, contact routes or support arrangements. Changing the address of the pages does not resolve those operational questions.
Country domains and subfolders are two ways to organise regional content. Either can be appropriate when the structure fits the business, publishing process and technical implementation. The useful comparison includes ongoing ownership and customer experience, rather than treating a domain suffix as a shortcut to international success.
Start by defining the markets and the differences they require. Then compare structures against those requirements, plan localisation and check that customers and search engines can reach the intended versions reliably.
Separate language from market
A language version and a country version are different concepts. A French-language page might serve several markets, while a Canadian website might need both French and English content. List the required language and market combinations before creating folders or registering domains.
Describe what changes for each combination. The differences might include service coverage, currency, examples, contact details and the team handling enquiries. Keep a simple matrix, so the website team can see which pages need translation, regional adaptation or a separate offer.
Do not create a regional page solely because the business wants to appear international. If the company cannot serve the market or maintain relevant content, the page can set expectations the operation cannot meet. Establish the delivery and support position first.
Identify the intended starting scale and likely expansion. A first launch into one additional market may need a manageable structure that can grow. Planning potential growth is useful, but it should not require building and maintaining versions the business has no immediate use for.
Compare the main structures
A country-specific domain can make the intended market apparent and support separation between regional sites. It also adds registration and operating work, and some country domains have eligibility requirements. Confirm the actual rules and availability with the relevant registry or registrar before choosing one.
Subfolders under a generic domain can keep regional content within one main site, such as an illustrative example.com/fr/ structure. They can support shared publishing and maintenance, although the organisation still needs clear regional routing and content ownership.
Country domains, subdomains and subdirectories have different operational trade-offs. There is no universal structural winner. Assess each option alongside the organisation's ability to maintain, measure and support the resulting sites. Our international SEO and structure guide provides the related checks.
Subdomains may also be worth assessing when regional systems or publishing arrangements differ. Compare the implementation your team proposes, including how updates, access and reporting will work. The visible URL pattern does not reveal every technical dependency.
Assess ownership and maintenance before the decision
For each option, identify who will publish, review and maintain the regional content. A shared site can simplify common updates, while separate regional sites can suit independent teams. Either arrangement becomes difficult when responsibilities are unclear.
List the recurring work: domain renewals, access management, content review, technical updates, link checking and service changes. Compare the whole operating arrangement rather than only the initial build quote. An affordable launch can still create an unmanageable maintenance burden.
Keep domain registration and technical administration under understood business control. A regional partner may help manage a site, but the organisation still needs to know who controls renewals, DNS and account recovery. Document the arrangement for each domain, so expansion does not create a set of assets nobody can reliably maintain.
Check the CMS's localisation capabilities through a demonstration. Ask an editor to update a shared service description, revise one regional variation and identify which versions need review. This exposes whether the system supports the actual publishing process.
Consider how a future change would be handled. If a service stops in one market or a team changes contact details, the business needs to update the right pages without unintentionally altering every version. Define the relationship between shared content and local overrides.
Localise the content and the customer journey
Translate with subject knowledge and review the result in context. Accurate words can still produce an unclear service description if the terminology or buying process differs in the market. Ask a suitable reviewer to assess meaning, examples and the practical next step.
Check every element a customer encounters, including navigation, forms, confirmation screens and automated messages. A translated page followed by an unrelated-language enquiry form breaks the journey. The receiving team should also understand which version generated the request.
Use relevant examples and evidence where available. A case study from another market may still be useful, but explain its context honestly. Do not invent a local office, local clients or delivery capability to make a page appear established.
Review market-specific purchasing and service information with the appropriate business owners. Address currencies, availability, fulfilment and relevant terms through verified decisions. The web team should implement those decisions rather than infer them from a translation file.
Give each maintained version a clear route
Plan stable URLs for the versions the business will maintain. Keep the naming convention understandable to editors and customers, and document whether a code represents a language, market or combination. Consistency makes later expansion easier to review.
Offer a clear way for visitors to choose a relevant version. Someone travelling, using a business network or researching another market may need a version different from an inferred location. Check that navigation does not trap them in a repeated redirect.
Where equivalent pages exist, consider linking the selector to the corresponding page rather than always sending visitors to another homepage. Define the fallback when an equivalent does not exist. A predictable fallback is better than a link that invents a destination.
Test direct links as well as homepage navigation. A customer may arrive through a shared article or search result. Important regional context and a route to change version should remain understandable without requiring them to start again.
Plan search annotations with the technical team
Hreflang can describe language and regional relationships between suitable alternate pages. Maintain self-references and reciprocal links to equivalent versions. Annotations should reflect available, maintained content rather than a speculative map of future pages. Our localised page and hreflang guide provides the related checks.
Choose an implementation the team can generate and validate consistently, whether in page markup, headers or a sitemap where appropriate. Keep a clear source of truth for the relationships. Manual annotations scattered across templates can drift as pages are added or removed.
Review canonical, indexing and redirect behaviour together with the alternate-page plan. These controls serve different purposes. A technical reviewer should check the combined result, so an intended regional page is not accidentally redirected away or excluded from discovery.
Inspect representative page groups after deployment. Confirm the expected URLs resolve, the content is correct and the version relationships remain accurate. Search annotations can assist interpretation, but they do not guarantee indexing or rankings.
Launch one manageable regional journey well
Create a release checklist covering content review, enquiry delivery, version selection, search configuration and operational ownership. Include mobile tasks and any external systems in the journey. A visually complete regional homepage is only one part of readiness.
Review the enquiries and questions that follow launch. Customers may reveal terminology or preparation details the initial plan missed. Use those findings to improve the regional content before multiplying the same weakness across further markets.
Giraffe Digital's digital strategy service considers websites, content and customer journeys. An international structure becomes a useful business asset when the domain decision is connected to maintainable local information and a working route to the right team.
Frequently asked questions
How should we separate language from market?
A language version and a country version are different concepts. A French-language page might serve several markets, while a Canadian website might need both French and English content. List the required language and market combinations before creating folders or registering domains. Describe what changes for each combination. The differences might include service coverage, currency, examples, contact details and the team handling enquiries. Keep a simple matrix, so the website team can see which pages need translation, regional adaptation or a separate offer. Do not create a regional page solely because the business wants to appear international. If the company cannot serve the market or maintain relevant content, the page can set expectations the operation cannot meet.
How should we assess ownership and maintenance before the decision?
For each option, identify who will publish, review and maintain the regional content. A shared site can simplify common updates, while separate regional sites can suit independent teams. Either arrangement becomes difficult when responsibilities are unclear. List the recurring work: domain renewals, access management, content review, technical updates, link checking and service changes. Compare the whole operating arrangement rather than only the initial build quote. An affordable launch can still create an unmanageable maintenance burden. Keep domain registration and technical administration under understood business control. A regional partner may help manage a site, but the organisation still needs to know who controls renewals, DNS and account recovery. Document the arrangement for each domain, so expansion does not create a set of assets nobody can reliably maintain.
How should we localise the content and the customer journey?
Translate with subject knowledge and review the result in context. Accurate words can still produce an unclear service description if the terminology or buying process differs in the market. Ask a suitable reviewer to assess meaning, examples and the practical next step. Check every element a customer encounters, including navigation, forms, confirmation screens and automated messages. A translated page followed by an unrelated-language enquiry form breaks the journey. The receiving team should also understand which version generated the request. Use relevant examples and evidence where available. A case study from another market may still be useful, but explain its context honestly. Do not invent a local office, local clients or delivery capability to make a page appear established.
How should we give each maintained version a clear route?
Plan stable URLs for the versions the business will maintain. Keep the naming convention understandable to editors and customers, and document whether a code represents a language, market or combination. Consistency makes later expansion easier to review. Offer a clear way for visitors to choose a relevant version. Someone travelling, using a business network or researching another market may need a version different from an inferred location. Check that navigation does not trap them in a repeated redirect. Where equivalent pages exist, consider linking the selector to the corresponding page rather than always sending visitors to another homepage. Define the fallback when an equivalent does not exist. A predictable fallback is better than a link that invents a destination.
How should we launch one manageable regional journey well?
Create a release checklist covering content review, enquiry delivery, version selection, search configuration and operational ownership. Include mobile tasks and any external systems in the journey. A visually complete regional homepage is only one part of readiness. Review the enquiries and questions that follow launch. Customers may reveal terminology or preparation details the initial plan missed. Use those findings to improve the regional content before multiplying the same weakness across further markets. Giraffe Digital's digital strategy service considers websites, content and customer journeys. An international structure becomes a useful business asset when the domain decision is connected to maintainable local information and a working route to the right team.
