Country folders, subdomains or ccTLDs? An international SEO guide

Country folders, subdomains and ccTLDs each solve different international SEO and operating-model problems. Learn how to choose the structure that fits your markets, teams and platform.

Northstar Running is ready to launch in Germany. The team has three plausible options: example.com/de/, de.example.com or example.de.

Which one should it choose?

The answer affects more than rankings. It influences how German customers perceive the brand, who controls products and content, how releases are deployed, how local compliance is managed, how links and reporting are organised, and how difficult future changes may become.

International URL architecture should therefore be treated as an operating-model decision, not an SEO preference. Search engines can understand all three structures. The more important question is whether the structure matches the way the business actually operates.

The three international structures in plain English

Google documents country-specific domains, subdomains and subdirectories as valid approaches for multilingual and multi-regional websites. Each has different practical advantages and disadvantages, and Google does not present one as a universal winner. Its international SEO guidance explains the main options and signals.

Country folders, or subdirectories

A country folder places a market version inside the main domain:

• example.com/de/
• example.com/fr/
• example.com/es/

The German version is a path beneath the main website. The domain, platform and much of the infrastructure can remain shared. In URL terminology, the market identifier is part of the path rather than a separate hostname or top-level domain. RFC 3986 defines the general structure of URLs and their paths.

Subdomains

A subdomain places the local version on a different hostname under the same main domain:

• de.example.com
• fr.example.com
• es.example.com

This can give a regional team or application more technical separation without requiring a separate registrable domain for every country. It does not, by itself, create a separate legal company or guarantee that Google will treat the market as an entirely unrelated site.

Google says it has no general preference between subfolders and subdomains for crawling, indexing and ranking when they are crawlable and correctly managed. That is an important correction to the familiar claim that subdomains are automatically worse for SEO.

Country-code top-level domains

A country-code top-level domain, or ccTLD, uses a country-associated domain extension:

• example.de
• example.fr
• example.es

A ccTLD is a strong signal that the site is intended for a particular country. It also creates the clearest visible separation between markets. The extension does not prove that the business has local stock, suitable prices, local service or genuinely relevant content. Google lists ccTLDs as one of several geographic signals, alongside language, currency, addresses, phone numbers and local links.

What Google confirms, and what it does not

The evidence supports a more careful position than “folders always win” or “local domains always rank better”.

Google recognises several international structures. It also says that subfolders and subdomains do not have a general crawling, indexing or ranking preference when managed properly. The former Search Console country-targeting setting is no longer available, so older advice about assigning a country target to a folder should not be used as current implementation guidance. Google confirms that the International Targeting report and country-targeting feature were deprecated.

A ccTLD is a strong geographic clue, but Google’s SEO guidance describes the effect of top-level domains as generally low except where country targeting is relevant. That makes it difficult to defend a universal claim that .de will always rank better, earn more clicks or convert more visitors than /de/. The SEO Starter Guide provides the relevant context on top-level domains.

In practice, the domain structure is one part of a wider system. Local language, useful content, appropriate products, pricing, delivery, payment methods, customer support, local links and business information all matter. A German folder with translated English copy and no German fulfilment proposition is still a weak German experience.

Use one decision model, not one SEO slogan

Northstar’s three options should be compared against the questions that will affect the business after launch.

Country folders: central control with a shared foundation

example.com/de/ is often a sensible starting point when Northstar has one ecommerce platform, broadly shared products and a central marketing team.

The operational advantages are straightforward:

• One primary domain and platform can support several markets.
• Central teams can share templates, navigation patterns, analytics and publishing workflows.
• Adding a new market does not necessarily require buying and securing another registrable domain.
• Reporting can be easier to organise within a shared property and URL structure.

These are applied recommendations rather than Google ranking rules. They follow from the shared-host and central-management characteristics of a subdirectory model. Google’s comparison of international structures supports the underlying operational distinction.

The trade-off is that a shared foundation can become a shared constraint. If Germany needs different products, prices, fulfilment rules, compliance content or editorial approval, the folder may become a collection of exceptions inside a system designed for uniformity.

There is also a larger potential release blast radius. A change to a shared template, canonical rule, navigation component, tracking setup or CMS deployment may affect multiple markets at once. This is an operational inference, not a quantified Google finding. It makes release testing and market-level permissions important. Google’s documentation on canonicalisation and site moves reinforces the need to validate URL and page relationships when changes are made. See Google’s canonicalisation guidance.

Subdomains: separation without a new root domain

de.example.com may suit Northstar if the German operation has its own team, application or deployment process, while the parent company still wants a visible relationship with the main brand.

A subdomain can help separate regional content ownership, platforms or hosting environments, release schedules, access permissions and market-specific applications. This is an organisational and technical inference: the benefit depends on the company’s platform, access-control and release model.

That separation can reduce the chance that a German release changes the UK experience. It can also make it easier to give a regional team control over its own site without purchasing a new ccTLD.

But a subdomain is not a magic boundary. Google’s site-diversity documentation says subdomains are generally considered part of the same root-domain site for site-diversity purposes, although they may sometimes be treated separately. It would therefore be too strong to describe every subdomain as a completely unrelated website. Google explains this distinction in its site-diversity guidance.

The practical complications usually appear in governance and measurement. Teams need consistent internal linking, templates, canonicals, XML sitemaps and hreflang relationships across different hosts. Reporting also needs deliberate property ownership and aggregation.

There are web-platform considerations too. A subdomain is a different browser origin from the main domain. That can affect authentication, JavaScript access, local storage, cookies, consent and the continuity of a customer journey. MDN explains how the same-origin policy affects separate hostnames.

ccTLDs: the clearest market boundary

example.de gives German customers the most obvious country cue of the three options. It may be a strong fit when Northstar Germany has its own legal, commercial and operational identity.

A ccTLD can make sense when:

• the national business has its own products, pricing and fulfilment;
• local compliance and customer service are managed independently;
• the market has its own leadership, marketing budget and partnerships;
• customers strongly expect a local domain; or
• the business may eventually be sold, spun off or operated separately.

The cost is not simply the annual domain registration fee. Multiple country domains create more properties to secure, renew, monitor, redirect, report on and give access to. Depending on the country and corporate structure, there may also be registration restrictions, trustee requirements, infrastructure decisions or local legal obligations. These are potential obligations rather than requirements of every ccTLD. Google lists cost, availability, infrastructure and registration restrictions among the disadvantages of country-specific domains.

Separate domains also require a realistic link and authority plan. The phrase “link equity consolidation” is too blunt to decide the architecture. Search engines evaluate links, pages, relationships and relevance in context. There is no public rule saying that links to a main domain automatically transfer to every subdomain or ccTLD, nor that a folder always receives more value.

A better question is whether each market can earn and maintain the external references, useful content and internal connections it needs. Google identifies local links as one possible international signal, but it does not publish a universal number of links required for a market. Local links are discussed as one signal among several.

How the options compare in business terms

For Northstar, the choice should be tested against the following criteria.

• Local customer trust: a ccTLD provides the clearest country cue. A folder or subdomain can still be trusted when the language, pricing, delivery, payment methods, service information and brand experience are genuinely local. The extension alone is not proof of relevance. Research on localisation and trust is context-dependent; it does not establish a universal conversion advantage for one URL structure.
• Legal and market autonomy: folders are easiest to centralise. Subdomains can support separate teams or applications. ccTLDs create the clearest visible boundary, but do not legally establish independence by themselves.
• Content and merchandising: folders suit similar catalogues and shared editorial processes. Subdomains or ccTLDs become more defensible as products, prices, stock, compliance and content diverge.
• Platform and deployment ownership: a shared folder can simplify delivery but increase the impact of a faulty release. A subdomain can provide useful technical isolation. Separate domains may provide the strongest boundary, at the cost of more infrastructure.
• Reporting: folders can be simpler to aggregate and segment. Subdomains need careful Search Console and analytics governance. Separate ccTLDs remain separate domains, so global and market reporting must be deliberately combined.
• Link acquisition: every market needs a credible reason to be referenced. A shared domain may make central campaigns easier to organise, but it does not remove the need for locally relevant partnerships and content.
• Hreflang and cross-market governance: all three models need stable locale mappings and accurate relationships between equivalent pages. Hreflang can be implemented in HTML, HTTP headers or XML sitemaps, but it does not create local demand or fix unsuitable content. Google documents the supported hreflang methods and reciprocal page relationships.
• Release risk: shared systems can create a larger blast radius; separate systems can drift apart or miss updates. Neither model is automatically safer.
• Cost and future flexibility: folders usually minimise property overhead. Subdomains sit in the middle when teams need separation. ccTLDs may offer strategic flexibility for independent national businesses, but carry the highest ongoing administration.

Three business shapes and defensible choices

A centrally managed brand

Imagine Northstar sells the same running shoes across Europe, uses one ecommerce platform, sets most prices centrally and has a small local marketing team.

A country-folder model is likely to be defensible. It keeps the architecture close to the central operating model and avoids creating several separate technical properties before the business has the people or demand to manage them.

The decision should still be tested against local requirements. If Germany needs a different catalogue, payment system or returns process, “one platform” may describe the technology rather than the actual business.

Semi-independent regional operations

Now imagine Northstar gives European regional teams control over campaigns, editorial content and some merchandising. The teams use different applications but remain part of one corporate brand.

A subdomain may be reasonable if genuine deployment or platform separation is useful. A folder can also work if the platform supports strong market-level permissions, testing and governance.

The choice depends on the boundary the organisation needs. If the team only needs content ownership, a subdomain may add unnecessary measurement and cross-host complexity. If it needs a separate application and release process, that complexity may be justified.

Genuinely separate national businesses

Finally, imagine Northstar Germany has its own legal entity, warehouse, customer service team, product range, pricing, marketing budget and leadership. It may eventually be sold independently.

A ccTLD becomes more defensible here because the visible domain boundary reflects a real commercial boundary. It may support local recognition and make future separation clearer.

It is still not compulsory. A separate business can operate on a folder or subdomain. The point is that the extra domain cost and governance burden now have a business reason behind them.

Design the implementation before choosing the label

The architecture is only the visible part of the decision. Before launch, Northstar should define how the whole international system will work.

• Locale URL mapping: decide how every market and language version maps to a stable URL, including product, category, editorial and support pages.
• Internal linking: make sure users and crawlers can reach important local pages without relying on a country selector, JavaScript-only navigation or an automatic redirect.
• Canonical URLs: define which URL represents each page and prevent templates from accidentally pointing every market to one default version.
• XML sitemaps: decide whether sitemaps are separated by market, content type or property, and assign clear ownership for monitoring them.
• Hreflang: establish who maintains alternate-language and alternate-region relationships when pages are added, removed or changed.
• Redirects: map old and new URLs before launch, particularly if the decision changes an existing domain or URL structure.
• Analytics and consent: decide whether cross-market journeys should appear as one journey or separate market journeys. Separate root domains need deliberate cross-domain measurement; subdomains also require careful cookie, consent and tagging configuration. Google documents cross-domain measurement considerations.
• Search Console ownership: a Domain property can cover protocols, subdomains and paths under one domain, while separate ccTLDs remain separate domains. Google explains the difference between Domain and URL-prefix properties.
• Release validation: test templates, canonicals, internal links, sitemaps, structured data, tracking and hreflang across every market before and after deployment.

These controls help search engines discover and interpret the site, but they cannot compensate for weak translation, unsuitable products, poor pricing, missing payment methods, weak delivery or absent local support.

Before you choose: a practical checklist

Use these questions to force the architecture decision back into business reality:

• Are the markets centrally managed, semi-independent or genuinely separate businesses?
• Who owns content, merchandising, technical releases, analytics, domain security and incident response in each country?
• How different will products, pricing, fulfilment, compliance and customer support be over the next three to five years?
• Can the current CMS and ecommerce platform support stable locale mappings, market-specific canonicals, sitemaps, hreflang and internal linking?
• Would a shared deployment create an unacceptable release blast radius?
• Would separate properties create unacceptable governance drift or missed updates?
• Are the desired ccTLDs available and legally registrable by the business?
• Will customers move between markets, checkout domains or support properties?
• Do analytics, consent, authentication and cookie requirements support that journey?
• What reporting is needed: one global view, market-specific access or both?
• Can each market earn locally relevant links, reviews, partnerships and business references?
• Is a national business likely to be sold, spun off or independently operated later?
• Would changing the existing architecture introduce migration risk that the organisation can realistically test and validate?

If these questions have no clear owner, the business is not ready to choose a domain structure. It is still deciding how it intends to operate internationally.

So, which architecture should you choose?

Country folders are often a good fit for a centrally managed brand with shared products, platforms and workflows. Subdomains can be sensible when regional teams or applications need meaningful technical separation without creating a new registrable domain for every country. ccTLDs are defensible when national operations have genuine commercial, legal and operational autonomy, or when a clear independent market identity has strategic value.

None of those is a ranking guarantee. Google does not document a universal winner between folders and subdomains, and a ccTLD is not a substitute for local relevance. The strongest architecture is the one the business can govern accurately, support commercially and maintain consistently.

That is the practical test for Northstar: not which URL looks most international, but which structure lets the German operation deliver a credible German experience without creating more technical and organisational risk than the business can manage.

Liquid Silver can help businesses assess that decision across search signals, platform constraints, market autonomy and implementation risk, then turn the chosen model into a tested international SEO system.