International URL Structure

For general URL conventions (slugs, hyphens, path depth), see URL Structure. This article covers the higher-level decision of how to organise an international site across domains.

The URL structure you choose for an international site is one of the most consequential technical decisions in any international SEO strategy. It determines how Google understands your regional targeting, whether link equity is consolidated or fragmented across your properties, and how much maintenance overhead you take on as you add markets.

The four options

Country-code top-level domains (ccTLDs)

Each country gets its own domain: example.co.uk for the UK, example.de for Germany, example.fr for France. Google describes ccTLDs as providing “a strong signal to both users and search engines that your site is explicitly intended for a certain country”.¹ This is the strongest geo-targeting signal available, and no additional configuration is needed.

One important exception before you buy a domain on this basis. Not every country-code domain counts as a country signal: Google states that “we also treat some vanity ccTLDs (such as .tv and .me) as gTLDs, as we’ve found that users and website owners frequently see these as being more generic than country-targeted”.¹ The list runs to around twenty and includes several domains commonly bought for branding rather than geography: .ad, .ai, .as, .bz, .cc, .cd, .co, .dj, .fm, .io, .la, .me, .ms, .nu, .sc, .sr, .su, .tv, .tk and .ws, with .eu and .asia treated as generic regional domains.¹ A .io or .co domain buys you no automatic country association at all.

Note also Google’s stated limit on the approach: a ccTLD “can only target a single country”,¹ which makes it a poor fit where one language serves several markets.

The tradeoff is authority. Each ccTLD is a separate domain, which means a separate crawl budget, a separate link profile, and a separate Search Console property. A backlink to example.co.uk does not benefit example.de. For businesses entering a new market, starting from zero authority on a new ccTLD is a significant disadvantage against established local competitors.

ccTLDs make sense when:

• Legal or regulatory requirements mandate a distinct local domain
• The brand operates under genuinely different names or identities in each country
• The business can sustain separate SEO programmes for each domain

Subdomains

Each market gets a subdomain: uk.example.com, de.example.com. Google treats subdomains as separate properties and each can be set up as a distinct Search Console property, but they do not receive the automatic country association that ccTLDs do. With the International Targeting setting removed in 2022,² geo-targeting for subdomains rests on the other signals Google reads automatically, chiefly hreflang, the visible language of the content, and the market signals covered below.

Link equity does not consolidate across subdomains as effectively as it does with subdirectories. Links pointing to de.example.com primarily benefit that property, not the root domain.

For most sites, subdomains offer no SEO advantage over subdirectories at higher operational cost, which is the honest summary. They are not without merit, though, and it is worth naming the one real edge: Google’s own comparison lists “allows different server locations” among the subdomain pros, against “single server location” as a subdirectory con.¹ Since Google also names server location among its geotargeting signals, that is a genuine, if minor, international advantage. Subdomains are a reasonable choice where technical or organisational constraints make subdirectories impractical.

Subdirectories

All markets live under a single domain: example.com/uk/, example.com/de/. This is the recommended approach for most sites.

Advantages:

• Link equity accumulates on a single domain. A link to any page on example.com benefits every international variant.
• A single domain means one hosting setup, one SSL certificate, and one primary Search Console property.
• Lower operational overhead as markets scale.

The main disadvantage is a weaker automatic geo-targeting signal compared to ccTLDs, mitigated by implementing hreflang correctly and by the other market signals below.

URL parameters

example.com/?lang=de or example.com/?country=uk. Google marks this approach “not recommended”,¹ and it should be avoided for all new builds. Google’s stated objections are that URL-based segmentation becomes difficult and that “users might not recognize geotargeting from the URL alone”.¹ In practice the URLs are also poor for sharing and analysis. If you encounter an existing site using parameters for internationalisation, migrating to subdirectories is a worthwhile investment.

What geotargeting signals does Google actually use?

Since the manual Search Console setting is gone, it is worth knowing what remains. Google documents four groups of signals for determining a page’s target locale:¹

• ccTLDs, subject to the vanity-domain exception above.
• hreflang statements, “whether in tags, headers, or sitemaps”.
• Server location, via the server’s IP address, which Google qualifies: some sites use CDNs or host abroad, “so it is not a definitive signal”.
• Other signals, including “local addresses and phone numbers on the pages, the use of local language and currency, links from other local sites, or signals from your Business Profile (where available)”.

Two clarifications worth carrying. Language is determined from what a reader sees, not from your markup: “Google uses the visible content of your page to determine its language. We don’t use any code-level language information such as lang attributes, or the URL.”¹ And there is no markup shortcut here, since Google “ignores locational meta tags (like geo.position or distribution) or geotargeting HTML attributes”.¹

So URL structure is one input among several. A subdirectory site with genuinely localised content, local currency, local contact details and local links is sending several of these signals at once; the URL alone was never doing the work.

Don’t redirect users automatically

Whichever structure you choose, the most common way it gets broken in practice is automatic redirection based on a guess about the visitor.

Google’s guidance is explicit: “avoid automatically redirecting users from one language version of a site to a different language version of a site. For example, don’t redirect based on what you think the user’s language may be. These redirections could prevent users (and search engines) from viewing all the versions of your site.”¹ On the IP-based version specifically it raises a caution: “don’t use IP analysis to adapt your content. IP location analysis is difficult and generally not reliable. Furthermore, Google may not be able to crawl variations of your site properly.”¹

The mechanism is worth understanding, because it explains why the failure is often invisible. Google notes that “most, but not all, Google crawls originate from the US”, and that “the crawler sends HTTP requests without setting Accept-Language in the request header”.¹ A site that redirects US visitors to /en-us/ will therefore tend to show Googlebot that version and little else, and header-based language switching fails the same way, since there is no header to read. Google states plainly that it does “not attempt to vary the crawler source used for a single site in order to find any possible variations in a page”.¹

The workable pattern is to give every version its own URL, let users land where they asked to land, and offer a visible way to switch. Google’s own recommendation is “using different URLs for each language version of a page rather than using cookies or browser settings to adjust the content language on the page”,¹ and it suggests “adding hyperlinks to other language versions of a page”.¹ A banner suggesting a different version is fine; a forced redirect is not.

How do you choose the right international URL structure?

For most organisations: use subdirectories. The link equity benefit is significant, especially for sites in competitive markets where accumulating authority takes years. Consolidating that authority on a single domain rather than splitting it across multiple ccTLDs makes each individual page more competitive.

Use ccTLDs when distinct local domains are genuinely required: by legal structure, by brand architecture, or by compliance. Not because they feel more local to your audience.

URL structure and hreflang

Whichever URL structure you choose, it must be implemented consistently before hreflang annotations are added. Hreflang references specific URLs; if those URLs later change (for example, from subdomains to subdirectories), all hreflang annotations need updating simultaneously. Retrofitting a URL migration and a hreflang update at the same time increases the risk of errors considerably.

URL naming conventions

When using subdirectories, there are two main conventions:

Country codes: /uk/, /de/, /fr/. Clear for regional targeting. Use when one language per country.

Language codes: /en/, /de/, /fr/. Better when one language serves multiple countries (English for the UK, Australia, and Canada). Combine with hreflang to specify regional targeting.

Combined codes: /en-gb/, /de-de/, /fr-fr/. Most explicit; best for large sites with both language and regional variants.

How do you migrate between international URL structures?

Changing international URL structure is one of the harder SEO migrations to execute cleanly; treat the initial choice as a long-term commitment. Changing from one URL structure to another is a significant migration with real ranking risk. If moving from subdomains or URL parameters to subdirectories:

1. Set up the new URL structure and test it before redirecting any traffic.
2. Implement 301 redirects from every old URL to its new equivalent.
3. Update hreflang annotations to use the new URLs.
4. Update the XML sitemap.
5. Update internal links throughout the site.
6. Monitor Search Console for crawl errors and ranking changes for several weeks after migration.

Frequently asked questions

Can I mix URL structures across markets?
Technically yes, but it creates maintenance complexity and makes hreflang harder to implement correctly. Consistency across all markets is strongly preferable. Note that hreflang itself is not the obstacle: Google states that alternate URLs “do not need to be in the same domain”,³ so a ccTLD in one market and a subdirectory in another can still be annotated as versions of each other.

Does URL structure affect whether I appear in AI answers?
There is no evidence that it does, and no platform has documented a mechanism. Structure determines which URL Google serves to which user in classic search; AI systems select and synthesise sources before that question arises. Treat a well-formed international URL structure as necessary hygiene for search rather than as a lever for AI visibility. What appears to matter more is whether each market’s pages say something genuinely different, which is covered in hreflang best practices.

Does Google ever ignore the URL structure signal?
URL structure is one signal among many. A well-optimised subdirectory with strong local links and correct hreflang will outperform a neglected ccTLD. The structure sets the stage; content and authority determine rankings.

Should I buy all relevant ccTLDs even if I use subdirectories?
Buying defensive ccTLDs to prevent brand squatting can be sensible depending on your market. Using them for SEO alongside a subdirectory strategy creates confusion and is unnecessary.

Footnotes

1. Managing multi-regional and multilingual sites — Google Search Central ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶

2. The International Targeting report is deprecated — Google Search Console Help ↩

3. Tell Google about localized versions of your page — Google Search Central ↩