Drupal Multilingual: Where the Site Structure Breaks
Drupal multilingual breaks not at the stage of enabling languages, but later — when content starts to live its own life. A typical picture: a piece of content has been translated, but its language version got a separate URL instead of being linked to the source node.
A search engine sees two independent documents with the same meaning, and both pages drop in the rankings — content duplicates dilute the weight between the versions.
The second source of problems is translation desynchronization. Some fields are translated, some remain in the original language, while interface strings are pulled from a separate set and live on their own schedule.
As a result, the user sees a mix of languages on a single page, and the editor does not understand which version they are editing and whether saving will overwrite someone else's translation.
The third layer is hreflang errors. If the markup specifies non-existent URLs, region codes are mixed up, or a return link is missing, the search engine simply ignores the hints. Then the language versions compete with each other, and the target audience lands on the wrong page.
For support, this means that every edit requires manual checking of URLs and links between versions.
Separately, there is the structure of language versions: the choice between translating nodes, separate content items for each language, and a domain scheme determines everything that follows — from the cost of edits to search engine behavior.
We break down how to build Drupal multilingual without duplicates, with correct hreflang and predictable support.
What a correct language architecture delivers
A correct language architecture starts with content existing in a single instance, while language versions are its representations.
In Drupal, this is handled by entities with field translation enabled and linked via langcode: editing the source page does not require duplicating it in every language, and translations are pulled into the current structure.
If the architecture is built correctly, publishing a new language version takes minutes rather than hours of manual copying.
The second effect is predictable indexing. When each version has its own address, a correct hreflang, and a canonical tag, search engines see distinct language pages rather than duplicates of the same text.
The share of pages without duplicates grows, and with it, visibility in local search results: a visitor from the relevant region lands on their own version rather than an English-language placeholder.
The third effect is resilience to edits. When the catalog structure or card template changes, the changes apply to all languages at once because the content source is single.
There is no need to reconcile dozens of pages manually and catch discrepancies that usually surface only after release.
The speed of publishing translations, the share of pages without duplicates, and the predictability of edits are not abstract wishes but measurable indicators that are built into the architecture from the start.
That is exactly why we analyze the language model before layout begins, rather than fixing it after launch.
Ways to organize translations: comparing approaches
In Drupal, content translation and interface translation are two independent mechanisms, and confusing them is costly: interface strings live in translation files and are updated separately from entities, while entities themselves (content, taxonomy, menus, fields) receive translations at the database level.
If you choose the wrong approach for the task, you end up with either duplicate content or untranslated labels in forms and emails.
The second layer of choice is how languages are visible in URLs.
Language prefixes (/en/, /de/) are simpler to set up and do not require separate certificates, while language domains give clean URLs and are better suited when a language has its own audience and its own search results.
Changing this decision after launch means migrating all URLs, so we lock it in before populating content.
| Option | When it fits | Limitations |
|---|---|---|
| Entity translation (built-in) | Content and taxonomy where translations are linked to each other | As the number of languages and fields grows, the database grows; links between translations must be maintained |
| Interface translation via files | Strings of themes, forms, emails, system labels | Does not cover content; updating a module may overwrite a string |
| Single content with language fields | Simple types where a translation is just one or two fields | Does not scale to large volumes, breaks search and filters |
| Language domains | Separate search results and brand per language | Requires certificates, separate configuration of redirects and canonical URLs |
| Language prefixes | Quick start, one domain | Languages are less clearly separated in search, regional versions are harder |
In practice, they are almost always combined: entities are translated with the built-in mechanism, the interface with files, and the addressing method is chosen based on the number of languages and search requirements.
The limitation that surfaces last of all is shared content such as prices or specifications: it is either duplicated per language or moved into a separate entity with references, and this decision is also best made before populating content.
Stages of setting up a multilingual site
Multilingualism in Drupal is not about installing a module, but about designing the structure: it determines how search engines will see the page versions and how editors will work with them.
We arrange the order of work so that duplicate URLs and out-of-sync translations do not appear at the content entry stage rather than being fixed later with redirects.
- Audit of the language structure. We review the current content, taxonomies, menus, and templates: what is fully translated, what remains shared, and where content is already duplicated. We record the target languages and regional variants so as not to introduce unnecessary entities.
- Language scheme and translation rules. We determine which content types and fields are translated, what is inherited without translation, and how we handle the language binding of terms. At this step we set the translation mode — manual, with a common source, or mixed.
- Configuring translations. We enable the required languages, configure content types, fields, and taxonomies, and connect modules for interface and content translation. We separately verify that the editor sees only the relevant language tabs and does not create duplicates.
- Checking URLs and markup. We configure path patterns with a language prefix, eliminate duplicates, and check canonical URLs and the correctness of language labels. We run the sitemap and make sure that each version points to its alternatives.
- Testing scenarios. We check language switching, behavior when a translation is missing, the operation of search and forms, and redirects from old URLs. We separately look at how the site behaves when a new language is added.
- Handing over documentation. We provide the guidelines: which fields to translate, how to add a language, and how to check URLs before publication. Plus a map of the current structure and a list of known limitations.
This order removes the main pain of multilingual projects — version divergence and duplicates in search results. Editors work by clear rules, and search engines get an unambiguous picture of the language versions.
Artifacts and documentation after implementation
After implementing Drupal multilingual functionality, the client receives not a "set of settings" but a package that the team can work with without us: configurations, URL schemes, guidelines, and redirect rules. Below is exactly what we hand over and why each artifact is needed in daily work.
- Language configuration export — which languages are enabled, which one is the default, how prefixes and language detection by URL are configured. It allows deploying the same configuration to a staging environment and production without manual assembly.
- URL and translation scheme — a "language → URL pattern → translation source" table so that new content gets a correct URL and no duplicate appears.
- Redirect and canonical URL rules — a map of redirects from old URLs to new ones and settings that prevent language versions from being merged in search.
- Publishing guidelines — the editor's procedure: which language is filled in first, how translations are linked, what is checked before publication.
- Translation documentation — a glossary of terms and formatting rules so that different editors do not diverge in wording.
- hreflang instructions — which language pairs are assigned automatically and which are set manually, and why.
- Acceptance checklist — a set of checks: URL correctness, absence of duplicates, language switcher functionality, indexing of each version.
- Configuration change log — what changed in the language settings and when, so that in case of failure you can quickly roll back to a working state.
Each artifact addresses a specific risk: duplicates in search, lost translations, broken URLs after a release. Describe your task — we will come back with an estimate and a documentation handover plan.
Case: eliminating duplicates and translation desync
Corporate website on Drupal with four language versions: content editors complained that translations were "getting lost," and search results showed different URLs for the same page.
The audit confirmed the worst: 38% of indexed URLs were duplicates — Russian-language material was accessible both via the primary path and via a service path with a language prefix, and language tags on some pages pointed to themselves instead of to alternatives.
What it was before
Translations existed as separate pieces of content linked to each other manually. An editor would publish the Russian version, then copy it and translate it — the links between copies broke whenever the source was updated.
The average time from publishing the original to the translation appearing was 6 business days, because half the steps were done manually and verified by eye.
What was changed
The content model was migrated to the built-in translation mechanism: one piece of content with language versions instead of a set of copies.
The links between versions are now managed by the system, not the editor — when the source content is updated, the translation is marked as outdated and enters a queue for updating.
Language tags are assembled automatically from the set of published translations, service URLs are closed to indexing, and the canonical URL points to the language version rather than to a shared template.
What it became
The share of duplicate pages in the index dropped from 38% to 2% — only deliberate exceptions for similar materials remained. Translation publication time was reduced from 6 days to a few hours: the editor works with a single form rather than with copies.
Language tags are correct on 100% of checked pages, and mutual links between versions are no longer lost during updates.
A separate effect is predictability. Previously, no one could say how many materials were actually translated: copies diverged, and some existed without any link to the original.
Now the summary by language is built from the system itself, and gaps in translations are visible immediately rather than surfacing in complaints from regional teams.
How is entity translation different from interface translation?
In Drupal, these are two independent localization layers, and they must not be confused. Interface translation covers the strings generated by the system and modules themselves: field labels, buttons, emails, error messages.
They are stored separately from content and are pulled in at the page rendering stage. Entity translation covers the data itself: content items, taxonomy, menus, blocks, custom fields.
Here, each language version has its own set of values, its own publication date, and its own status.
The difference in approaches directly affects the structure. Interface strings do not create new nodes — a single record serves all languages, so adding a language does not bloat the database.
Entities, however, when translation is enabled, get a separate revision for each language: the English version of an article has its own URL alias, its own meta tags, its own attached files.
If you mix up the layers — for example, by creating an "English version" as a new content item instead of a translation — you will get duplicates in the sitemap, mismatched links, and desynchronization during updates.
In practice, this means different maintenance tactics. Interface strings are updated centrally: you fix one — it changes everywhere it is displayed.
Content translations are edited individually, and here it is important that the editor can see which version has become outdated after the source is edited.
At the start, we establish exactly what is translated as an entity and what as a string — this eliminates half of the future questions like "why is there old text on one page."
Field synchronization deserves separate mention. Values shared across all languages — for example, a SKU or an image — we move into non-translatable fields so they are not duplicated in each version. This keeps the structure flat, and the editor does not waste time on re-entering them.
Common technical concerns about multilingualism
Multilingualism is almost always implemented on a live site, not an empty one: content is already indexed, links have spread to external sources, and analytics have accumulated.
Therefore, the first question is not "how to enable a second language," but "how not to lose what is already ranking."
What should I do if the site is already deployed and generating traffic?
We add languages on top of the current structure without touching the URLs of the primary one. The base language stays on its existing paths, while new ones get a prefix — this way external links and accumulated signals are preserved.
Then we handle the technical side: we set up translation linking between materials, enable browser language detection with the option to switch manually, and verify that the switcher leads to the same material rather than the homepage. We also keep an eye on the sitemap: it must contain all language versions with correct tags.
How do I avoid duplicates and not lose rankings?
A duplicate occurs when language versions serve identical content or when a translation exists but is not linked to the original.
This is solved by linking translations at the material level and by correct language tags: each version points to itself and to all the others, including the base one.
If a translation is not ready yet, the page should not open with empty content — it is better to serve the base version with a language note than to spawn empty URLs that a search engine will treat as duplicates.
How do I check language tags and translation migration?
Checking language tags is a regular procedure, not a one-time setup: we verify that each version references the full set of alternatives, that the tags do not lead to non-existent URLs, and that the base language is specified correctly.
When migrating translations, we transfer not only the texts but also the links between versions — otherwise, after the move, materials break apart into independent pages, and the language tags have to be reassembled from scratch. We run the check before and after migration, comparing the number of linked pairs.
If your concern is not resolved — describe your structure and the current state of your languages, and we will get back to you with an assessment and a work plan.
Let's discuss the Drupal multilingual task
To come back with an estimate and a plan rather than generalities, we need to understand the current state of the project.
Send us access to the repository and configuration (configuration export, translation files, language detection settings) — we'll use them to conduct a multilingual audit and see where content is duplicated, how translation links are structured, and what's going on with hreflang.
- Site addresses and list of languages: which locales are active, whether there are language domains or subfolders, how the visitor's language is determined.
- How content is currently structured: translations via entity links, separate materials per language, or a shared template with translation fields.
- Translation sources: manual input, import files, external service — and who is responsible for synchronization.
- Current issues: duplicate pages in search results, "jumping" language, broken switchers, discrepancies in meta tags.
- SEO requirements: whether separate addresses are needed for each language, how canonical and hreflang should look.
- Constraints: deadlines, affected sections, integrations with external systems and catalogs.
After the audit, we'll come back with an estimate and a plan: we'll break the work into stages, specify implementation timelines and migration risks. If part of the content is already translated, we'll show how to migrate it without losing links and rankings. Describe the task — we'll discuss the details and propose a solution for your project.
