Static Site Generators in Production

Subdirectories vs Subdomains for Translated Static Sites

The first decision in translating a site is where the translations live: example.com/de/, de.example.com, or example.de. It is hard to change later — every URL, redirect, canonical tag, hreflang set and analytics report depends on it — and the trade-offs are different for static sites than for dynamic ones. A static site's build, deploy and caching model makes one structure much cheaper to run than the others, while search, team and legal factors can still push the other way.

This comparison uses one company's product site in four languages, which ran German and French on subdomains and Spanish and English in subdirectories for two years before consolidating, so both structures were measured on the same content, generator (Astro 5), host (Cloudflare) and team. It belongs to Internationalization for Static Sites.

The Three Options

Subdirectories, subdomains and country domains compared at a glance Three panels. Subdirectories, example.com slash de, are one build, one deploy and one certificate, sharing the domain's reputation. Subdomains, de.example.com, are one or several builds routed per host, a wildcard certificate, and separate search properties. Country domains, example.de, need a domain, certificate, analytics and search property per country. Three ways to place translations Subdirectories example.com/de/ one build, one deploy shared domain reputation lowest operating cost Subdomains de.example.com routing per host separate search property moderate cost Country domains example.de domain + cert per country hreflang across domains highest cost
The operational cost rises from left to right; the independence between languages rises with it.

Build and Deploy

Subdirectories are the natural output of every generator's i18n support: Astro's i18n routing, Hugo's defaultContentLanguageInSubdir, Eleventy's folder-per-language layout. One build produces every language; one atomic deploy publishes them together, so a navigation change reaches all languages at once.

Subdomains were run as two builds on the measured site: the main build (English, Spanish) and a separate project for German and French that shared components through a package. Changes to shared components needed two releases and two deploys, and for two years the German site lagged the English one by a release about a third of the time. An alternative is one build routed per host — de.example.com/* rewritten to /de/* at the edge — which keeps a single build but needs rewrite rules and per-host absolute URLs in canonicals and hreflang.

Country domains add the same routing per domain, plus a certificate and DNS zone each.

MeasureSubdirectoriesSubdomains (as run)
Builds per release12
CI minutes per release4.27.9
Releases where languages diverged031%
Config for routingnone2 projects, shared package

Caching and Performance

On one domain, the browser reuses its connection, TLS session and cached CSS, fonts and JavaScript when a reader switches language. On a subdomain, the reader's first page in the new language pays for a new connection and, unless assets are shared from a common origin, downloads the same assets again. Measured with WebPageTest on a mid-range phone, switching from English to German:

Time to largest contentful paint after switching from English to German Paired bars. On subdirectories the German page reached LCP in 0.9 seconds with 14 kilobytes transferred. On subdomains it reached LCP in 1.6 seconds with 96 kilobytes transferred, because of a new connection and uncached assets. Switching language mid-visit Subdirectory Subdomain LCP after switch (ms) 900 1600 Transferred 14 KB 96 KB
WebPageTest, Moto G Power, 4G, scripted navigation from the English home page to the German pricing page, median of nine runs.

Few readers switch language mid-visit, so this matters less than it looks, but the cache sharing also benefits CDN efficiency: one zone, one cache, one set of cache rules, as in CDN Caching Rules for SSGs.

Search engines handle all three structures correctly when hreflang and canonicals are right. The practical difference is reputation: a subdirectory inherits the domain's history; a subdomain is treated as a related site that earns its own. When the measured site moved German and French from subdomains into subdirectories (with 301 redirects for every URL), Search Console showed:

Measure, German pages3 months before move3 months afterChange
Organic clicks41,20050,700+23%
Average position, top 200 queries9.47.8better
Indexed pages1,6401,690+3%

French showed a smaller gain (+11%). Some of the change may come from seasonality and other work during the period, so treat the size as indicative; the direction matched what the team had seen on two other sites. Moving the other way — subdirectory to subdomain — is rarely worth the risk.

Subdirectories give one analytics property with a language dimension, one Search Console property (or one per folder, if wanted), one privacy policy and cookie setup. Subdomains need cross-domain configuration in some analytics tools, and separate Search Console properties.

The argument for subdomains or country domains is organisational. If the German site is run by a separate local team with its own release schedule, its own content system and its own legal entity, separate hosting can match how the business works. If local trust in a .de domain measurably improves conversion — some retailers report it, few documentation sites would — country domains can pay for themselves.

Decision tree for choosing where translations live The root asks whether languages are run by separate teams or legal entities. If no, use subdirectories. If yes, and they share a codebase, use subdomains routed to one build. If they have separate codebases and target countries rather than languages, use country domains. Otherwise use subdomains with separate builds. Choosing a structure Are languages run by separate teams or entities? No Subdirectories /de/, /fr/ in one build Yes, shared code Subdomains one build routed per host Yes, separate code Subdomains separate builds Yes, per country Country domains per-country entities
Most translated static sites end on the leftmost branch.

Cost Summary

ItemSubdirectoriesSubdomainsCountry domains (4)
Domains114
Certificates11 wildcard4
Builds11–21–4
Search Console properties134
Hreflang complexitysame hostcross-hostcross-domain
Engineering time per year (measured site)~2 days~9 days— (not measured)

Migrating From Subdomains to Subdirectories

The measured site's move took two weeks: generate a redirect map from every old subdomain URL to its new subdirectory URL (2,900 URLs), deploy the combined build with redirects at the edge, and update hreflang to the new URLs. Search Console's change of address tool does not cover subdomain-to-subdirectory moves, so the redirects and updated sitemaps carried the change on their own. Keeping Redirects Working After an SSG Migration covers the redirect side; Recovering Search Traffic Lost After a Generator Migration covers what to watch afterwards.

What Readers See

Two smaller differences affect readers directly. With subdirectories, the browser's per-site settings — cookie consent, saved theme, dismissed banners — carry over when a reader switches language, because the origin is the same; on subdomains, consent banners reappeared on the first page in the new language unless the consent tool was configured to share cookies across the parent domain, which this site's tool did not support until a paid upgrade. And bookmarks, shared links and browser history group naturally by domain, so a reader who mostly uses the German site sees one site in their history rather than two. Neither is decisive, but both pushed in the same direction as the measurements above.

Hosting Limits Worth Checking

Some static hosts limit custom domains or redirect rules per project, which matters for subdomains and country domains far more than for subdirectories. Check the host's limits on custom domains, rewrite rules and certificates before committing to a multi-host structure, especially on free and entry-level plans.

Verdict

  • Subdirectories for almost every translated static site: one build, one deploy, shared caching and reputation, lowest cost.
  • Subdomains when languages are run by separate teams with separate release cycles, ideally still from one build routed per host.
  • Country domains only when the business is genuinely organised by country and local domains are proven to matter.

Pitfalls

  • Choosing subdomains for tidiness. The operating cost is real and recurring.
  • Per-host URLs in a single build. Canonicals and hreflang must use each host's absolute URL.
  • Moving structure without full redirects. Every old URL needs a 301 to its new home.
  • Separate builds drifting. If you must run two builds, share components as a versioned package and release together.

Conclusion

For a translated static site, subdirectories are the cheapest structure to build, deploy, cache and measure, and on the measured site they also performed better in search: German organic clicks rose 23% after moving off a subdomain. Subdomains and country domains are organisational choices first, worth their cost when teams or legal entities are truly separate.

FAQ

Which URL structure is best for a translated static site?

For most sites, subdirectories such as example.com/de/. They are one build, one deploy, one certificate and one analytics property, and they share the domain's existing search reputation. Subdomains and country domains make sense when languages are run by separate teams, need separate hosting or legal entities, or target countries rather than languages.

Do subdomains hurt SEO compared with subdirectories?

Search engines treat a subdomain as a closely related but separate site, so a new language subdomain starts with less accumulated reputation than a subdirectory on an established domain. In the migration measured here, moving German from a subdomain to a subdirectory increased German organic clicks by 23 percent over three months. The effect varies by site and is not guaranteed.

Can one static build serve several subdomains?

Yes. Build all languages into one output with a folder per language, then route each subdomain to its folder at the CDN or host, for example with rewrite rules on Cloudflare or Netlify. This keeps one build while presenting subdomains, though it adds routing configuration and per-host canonical and hreflang URLs.

When are country-code domains worth it?

When the business operates as separate local entities, when local trust in a country domain measurably matters for conversion, or when legal requirements differ by country. They cost the most to run, with a domain, certificate, analytics and search console property per country, and every hreflang set spans several domains.

Filed underComparisons