Multilingual website: subdirectories, subdomains, ccTLDs, and SEO configuration

Building a multilingual or multi-regional site means more than translating content. The URL structure decision — subdirectories, subdomains, or separate ccTLD domains — determines how Google interprets geo-targeting, how link equity flows, and what ongoing maintenance costs. We cover all options: from simple multilingual setups to a regional ccTLD network managed from a single Next.js monorepo.

A multilingual website is not just a set of translated pages. From an SEO standpoint it is a distinct architectural challenge: Google must understand which version is intended for which audience, where the canonical page lives, and how link equity is distributed across language versions. A poorly chosen structure turns into technical debt for years.

Before choosing your URL structure, study competitors in your target regions. If the top three in your niche use ccTLDs, that is a signal. Google accounts for a domain's historical authority in a region — a new subdomain cannot replicate that in a month.

Three URL structure strategies

Google officially supports three URL structure approaches for multilingual and multi-regional sites. Each has its own strengths, limitations, and infrastructure requirements.

Subdirectories

example.com/ru/, example.com/en/, example.com/de/ — all on one domain. All link equity concentrates on a single domain. Simple maintenance: one site, one server, one infrastructure. The downside: Google does not treat a subdirectory as a local site because the domain is not country-tied. Best option for most businesses with an international audience.

Subdomains

ru.example.com, en.example.com, de.example.com — technically separate sites sharing a root domain. Google treats a subdomain as a separate site, which complicates link equity transfer. Geo-targeting is configured through Search Console. Historically used by large players; today considered an outdated choice for most multilingual scenarios.

Separate domains / ccTLDs

example.ru, example.de, example.fr — individual domains, each linked to a specific country. The strongest geo-targeting signal for Google. Users in Germany trust .de more than .com. The downside: each domain needs independent link building, hosting, SSL maintenance, and content work. High operational costs at scale.

Is geo-targeting needed?

If your business operates in specific cities or regions (services in London, Berlin, Warsaw), geo-targeting is a mandatory part of the architecture. For cities and regions, subdirectories with semantic slugs are used: /london/, /berlin/, /warsaw/. This is not the same as multilingual — geo-targeting can apply within a single language.

On key parameters: subdirectories win on link equity concentration and maintenance simplicity. ccTLDs win on geo-signal strength. Subdomains win in neither category and are gradually falling out of favour.

Do not confuse multilingual and multi-regional. Multilingual means different languages for one market (ru + en + de). Multi-regional means one language, different regions (Moscow, St. Petersburg, Yekaterinburg). The right structure can differ for each scenario.

Geo-targeting: cities, regions, and countries

Regional SEO is a standalone discipline within multilingual architecture. When a user searches for 'apartment renovation in Munich', Google wants to surface a site that signals relevance specifically for that city. Several mechanisms work in concert.

Geo-targeting via URL: Subdirectories with region or city codes in the URL: /london/, /berlin/, /warsaw/. Or ccTLD domains for countries: .de for Germany, .fr for France, .pl for Poland. The URL signal is read by the crawler before the page content is parsed.
Geo-targeting via Search Console: For subdomains and generic TLDs (.com, .org), you can specify a target country in Google Search Console property settings. Works as an additional signal but weaker than ccTLD. Cannot be applied to subdirectories — only to the domain or subdomain as a whole.
Geo-targeting via content and NAP: City, region, and address mentions along with local phone numbers in the content (NAP — Name, Address, Phone). Important for local SEO. Google cross-references content signals with Google Maps and Google Business Profile data.

For businesses with offices in multiple cities, the optimal structure is a main domain with subdirectories: site.com/london/, site.com/berlin/. Separate pages per city with unique content — not just a city name swap. Duplicate content with replaced city names is one of the most common local SEO filters.

If competitors in your region use ccTLDs (.de, .fr, .pl) while you use .com with geo-targeting in Search Console, you are operating at a structural disadvantage. In some niches this can be offset by content quality and backlinks; in others, a ccTLD is effectively a prerequisite for top rankings.

Platform choice: WordPress, MODX, Next.js, and headless CMS

The choice of CMS critically affects multilingual and multi-regional capabilities. Each platform solves the problem differently, with distinct trade-offs in flexibility, development cost, and scalability.

WordPress + WPML or Polylang

The most widely used solution. WPML is a powerful commercial plugin (~$99/year) supporting any number of languages, translation synchronisation, and hreflang builder. Polylang is a free alternative with limited capabilities in its free tier. Limitation: WordPress was not designed for multilingual use from the ground up, so any solution is a layer on top that complicates the database and slows things down over time.

MODX + Babel

MODX supports multilingual through the Babel component (context configuration). Each language or region becomes a separate context with its own resource tree, settings, and domain. More flexible than WordPress+WPML, but requires an experienced MODX developer. Documentation is sparse, ecosystem is small. Good when the team already has MODX expertise.

Next.js + next-intl

The native solution for modern applications. next-intl provides locale-based routing, translation management via JSON files, and full SSR/SSG support. Key advantage: from a single monorepo you can serve multiple domains with different locales via Next.js middleware. No plugin overhead, no version conflicts — the internationalisation logic is built into the architecture.

Headless CMS (Contentful, Sanity, Strapi)

The headless approach separates the content backend (CMS) from the frontend (Next.js, Nuxt, SvelteKit). One content source, multiple frontends or domains built on top of it. Contentful and Sanity support localisation at the field level. Editors get a friendly interface; developers get a fully free stack. Downside: adds another service to the infrastructure with associated costs.

For a simple bilingual corporate site, WordPress+WPML is a reasonable choice. For a complex regional network with dozens of domains — only Next.js. MODX fits when the team already works with that platform and has the relevant expertise.

Next.js and multi-domain setup: one monorepo, multiple ccTLDs

This is the most powerful and most complex architecture to implement. The concept: one codebase, one repository, one deployment pipeline — but multiple independent ccTLD domains for different countries. Available only with Next.js (and Nuxt 3 in a similar paradigm) — WordPress and MODX cannot do this without fundamental infrastructure surgery.

Why only Next.js? Because Next.js middleware can intercept a request before rendering and route it based on the hostname. WordPress and MODX are server-side monoliths not designed for this kind of routing without major architectural changes.

How it works in practice: in next.config.ts you describe the domains and their corresponding locales. Middleware intercepts the request, checks the hostname (seohead.ru → ru, seohead.com → en, seohead.de → de), and sets the correct locale on the request. All components, translations, and SEO metadata receive the right locale without any code duplication.

Unified content management

One set of JSON files or one headless CMS manages content for all domains. Updating an article, adding a new product, or changing navigation applies to all sites through a single deploy.

Unified deployment pipeline

A CI/CD pipeline builds one image that serves all domains. Nginx or a CDN routes traffic from different domains to a single container. Infrastructure costs are lower compared to running separate standalone sites.

Component reuse

Header, footer, SEO meta tags, structured data — written once and working across all domains with correct localisation. Updating a component applies everywhere simultaneously with no risk of divergence.

Implementation complexity

The architecture requires an experienced Next.js developer. You need to correctly configure middleware, hreflang per domain, a separate sitemap per domain, robots.txt per domain, and segregated SEO metadata. Errors lead to keyword cannibalization and loss of geo-targeting signals.

Who this makes sense for: businesses operating in 3+ countries with specific ccTLDs, a development team (not a single freelancer), and an existing or planned Next.js stack. For a small business with one or two languages — this is overkill.

Localisation and translation: how to do it right

Localisation is not translation. Translation is rendering meaning in another language. Localisation is adapting content to cultural context, audience expectations, and local norms. The SEO difference is critical: machine translation produces low-quality duplicate content that Google is getting better at detecting.

Machine translation (DeepL, Google Translate): Fast and cheap, but requires mandatory editing by a native speaker. Raw machine translation without post-editing is not localisation — it is a risk factor for a thin-content penalty. Use it as a first draft, not the final output.
Professional translation with localisation: A native-speaker translator adapts not just the text but also examples, case studies, units of measurement, date and currency formats, and cultural references. Expensive, but the right approach for key pages: homepage, services, about.
CAT tools and Translation Memory (TM): For large content volumes: Phrase (formerly Memsource), Lokalise, Crowdin. They store agreed-on translations of terms and save up to 40% of time when updating content. They integrate with the codebase via CI/CD pipelines.

SEO keywords in target languages must be researched independently: a direct translation of a keyword phrase often does not match what native speakers actually search for. Use Ahrefs or Semrush switched to the target country — not a translation tool.

Research semantics separately for each target language. 'Website promotion' does not map to the same search cluster as 'SEO' — they have different volumes and competition levels. Always do independent keyword research per locale, not just translation.

SEO configuration: hreflang, sitemap, canonical

The technical SEO setup for a multilingual site consists of several mandatory elements. Skipping any one of them causes indexing confusion and traffic loss.

hreflang

The hreflang attribute tells Google: 'This is the same page but for a different language or regional audience.' Implemented via <link rel="alternate" hreflang="en"> in <head> or through an XML sitemap. Required for all language versions, including x-default (the fallback). Errors in hreflang are one of the most common causes of incorrect language version ranking.

XML sitemap

For a multilingual site, the sitemap must contain all language versions of every page with hreflang annotations. For multi-domain setups — a separate sitemap per domain. Google does not automatically carry knowledge about pages across domains, even when the same codebase serves them.

Canonical tags

Each language version is self-canonical (its canonical tag points to itself, not to the main language version). Do not use canonical tags to 'merge' language versions — that tells Google to ignore the translations. hreflang and canonical are different tools serving different purposes.

Metadata in the correct language

Title, description, og:title, og:description — all must be in the language of that page version. Mixing languages in metadata lowers CTR and confuses the algorithm. For each page in every locale — unique, optimised metadata.

Common mistake: hreflang is correctly configured but pages are blocked from indexing in a specific region via robots.txt. Google cannot apply hreflang to pages it cannot index. Always check robots.txt separately for each domain or subdomain.

What to choose: subdirectories or multi-domains

Universal advice: start with a competitor analysis in each target region. If the top five in your niche in Germany are German ccTLDs (.de), the subdirectory example.com/de/ will work but at a structural disadvantage. If competitors use subdirectories — there is no reason to invest resources in ccTLDs.

Choose subdirectories when: Small or medium business without separate teams per country. Budget is limited. Speed of launch matters. Competitors in target regions also use subdirectories. Scales well: adding a new language means adding a folder and translations.
Choose ccTLDs when: Serious presence in specific countries with a highly competitive market. Competitors use ccTLDs. Separate teams or budget to maintain each domain independently. Maximum local trustworthiness matters (finance, e-commerce, legal services).
Avoid subdomains: Subdomains are the worst of three worlds: link equity does not transfer as well as from subdirectories, geo-signal is weaker than ccTLDs, maintenance is more complex than subdirectories. Use only when required by technical architecture (e.g., SaaS with custom client domains).

The most powerful SEO option — regional ccTLDs with a Next.js monorepo — is simultaneously the most expensive to launch and maintain. Managing 5+ domains with unique content, separate link-building strategies, and localisation teams is a full operational load. Make sure the business is ready for this investment before starting implementation.

In practice, most businesses start with subdirectories and migrate to ccTLDs as they grow. Well-configured 301 redirects and hreflang ensure a safe migration without losing positions. No approach is final — the architecture can be changed with the right technical migration plan.

FAQ

Yes. For regional targeting without a language change, use hreflang with a region tag: hreflang="en-US" for the United States, hreflang="en-GB" for the UK. This tells Google the content is in one language but targeted at different countries.

Technically yes, via WPML with separate WordPress installations per domain, or via Multisite. But this is not a monorepo — it is multiple independent WordPress installations requiring manual synchronisation. Scaling is painful.

Through the Babel component and context configuration. Each language or region becomes a separate context with its own resource tree and settings. Babel synchronises content between contexts. Requires an experienced MODX developer — documentation for Babel is sparse.

Language is a factor, but not the decisive one. More important signals include: ccTLD or geo-targeting in Search Console, backlinks from local resources, site speed in the region, and behavioural factors from the local audience.

Complex, but feasible. Required steps: register domains, migrate content, set up hreflang with new URLs, implement 301 redirects from old URLs to new domains, update backlink profiles, submit new sitemaps. The process takes 2–4 months with a traffic dip of 1–3 months.