URL architecture is the irreversible decision that frames every other choice in an international SEO program. Once a multinational site is in production with subdirectories, switching to ccTLDs is a 90-day migration with real visibility risk; once it's in production with ccTLDs, consolidating to subdirectories is the same. The right structure picked at launch saves years of cleanup; the wrong one becomes an architectural debt that compounds. This chapter covers the three patterns, the trade-offs, and the migration path when the early decision turns out wrong.

“The international URL architecture decision is the single most consequential one in the program. Hreflang is reversible in an afternoon; URL structure is reversible in a quarter, with risk. Pick the pattern that matches the operational model first, then optimize within it.”

The three patterns

• Subdirectories. example.com/es-mx/, example.com/en-au/. One domain, region-and-language directories. Authority consolidates; one Search Console property; one analytics; cheapest to operate.
• Subdomains. mx.example.com, au.example.com. One root domain, separate subdomains per region. Each subdomain is treated semi-independently by search engines (less than separate domains, more than separate folders). Authority partially shared.
• ccTLDs. example.com.mx, example.com.au, example.com. Separate top-level domain per country. Maximum local trust signal; zero authority sharing — each domain starts fresh.

Subdirectories — the default choice

Subdirectories are the right answer for most international sites. The reasoning:

• Authority consolidation. One domain holds all the backlinks. New region pages inherit the existing authority instead of starting from zero.
• Operational simplicity. One Search Console property covers all locales (filterable by directory). One analytics view shows all traffic. One CDN, one hosting setup.
• Cheapest hreflang. Same-domain alternates are simpler to verify and harder to break.
• Cleanest CMS integration. Most CMS platforms have first-class support for subdirectory localization.

The trade-off: less per-region trust signal than ccTLDs. For established global brands (Amazon, Apple, Stripe), this is irrelevant — the brand carries the trust. For new entrants in markets where local trust matters (financial services in some regions, healthcare), subdirectories may need to be supplemented with strong local link profile and on-page localization to compensate.

Subdomains — when teams operate independently

Subdomains earn their place when:

• Each region has its own product team, content team, and SEO team operating independently.
• The technical stack varies by region (different CMS, different hosting, different platform).
• Each region needs independent governance over deployments, infrastructure, and SEO standards.
• Risk isolation matters — a botched deploy on one region shouldn't take down the others.

Subdomains share some authority with the root but not all of it; Google treats them as related-but-separate properties. The operational cost is between subdirectories and ccTLDs — separate Search Console properties per subdomain, separate analytics views possible, separate technical audits often required.

ccTLDs — when local trust signal is decisive

Country-code top-level domains (example.com.mx, example.com.au) earn their place when:

• The market has strong "buy local" preference — users actively prefer .mx domains over .com.
• The brand is large enough to support per-country authority building (each domain starts at zero).
• Regulatory or trust requirements favor local domains (some financial services, government contracting).
• The brand can sustain the operational cost — separate Search Console properties, separate analytics, separate technical SEO audits, separate link-building programs per domain.

The cost: each domain has to earn its authority independently. A new example.com.mx with no link profile is a new domain to Google, regardless of how strong example.com is. Hreflang stitches them together but doesn't transfer authority.

Hybrid patterns

Some large multinational sites mix patterns:

• ccTLDs for top markets, subdirectories for the rest. example.com.au + example.com/es-mx + example.com/de — ccTLD where local presence is critical; subdirectory for regions where the operational cost would dominate the gain.
• Subdomain for major regions with independent ops, subdirectory for thinner markets. us.example.com + example.com/de + example.com/es — subdomain when the ops are independent; subdirectory when they're shared.

Hybrid is fine; the operational complexity multiplies. Each pattern adds to the Search Console-property count, the analytics-view count, the audit complexity. Hybrid is right when the regional differences justify it, wrong when it's an accident of historical decisions nobody cleaned up.

The "language only" mistake

A common architectural mistake: example.com/en/, example.com/es/, example.com/fr/ — language-only directories without region. This works for sites where the same Spanish content serves all Spanish-speaking markets (rare in practice), but fails when content needs to differ between es-MX and es-ES, or between en-US and en-GB. Once shipped, the migration to language-region (example.com/es-mx/) is a full URL migration.

The rule: if there's any chance the same language will need region-specific variants in the future, launch with language-region from the start. The cost of /es-mx/ over /es/ is zero today and saves a migration later.

The Search Console international targeting setting

For subdirectories and subdomains, Google's Search Console used to allow setting an international target per directory or subdomain. The setting was retired in 2023 — Google now uses hreflang and on-page signals instead. The implication: your URL architecture and hreflang are the geo signals; there's no admin-panel switch to override them.

For ccTLDs, the country code itself is the geo signal — example.com.mx is read as targeting Mexico without any additional configuration.

Migration patterns

When the early architectural decision turns out wrong, the migration follows three steps:

• Plan the redirect map. Every old URL maps to a new URL via 301. Document the entire mapping before any redirects go live. Test the mapping against the existing crawl.
• Update hreflang in the new structure. Pre-launch, the new hreflang on the new URLs needs to be ready. If the migration goes live with broken hreflang, the international visibility hit is severe.
• Monitor and retain. 301s stay in place for at least 12 months. Search Console crawl errors get watched daily for the first 30 days. Backlinks pointing at old URLs get refreshed where possible (high-value links worth the outreach effort).

Budget 30–90 days of reduced international visibility during the migration. The reindexing of every locale + the redirect chain processing both take time, and there's no shortcut. The chapter on website-architecture in the technical-SEO cluster covers migration risk management.

Picking the right pattern

• If you're operating a multi-region site with shared content, shared ops, and shared infrastructure: subdirectories.
• If each region has independent ops and risk-isolation matters: subdomains.
• If local trust is decisive, you have per-country teams, and the brand can carry per-domain authority building: ccTLDs.
• If you're in doubt: subdirectories. The default works for most sites.

With architecture set, the next chapter, translation vs localization, covers the content discipline that fills the URL structure with region-appropriate copy.