I would choose an international website structure by testing how the business will run it. Country domains, subdomains and subdirectories can all be legitimate options. The useful question is which arrangement fits the relationship between your markets, your teams and the service your customers actually receive.

This decision starts after the target markets have been chosen. It is about giving those markets a workable home, without assuming that an attractive URL will solve ownership or maintenance problems.

For a hypothetical company with a central product team and shared website management, language folders may be a practical starting point. For another company with independently operated country businesses, separate sites may deserve serious consideration. The difference is the operating model. Neither example establishes a universal ranking advantage.

Establish what a country version represents

Before discussing domains, I would ask what changes when someone moves between versions. Is it only the language? Does the product range change? Are customers dealing with another company, another support team or different delivery conditions?

A language and a market are not interchangeable. English content can serve readers in different places. A country can contain audiences who prefer different languages. If the structure treats those concepts as identical, the editorial and product teams may inherit decisions nobody intended to make.

Write down the relationship in ordinary language first. For example: this version presents the shared product in another language, while that version describes an offering managed by a separate local team. Only then choose the URL pattern that expresses it.

The exercise can expose an unresolved commercial question. If nobody can say whether a service is genuinely available in a market, a country label on the website will not settle the matter.

Understand the options without turning them into slogans

Google's documentation describes country-specific domains as a clear geographic signal, with additional infrastructure and possible registration constraints. It also recognises subdomains and subdirectories under generic domains as options. Subdirectories can simplify maintenance, while separate sites or subdomains can make separation easier. A URL alone may not make the intended country or language obvious.

Those are useful trade-offs. They are not a league table.

I would avoid a proposal that treats “folders share everything” or “local domains always win” as a complete argument. The recommendation needs to explain what will be shared, what will be independent and which constraints make that arrangement sensible for this business.

There is also a difference between a structure being technically possible and being affordable to operate well. A company may be able to launch separate websites without being able to keep their content, security, navigation and product information coherent.

Test the structure against an ordinary change

A practical way to compare options is to imagine a routine product change and follow it through the organisation. Who identifies the affected pages? Who approves the wording in each version? Who publishes the update? Who checks that the customer journey still works?

Suppose a hypothetical manufacturer changes the specification of a product sold across several markets. One local team controls its own site, while another depends on headquarters. Separate websites may reflect that reality, but the business still needs a reliable way to notify both teams and confirm the correction.

Now imagine a market-specific change instead. A service becomes unavailable in one territory while remaining available elsewhere. Can the local team make that distinction without altering the shared content for everyone?

I would use both situations when evaluating a proposed structure. Shared changes test coordination. Local exceptions test autonomy. A solution that handles one elegantly and makes the other unmanageable needs a clearer explanation of its limits.

Give customers a way to recover from the wrong version

A visitor can arrive on a version that is not the best fit. They may follow a shared link, return to a saved page or be comparing services across markets. I want the interface to help them choose the appropriate version without guessing their needs for them.

Google recommends separate URLs for language versions and advises against automatically redirecting visitors based on an assumed language. Its guidance also supports visible links that let users select another version.

My practical preference is for a selector that explains the choice. A country selector should describe markets; a language selector should describe languages. Combining them can work if the relationship remains understandable.

The destination matters too. Someone examining a particular product should not have to restart at a homepage when a matching page exists. Where no matching offer exists, the website should explain that honestly. A switch that silently changes the product or availability creates confusion precisely when the interface appears to be helping.

Decide which independence is actually needed

Local ownership can be valuable without requiring a separate domain. Conversely, a shared domain does not guarantee shared control. Editorial permissions, application architecture and business responsibilities need to be considered alongside the address structure.

I would ask local teams which decisions they need to make independently. The answer might concern campaigns, product descriptions, support information or release schedules. Each requires a different kind of flexibility.

This is where a concrete example helps more than a broad promise of “scalability”. Ask the proposed supplier to demonstrate how a local editor changes an offer while the central team retains control of the brand template. Then ask what happens when the shared template changes.

The aim is to identify the real boundary between central and local responsibility. If that boundary remains vague, the URL decision may simply conceal a disagreement that will reappear during publishing.

Record why the decision fits this business

I would finish with a short decision record: the chosen structure, the alternatives considered, the operational assumptions and the circumstances that would justify reviewing it. This protects the reasoning from being lost when people or suppliers change.

Include the cost of maintaining the arrangement, not just launching it. A structure that requires separate review processes or specialist development in every market should be assessed with those obligations visible.

There is no reason to redesign an established structure merely because another arrangement looks cleaner in a presentation. A change needs a concrete benefit that justifies its disruption and implementation work.

The structure I would favour is the one the business can explain to a customer and maintain through ordinary change. If both tests are satisfied, the architecture has earned its place in the plan. If either fails, a more elegant URL will not compensate for it.