Subdomain vs Subdirectory for International SEO: Pick a Structure

Crawvix Editorial Team · Published October 29, 2026 · Last updated October 29, 2026 · 9 min read

The moment a business adds a second language or country, someone has to decide where the new pages will live. Will German pages sit at example.com/de/, at de.example.com, or on a separate domain such as example.de? The question of subdomain vs subdirectory for international SEO comes up in almost every expansion project, and it is hard to change later without redirects, lost history and a lot of rework.

This guide is for site owners, marketers and developers who are planning a multilingual or multi-regional site, or who inherited one and want to understand the trade-offs. You will compare the options as Google documents them, make a decision based on your own resources, and set up the chosen structure so search engines can tell your versions apart.

One honest note before we start: no structure is a ranking shortcut. The choice affects how easy your site is to run, how clearly each version signals its audience and how much separation you get between markets. It does not decide how well your pages rank.

Before you begin

  • Gather facts: which languages and countries you serve today, which you plan to add in the next two years, and whether different markets need different prices, legal text or products.
  • Check your resources: who can register domains, manage DNS, run extra servers and maintain separate sites? Also check your content team's capacity, because every version needs real, translated content.
  • Know your platform limits: some CMS and shop platforms support folders per language easily and subdomains or separate domains only with extra work. Read your platform's documentation first.
  • Time and risk: the decision takes a day of discussion. Changing it after launch is a site migration, with redirects for every URL. Plan carefully now.
  • Backup: if you are changing an existing structure, export the full URL list from your sitemap and server logs before you start.

The options at a glance

Google's guidance on multi-regional sites lists four ways to structure the URLs. It sets out advantages and disadvantages for each rather than naming one as the winner.

Option Example Advantages Disadvantages
Country-code domain (ccTLD) example.de Clear geotargeting; server location does not matter; easy to separate sites Can be expensive or hard to get; needs more infrastructure; some registries have strict rules; targets one country only
Subdomain on a generic domain de.example.com Easy to set up; servers can be in different places; easy to separate sites Users may not tell from the URL whether de means a language or a country
Subdirectory on a generic domain example.com/de/ Easy to set up; low maintenance on the same host Users may not recognise the geotargeting from the URL; one server location; harder to separate sites
URL parameters example.com?loc=de None listed Google does not recommend it; segmenting by URL is difficult and geotargeting is not clear

Treat the table as a list of trade-offs, not a score. The right answer depends on which disadvantage you can live with.

Step-by-step instructions

Step 1: Decide what a "version" means for your business

Write down whether you are targeting languages, countries, or both. A single language can serve several countries (English in the United States and the United Kingdom), and a single country can need several languages (French and German in Switzerland).

This matters because a country-code domain targets one country, while a folder or subdomain can be organised by language, by country or by both (/de-ch/). Google also warns that a subdomain such as de.example.com does not tell users, or by itself the search engine, whether it means German speakers or Germany. Choose names that match your plan, and write the mapping down.

You have succeeded when you have a one-page table of audiences, each with a language and, if relevant, a country.

Step 2: Score the options against your resources

Go through the table above with your own constraints.

  • Small team, one platform, shared brand: subdirectories are the lightest option, because everything runs on one host and one set of settings.
  • Separate teams or separate legal entities per country: subdomains or country domains give cleaner separation, at the price of more infrastructure.
  • Strong local presence in one country, with local domain available: a country-code domain makes the target obvious. Check availability and registry rules before committing.
  • Server location needs: Google lists different server locations as an advantage of subdomains and separate domains, and a single server location as a disadvantage of subdirectories. If you need servers near users, a CDN is a common alternative; our CDN setup guide covers doing that without breaking crawling.

You have succeeded when you have picked one structure and can state in a sentence why its disadvantages are acceptable.

Step 3: Avoid the structures Google does not recommend

Google does not recommend URL parameters such as ?loc=de for country or language versions. Cookies and browser settings are also poor ways to vary a page. Google says to use different URLs for each language version rather than cookies or browser settings, because a crawler cannot reach versions that exist only behind a setting.

Also avoid mixing structures casually. A site that has example.com/de/, fr.example.com and example.es all at once is harder to maintain, harder to report on and harder to explain to colleagues.

You have succeeded when every version has its own stable, linkable URL in one consistent pattern.

Step 4: Build the structure and keep one language per page

Create each version at its own URL. Within each page, keep content and navigation in one language. Google advises against side-by-side translations and notes that translating only the boilerplate while the main content stays in one language can be a poor experience, especially for user-generated content.

Do not rely on the HTML lang attribute or locational meta tags for search. Google says it does not use code-level language information to detect language, relying instead on the visible content, and that it ignores locational meta tags. The lang attribute is still good practice for accessibility.

You have succeeded when each URL serves one language of content and nothing is hidden behind a cookie or setting.

Step 5: Connect the versions with hreflang

Whatever structure you choose, tell search engines how your versions relate with hreflang annotations. Google says language-specific subdomains such as en, en-gb and de do not by themselves determine the target audience, so you must map the audience explicitly. Follow the hreflang implementation guide for codes, return links and x-default.

Alternate versions do not need to share a domain, so hreflang works the same way across a country domain, a subdomain and a folder.

You have succeeded when every version lists all of its alternates and itself, and the sets are reciprocal.

Step 6: Give visitors a way to choose, and do not guess

Geotargeting is not an exact science, in Google's words, so some visitors will land on the wrong version. Add visible links so people can switch region or language.

Do not redirect visitors automatically based on a guess about their language or location. Google says this can prevent users and search engines from reaching every version, and it also says not to use IP analysis to adapt content because IP location is unreliable. Googlebot usually does not send an Accept-Language header, so a site that decides by that header may show crawlers only one version. A banner suggesting a better version, with a link, is safer than a forced redirect.

You have succeeded when a visitor and a crawler can each reach every version by following ordinary links.

Step 7: Set up Search Console to match

Search Console properties follow your structure. A Domain property covers all subdomains, protocols and subpaths for a domain and needs DNS verification. A URL-prefix property covers only URLs that start with the exact prefix you enter, and Google suggests creating one per subfolder you want to track, such as https://example.com/france/, in addition to one for the whole site. If you use separate subdomains and URL-prefix properties, each subdomain needs its own property. A Domain property cannot be limited by path, but you can use a page filter in the Performance report. The Search Console setup guide walks through verification.

You have succeeded when you can view performance for each market separately.

Final verification checklist

  • Every language or country version has its own stable URL in one consistent pattern.
  • No version depends on cookies, IP detection, or the Accept-Language header to appear.
  • Each page contains one language of main content and navigation.
  • hreflang annotations are in place, reciprocal and use valid codes.
  • Visible links let users switch to other regions or languages.
  • No automatic redirect sends users or crawlers away based on a guess.
  • The same robots rules apply across every version.
  • Search Console properties exist for each market you want to monitor.

Common mistakes to avoid

  • Choosing by habit rather than resources. Picking a country domain without budget for separate hosting and teams leaves sites neglected. Match the structure to what you can maintain.
  • Using URL parameters for locales. Google does not recommend them. Switch to folders or subdomains.
  • Assuming de.example.com signals Germany. It could mean German language. Use hreflang to say what you mean.
  • Redirecting by IP or browser language. This hides versions from crawlers and frustrates travellers. Use links and banners.
  • Different robots rules per locale. Google recommends applying robots rules consistently across locales. Check each version's robots.txt and robots meta tags.
  • Translating only the menu. Translate the main content too, or do not publish that version.
  • Moving structures without redirects. A switch from subdomains to folders is a migration. Map every old URL to its new one with permanent redirects, and read our redirect chains guide to avoid loops.

Frequently asked questions

Which structure is best for SEO?

Google's documentation lists pros and cons for each and does not name a single winner. The best choice is the one that gives clear signals, that you can run well and that suits your team. A structure you can keep consistent is a better choice than one you cannot afford to maintain.

Can I mix a country domain with subfolders?

Yes. For example, you might run example.de for Germany and example.com/fr/ for France. It works, but it multiplies things to maintain, so only do it when there is a clear business reason.

Do I need a country-code domain to target a country?

No. A country-code domain gives a clear geotargeting signal, but Google also names locale-specific URLs with hreflang or sitemaps as geotargeting methods. A subdirectory with correct annotations can target a country.

Does server location matter?

Google says that for country-code domains the server location does not matter. Differing server locations are listed as an advantage of subdomains and separate domains. If speed in far-away regions is your concern, test it rather than assume.

Should I use language folders or country folders?

Use language folders if you offer the same content in a language to many countries, and country-plus-language folders (such as /de-ch/) if prices, laws or products differ by country. Whichever you choose, say so explicitly with hreflang.

Can I change the structure later?

You can, but it is a site migration with redirects, new sitemaps and a period of monitoring. Make the decision as if it were permanent.

Official references


Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.