International E-commerce: Hreflang + ccTLDs vs Subdirectories

International ecommerce architecture decisions are the ones with the longest tail. The choice of ccTLD (example.fr) vs subdirectory (example.com/fr/) vs subdomain (fr.example.com) shapes your SEO ceiling in every market for as long as the site exists. Changing the architecture later is a multi-quarter migration project with real traffic risk.

Most ecommerce sites make this decision poorly — often defaulting to whatever the platform recommends or what the engineering team finds easiest. This article covers the framework for choosing, the trade-offs per option, and the hreflang + currency + content considerations that follow.

The three architectural patterns

Pattern 1: ccTLD (country-code top-level domain)

example.fr    — France
example.de    — Germany
example.es    — Spain
example.co.uk — UK

Pros:

• Strongest geo-targeting signal. Google's systems treat ccTLDs as explicitly country-targeted.
• Users trust them (French users expect .fr sites).
• Can run localized infrastructure (CDN, data, compliance) per market.

Cons:

• Each ccTLD builds authority separately. 5 ccTLDs split your global authority 5 ways.
• Operational overhead: 5 DNS setups, 5 SSL certs, 5 analytics properties.
• Expensive and slow to scale. Adding a 6th market is a from-scratch project.

Use when: large-scale international player with dedicated resources per market, or when local market trust (users prefer .fr) is a real purchase driver.

Pattern 2: Subdirectory

example.com/en-us/
example.com/fr-fr/
example.com/de-de/
example.com/es-es/

Pros:

• All authority consolidates on one domain. Backlinks to any locale strengthen all locales.
• Single infrastructure setup; simpler operations.
• Easy to add new locales (just new paths).
• Supports growth into new markets without major capex.

Cons:

• Weaker geo-targeting signal than ccTLDs. Mitigated via hreflang and GSC's International Targeting, but still weaker.
• User trust may be lower in markets where they prefer local TLDs.

Use when: mid-size international player optimizing for operational efficiency and authority consolidation. Default choice for most B2C ecommerce in 2026.

Pattern 3: Subdomain

fr.example.com
de.example.com

Pros:

• Some isolation between locales (separate infrastructure possible).
• Can use different CMS per subdomain.

Cons:

• Middle ground between ccTLD and subdirectory — often gets the worst of both.
• Each subdomain builds authority somewhat separately (Google treats subdomains as related but not identical).
• Users don't parse subdomains as cleanly as path segments.

Use when: rarely. Usually chosen for technical reasons (separate deployments, separate teams) rather than SEO. Most sites should prefer subdirectory or ccTLD.

The decision framework

Three questions:

1. How many markets are you targeting?

• 1-2 markets: Subdirectory is usually enough. ccTLD if market trust critical.
• 3-5 markets: Subdirectory unless you have enterprise-level resources.
• 5-15 markets: Subdirectory almost always. The consolidation beats the per-market boost.
• 15+ markets: Subdirectory is the only practical choice at scale.

2. Is local trust a purchase factor?

In some markets, users strongly prefer local domains. Research:

• Germany: high .de trust. Mittelstand consumers particularly value .de.
• France: mixed. Large brands get away with example.com/fr/; smaller brands may benefit from .fr.
• UK: mostly indifferent. .co.uk and .com/uk/ both trusted.
• US: mostly indifferent. .com is default.
• Japan: high .jp preference.

If purchase completion hinges on local trust, lean ccTLD.

3. What's your capex/operational capacity?

• Lean team, shared resources: subdirectory.
• Dedicated market teams, separate localization pipelines: ccTLD viable.

Hreflang for ecommerce

Once architecture is decided, hreflang declares the relationship between locale URLs. Covered in depth in hreflang-implementation, but ecommerce-specific considerations:

Sitemap-delivered (scales best for large catalogs)

For catalogs past 10,000 products, inline hreflang <link> tags balloon templates. Sitemap-delivered is the only sane option:

<url>
  <loc>https://example.com/fr-fr/product/shoe-1</loc>
  <xhtml:link rel="alternate" hreflang="fr-fr" href="https://example.com/fr-fr/product/shoe-1"/>
  <xhtml:link rel="alternate" hreflang="es-es" href="https://example.com/es-es/producto/zapato-1"/>
  <xhtml:link rel="alternate" hreflang="en-us" href="https://example.com/en-us/product/shoe-1"/>
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en-us/product/shoe-1"/>
</url>

Critical bidirectionality

Each locale URL must reference all other locale alternates, including itself. Bidirectionality breaks when:

• URLs change in one locale without propagating to others (e.g., a product slug update in Spanish not reflected in the French alternate).
• Products discontinue in some locales but not all. The locale where it's gone still needs to either remove the hreflang entry or redirect.

Automated validation in CI is the only way to keep this working at ecommerce scale.

x-default for ecommerce

Point to either the English (typically US) version OR a dedicated /international/ landing page with language selector. For users outside all declared markets, this is what shows.

Currency handling

Separate from architecture, currency affects user trust and conversion:

Option 1: JavaScript currency swap based on geo-IP

User sees EUR in Spain, GBP in UK, USD in US — all on the same URL. Prices are formatted client-side.

Pros: single URL per product, consolidated signals, simple architecture. Cons: JS-dependent; Googlebot might see default currency only; currency conversions can confuse users when they cross borders.

Option 2: Separate URLs per currency

/fr-fr/product?currency=EUR vs /fr-fr/product?currency=USD. Canonical the currency variants to the default currency for that locale.

Pros: clean indexation (canonical handles duplicates). Cons: parameter noise; most sites don't need currency variants beyond the locale's native one.

Option 3: Currency per locale, no swap

French market shows EUR only. UK market shows GBP only. Germany shows EUR. No runtime switching.

Pros: simplest, cleanest. Each URL shows the correct currency for its locale. Cons: travelers or multi-locale buyers can't easily compare.

Option 3 is the default for most ecommerce. Option 1 adds complexity with limited benefit.

Localized content (not just translated)

Hreflang + a translated URL isn't enough. Locales need genuinely localized content:

• Product descriptions: translation is baseline; localization (references, units, size conversions) is better. A "12-inch pizza" translated to German as "12-Zoll Pizza" is technically correct but jarring — "30 cm Pizza" reads natural.
• Pricing: local currency, local format (€1.299,00 in German; €1,299.00 in British English; €1 299,00 in French).
• Shipping and returns: locale-specific policies, shipping timeframes, return procedures.
• Legal: GDPR-specific for EU locales; different privacy/terms per region.
• Payment methods: iDEAL for Netherlands, SEPA for EU generally, PayPal universally, local cards everywhere.

Machine-translated product descriptions with no localization adjustments produce near-duplicate content across locales from Google's perspective. Real localization differentiates.

Geo-targeting via GSC

Beyond URL architecture, Google Search Console's International Targeting lets you explicitly target subdirectories to countries:

• example.com/fr/ → targeted to France.
• example.com/es/ → targeted to Spain.

Only applies to subdirectory-based international structures (not ccTLDs; those are targeted by their TLD). Deprecated in mid-2022 and replaced by hreflang signals, but still available for subdirectory sites that need explicit geo-targeting.

Common mistakes

Same content across locales, different URL, no localization. Translation without adaptation. Google treats as near-duplicate; hreflang gets ignored.

Hreflang pointing to redirects. If a product URL changes and the hreflang still points at the old URL (which now 301s), the signal weakens. Update hreflang when URLs change.

Mixing ccTLDs and subdirectories. example.fr + example.com/es/ — inconsistent, confusing. Pick one pattern.

Not canonicalizing default locale variants. If a user in France hits example.com/ (English default) vs example.com/fr/ (French), both should be self-canonical to themselves, not one canonicaled to the other.

Blocking cross-locale access. Geo-blocking where French users literally can't reach the UK site because of IP-based redirect. If Googlebot (US-based) can't reach the French site, it can't index it. Use Vary: Accept-Language and don't hard-redirect bots.

Deep paginated URLs included in per-locale sitemaps. Sitemap bloat per locale multiplies the maintenance burden. Only include canonical, indexable URLs per locale.

Frequently asked questions

Should I translate my blog content for every locale?

Depends on SEO value. Translating evergreen pillar content to 5 languages is cost-effective; translating 200 blog posts to 5 languages is not. Prioritize high-traffic, high-commercial-intent content for translation.

How do I handle currency for users outside my declared locales?

x-default hreflang points to a default URL (typically USD or EUR). The default URL shows the default currency. Display a "your currency?" prompt if the user's geo-IP suggests they'd prefer something different.

Can I use hreflang between ccTLD and subdirectory?

Yes. example.fr can be the fr-fr alternate of example.com/en-us/. Just ensure bidirectionality.

What if I can't add hreflang (platform limitation)?

Sitemap-delivered hreflang usually works even on platforms that don't support inline <link> tags. Generate the sitemap externally if needed. Without hreflang at all, you're leaking signal between locales.

Do I need hreflang if my locales use different URLs entirely?

Still yes. Different URLs + same products + multilingual users = hreflang territory. Google tries to show the right locale to the right user; hreflang is how you tell it.

What to read next

• E-commerce SEO Playbook — international strategy in the broader ecommerce picture.
• Hreflang implementation — detailed technical implementation.
• Canonical tag for ecommerce — canonical + hreflang interaction.