What does “multilingual project” mean
By multilingualism, business usually means one thing: “so that the site is in several languages.” In practice, this phrase hides a bunch of dozens of separate decisions: how to mark up URLs, how to give Google the correct versions of pages, how to translate not only texts, but also menus, forms, buttons, system messages, how to make partial or complete translations, how to manage releases in countries with different jurisdictions, and how to keep all this in one editorial system, and not in four parallel ones.
Drupal is made taking into account these tasks at the core architecture level. This is not a “plugin glued on top”, but a built-in multilingual model that starts with the Language entity and permeates all types of data - from nodes and paragraphs to users, taxonomies, system messages and view configurations.[1] This is why large multilingual projects - from EU government portals to NASA and the World Food Program - have historically been built on Drupal.
In this article, we look at exactly what mechanisms make Drupal a strong choice for a multilingual project with multiple domains, what it can do out of the box, where it is inferior to alternatives, and what the correct architecture for such a launch looks like.
Three levels of multilingualism
Before comparing CMS, it is important to divide the task into layers. Most problems in multilingual projects occur where one of these layers is forgotten or implemented manually.
Articles, service pages, product cards, paragraphs, taxonomy, media. In Drupal, it is translated at the level of individual fields - you can translate only the title and hero, leaving the rest common.
Buttons, form signatures, error messages, pagination, dates. Interface Translation picks up strings from kernel modules, contrib and custom themes, allows editing through the UI.
Menus, blocks, views, content types, field names, roles, email templates. Configuration Translation allows the editor to edit config versions for each language without editing the code.
Why is this important
If the CMS only works with content, and the interface and configuration are hard-coded through theme files - any addition of a new menu, a view or block becomes a developer's task. In Drupal, all three layers are edited with the same editor, without deployment.
Four URL and domain architectures
Google is considering four ways to host language/region versions of a site, each with its own strengths and weaknesses.[2] The choice of architecture determines both technical complexity and search behavior.
Subfolders /ru/, /en/
Start
Subdomains en.example.com
Average
Country TLDs example.de
Average
Multi-domain on one core
Drupal
The fundamental difference between Drupal is that it supports all four scenarios on one engine without changing the platform. Moving between architectures (for example, from subfolders to separate domains) is a tweak, not a refactoring.
What Drupal does out of the box
Below are the key modules that form the multilingual outline of Drupal. The first four are included in the kernel and are enabled “from the admin panel”, the rest are stable contrib modules from the ecosystem that are needed by almost any multilingual project.
Language (core)
Enables multilingual model. Allows you to add any number of languages, select a definition strategy (URL prefix, subdomain, cookie, Accept-Language, session), set a fallback language.
Content Translation (core)
Translates content by entities and fields: nodes, paragraphs, media, taxonomy, blocks, users. Supports partial translations, draft versions, tracks “outdated” translations when editing the source.
Interface Translation (core)
Manages interface lines: buttons, signatures, forms, system messages. Import .po from Drupal locales, local overrides, lines from contrib and themes - all in one screen.
Configuration Translation (core)
Translates configuration: menu, blocks, view display, email templates, names of fields, content types, roles. The “Services” menu becomes “Services” not a switch in the theme, but a translation of the config.
Metatag
Per-language meta description, title, OG tags, Twitter Cards, canonical, robots. Defined by templates by content type and redefined for individual pages - all this is multilingual.[3]
Simple XML Sitemap
Sitemap with automatic hreflang alternatives: each URL entry is accompanied by links to all language versions. Separate sitemap per domain, auto-generation of index, incremental update.
Pathauto + Language token
URL aliases per language - /uslugi/seo in Russian and /services/seo in English from one pattern with a language token. The editor does not set aliases manually - they are generated from the header according to the rules.
Domain Access
Several domains on one installation. Each node belongs to one or more domains, you can configure per-domain menus, blocks, themes. Works on top of multilingualism - one node can be in two languages and three domains.[4]
Comparison: Drupal vs WordPress vs Bitrix vs Tilda
We compare four platforms according to key parameters that determine the cost and quality of a multilingual project with several domains. In WordPress, we consider a combination with a paid WPML plugin, without which multilingual functionality is limited.
| Option | Drupal | WordPress + WPML | 1C-Bitrix | Tilda |
|---|---|---|---|---|
| Multilingual in core | Yes, 4 modules | No, plugin | Partially | No |
| Translation of fields | Per-field | At level entries | Through information blocks | Double page |
| Automatic hreflang | Out of the box | Via plugin | Manually | Manually |
| Translating menus/blocks/views | UI for editor | Only via WPML | Manually by language | Double |
| Multi-domain in one core | Domain Access | Multisite + WPML | Multisite | Only individual accounts |
| Cost of licenses/plugins | 0 (open source) | ~$99–199/year (≈300–620 BYN) | From ~1,500 BYN per edition | Subscription for pages |
| Editorial workflow per-language | Content Moderation, statuses | Via plugin | Customizable | No |
| Integration with translation services | TMGMT, Lingotek | WPML + TMS integration | On your own | No |
| Scale (50+ languages) | Tested for EU portals | Difficult, but possible | Not intended | Not intended |
| Sitemap per-domain + hreflang | Simple XML Sitemap | Yoast/Rank Math + manual setting | Limited | Without alternates |
Output from the table. For simple tasks (2 languages, 1 domain, small content), the difference between the platforms is not critical. On tasks of the level “4–6 languages × 2–3 domains × hundreds of pages × editorial workflow,” Drupal wins fundamentally - this is the configuration it was designed to support.[5]
SEO benefits for a multilingual project
SEO on a multilingual website is not just about content. This is also the correct technical markup so that Google and Yandex understand which page is intended for which audience. Errors here are costly: two languages may start competing for the same search results, canonical points to the wrong version, users from Germany see an English page instead of a German one.
What Drupal does automatically
For each translated page: <link rel="alternate" tag hreflang="xx" href="..."> for all language versions, correct canonical, lang-attribute in <html>, correct metadata language (og:locale, og:locale:alternate). The editor does not mark this up manually—the data model itself knows which page corresponds to which language.
Where other CMSs go wrong
Typical problems of platforms without native multilingualism: hreflang is placed only on some pages, canonical refers to the source language instead of the current one, sitemap alternates are omitted, the language switcher switches to the main page instead of the same page in another language.[6] All this is a loss of traffic and indexing.
Multi-domain on one core
The scenario of a typical international project: one brand, several domains (brand.com, brand.de, brand.pl), each with its own set of languages and part of the content. News and articles are shared between domains, service cards are shared only in relevant countries, prices and legal texts are unique for each.
In Drupal, this configuration is implemented in two ways:
Classic multisite
Several independent installations
Each domain is a separate Drupal installation with a common core. Plus - complete isolation, the possibility of different themes and settings. The downside is that content is not shared between sites out of the box, editors work in different admin panels, module updates are tested on each site separately. Suitable when sites are conceptually different.
Domain Access
One Drupal, several domains
One admin, one database, one installation. Each node belongs to the selected domains. Common editorial workflow, common content pool with override by domain. Per-domain customization of menus, themes, blocks, URL aliases. Works on top of multilingualism - the German page on brand.de and the English page on brand.com live in the same entity.
How it works in conjunction
A Node with the “price” field can have a version in Russian and English, and at the same time - different field values for brand.com and brand.de. As a result, the editor has one interface, SEO has the correct hreflang and canonical, and the business has one control loop instead of three separate sites.
Typical mistakes of multilingual sites
Let's compare the most common errors that occur in multilingual projects on other platforms with how a correctly configured Drupal solves the same problems.
Typical mistakes
How SEO is broken
The same title/description in all languages. Canonical points to English version from all languages (cannibalization). Hreflang are placed partially or with typos in country codes. The language switcher leads to the main page. Sitemap without alternates. 301 redirects for Accept-Language break indexing. The menu is translated, and the names of the items are taken from the theme and remain in English.
The correct approach
As done in Drupal
Meta templates per-language via Metatag. Canonical refers to the current language, hreflang refers to all alternatives. Switcher uses entity-relations and leads to the same page in a different language. Simple XML Sitemap adds alternates automatically. Language detection by URL + cookie (without forced redirects). Interface Translation guarantees the translation of all UI strings, including the theme and modules.
Launch checklist
7 steps to properly launch a multilingual Drupal project
- Identify target languages and countries before the technical specifications for the site. The list of languages affects the URL structure and domain selection (subfolder/subdomain/TLD) and design (length of lines in the menu, text direction for RTL).
- Choose the URL architecture in advance.Subfolders for start and simple SEO consolidation, country-level domains - if local targeting is a priority. Changing the architecture after the release is a painful process with redirects.
- Decide what translation is complete and what is partial.In Drupal, you can translate individual fields - this is useful when the service catalog is general, and landing pages are localized. Planned at the content model stage, not after release.
- Enable all four kernel language modules.Language, Content Translation, Interface Translation, Configuration Translation. This is the base without which Drupal works like a regular monolingual CMS.
- Set up Metatag and Simple XML Sitemap right away Per-language meta, canonical and sitemap templates with hreflang alternatives should be ready before the first indexing.
- Identify content common to domains.What is shared (news, privacy policy) and what is unique for each domain (catalog, prices, legal details). The choice between Domain Access and multisite depends on this decision.
- Design an editorial workflow.Who translates, who reviews, how “outdated” translations are tracked after source code edits. Content Moderation + working statuses “translation needed / in progress / ready.”
ONTOP Practice
On ONTOP projects we work with full-cycle multilingual Drupal installations: from choosing URL architecture and domains to setting up Metatag, Simple XML Sitemap, Domain Access and integration with third-party translation services via TMGMT. Editors get a single interface, SEO specialists get automatically correct hreflang and canonical, businesses get the opportunity to scale the project to new languages and countries without changing platforms.
More details about related processes: single agency instead of several contractors, why “website first, then marketing” is a redo, website development on Drupal, SEO promotion.
Are you planning a multilingual project or migration to Drupal? Get a free architecture assessment - we'll show you which modules you'll need, how to design a URL, and where points of difficulty will arise.
FAQ
Drupal is more complicated than WordPress - won't we overpay for implementation?
On simple monolingual sites, WordPress is actually cheaper to start with. On multilingual projects with multiple domains, the picture changes: WPML requires a separate license, manual configuration of hreflang in several plugins, and still does not cover the translation of menus/widgets as cleanly as Drupal. In 12–18 months, Drupal's TCO is usually lower precisely due to the lack of a plugin chain.
Is Domain Access needed if there are only two domains?
Not always. If two domains are different languages of the same brand and the content is common, one Drupal with subfolders or subdomains is enough. Domain Access is needed when sites must differ in content (catalog, prices, legal details) and editors want to manage everything from one admin panel. For business scenarios “RU + EN of the same” Domain Access is redundant.
How does Drupal work with translations if they are done by an external agency?
Through the TMGMT (Translation Management Tool) module: you can upload content to XLIFF or connect the API of translation services (Lingotek, Smartling, ModernMT). Drupal tracks the translation status, automatically imports completed versions, and marks them as “outdated” when editing the source. The editor's manual work comes down to verification and publication.
How to choose between subfolders and individual domains?
Rule of thumb: subfolders - if the business is international, but there is no strong local connection, and the content overlaps. Country specific TLDs - if you want the maximum local targeting signal for Google, and are ready to accumulate SEO weight on each domain from scratch. An intermediate option is subdomains on a common TLD with geotargeting settings in Search Console.
What to do with RTL languages (Hebrew, Arabic)?
Drupal supports RTL at the core level: the theme automatically switches the text direction, menus and layout are mirrored. The only thing required is a correctly prepared theme with RTL styles (most high-quality themes support RTL out of the box). Content and interface are in the same editor, without separate tools.
Is it possible to add a new language a year after launch without rework?
Yes. Drupal was designed to expand the range of languages: adding a new one means enabling it in the admin panel and translating existing content. The URL scheme, hreflang, sitemap, meta templates will automatically pick up the new language. There is no need to convert anything. This is a key difference from a CMS, where each new localization is a separate project.
What is the situation with caching on a multilingual + multi-domain site?
Drupal uses cache contexts: cache keys are automatically separated by language and domain. The same page in Russian under brand.com and in German under brand.de are cached as separate records. With proper configuration of BigPipe, Dynamic Page Cache and external CDN (Varnish / nginx fastcgi), performance does not suffer.
Conclusions
A multilingual project is not a task of “add a language switcher to the header.” This is an architecture challenge that permeates content, interface, configuration, URLs, SEO markup, caching, and editorial workflow. The choice of CMS here is a strategic decision that affects the cost of ownership over several years.
Drupal is one of the few platforms where multilingualism is built into the core level and is not assembled from plugins. This is manifested in small things: automatic hreflang, correct canonical, translation of menus and configurations through the UI, Domain Access working on top of a multilingual model, integration with translation services. For projects at the level of “3+ languages × 2+ domains × full-fledged editorial process,” this provides noticeable savings—both money and editorial time.
If the project is immediately designed as international, Drupal is almost always the most predictable choice. If the start is limited to one language and one domain, but in the future you want to enter new markets, Drupal makes it possible to start simply and scale without changing the platform.
Sources
- Drupal.org - Multilingual guide - official guide to the Drupal multilingual model: languages, translation of content, interface and configurations.
- Google Search Central - Localized versions of your pages - official documentation on hreflang, canonical and URL architectures for multilingual and multiregional sites.
- Drupal.org - Metatag module - module for managing meta tags, including multilingual templates title, description, canonical, Open Graph.
- Drupal.org - Domain Access project - module for managing multiple domains on one installation Drupal with shared or separated content.
- Moz - International SEO guide - a practical guide to SEO of multilingual and multiregional sites, URL architecture, hreflang, common errors.
- Google Search Central - Multi-regional and multilingual sites - official Google markup recommendations and indexing sites with multiple languages and regions.
