Что значит «мультиязычный проект»
Под мультиязычностью бизнес обычно понимает одно: «чтобы сайт был на нескольких языках». На практике за этой фразой скрывается связка из десятков отдельных решений: как размечать URL, как отдавать Google правильные версии страниц, как переводить не только тексты, но и меню, формы, кнопки, системные сообщения, как делать переводы частичными или полными, как управлять релизом на страны с разной юрисдикцией, и как держать всё это в одной редакционной системе, а не в четырёх параллельных.
Drupal сделан с учётом этих задач на уровне архитектуры ядра. Это не «плагин, приклеенный сверху», а встроенная мультиязычная модель, которая начинается с сущности Language и пронизывает все типы данных — от узлов и параграфов до пользователей, таксономии, системных сообщений и конфигурации вьюх.[1] Именно поэтому крупные многоязычные проекты — от государственных порталов ЕС до NASA и Всемирной продовольственной программы — исторически строятся на Drupal.
В этой статье разбираем, какие именно механизмы делают Drupal сильным выбором для мультиязычного проекта с несколькими доменами, что он умеет из коробки, где проигрывает альтернативам, и как выглядит корректная архитектура такого запуска.
Три уровня мультиязычности
Прежде чем сравнивать CMS, важно разделить задачу на слои. Большинство проблем мультиязычных проектов происходят там, где один из этих слоёв забывают или реализуют вручную.
Статьи, страницы услуг, карточки товаров, параграфы, таксономия, медиа. В Drupal переводится на уровне отдельных полей — можно перевести только заголовок и hero, оставив остальное общим.
Кнопки, подписи форм, сообщения об ошибках, пагинация, даты. Interface Translation подхватывает строки из модулей ядра, contrib и кастомных тем, позволяет редактировать через UI.
Меню, блоки, вьюхи, типы контента, названия полей, roles, email-шаблоны. Configuration Translation даёт редактору править версии конфига для каждого языка без правки кода.
Почему это важно
Если CMS работает только с контентом, а интерфейс и конфигурация переведены жёстко через файлы темы — любое добавление нового меню, вьюхи или блока превращается в задачу разработчика. В Drupal все три слоя редактируются одним и тем же редактором, без деплоя.
Четыре архитектуры URL и доменов
Google рассматривает четыре способа размещения языковых/региональных версий сайта, у каждого — свои сильные и слабые стороны.[2] Выбор архитектуры определяет и техническую сложность, и поведение в поиске.
Подпапки /ru/, /en/
Старт
Поддомены en.example.com
Средне
Страновые TLD example.de
Средне
Multi-domain на одном ядре
DrupalПринципиальное отличие Drupal — он поддерживает все четыре сценария на одном движке без смены платформы. Переезд между архитектурами (например, с подпапок на отдельные домены) — это настройка, а не рефакторинг.
Что Drupal делает из коробки
Ниже — ключевые модули, которые формируют мультиязычный контур Drupal. Первые четыре входят в ядро и включаются «из панели администратора», остальные — стабильные contrib-модули из экосистемы, которые нужны почти любому мультиязычному проекту.
Language (ядро)
Включает мультиязычную модель. Позволяет добавить любое количество языков, выбрать стратегию определения (URL-префикс, поддомен, cookie, Accept-Language, сессия), задать fallback-язык.
Content Translation (ядро)
Переводит контент по сущностям и полям: узлы, параграфы, медиа, таксономия, блоки, пользователи. Поддерживает частичные переводы, версии черновиков, отслеживает «устаревшие» переводы при правке исходника.
Interface Translation (ядро)
Управляет строками интерфейса: кнопки, подписи, формы, системные сообщения. Импорт .po из локалей Drupal, локальные переопределения, строки из контриба и темы — всё в одном экране.
Configuration Translation (ядро)
Переводит конфигурацию: меню, блоки, отображение view, email-шаблоны, названия полей, типов контента, ролей. Меню «Услуги» становится «Services» не переключателем в теме, а переводом конфига.
Metatag
Per-language meta description, title, OG-теги, Twitter Cards, canonical, robots. Задаётся шаблонами по типам контента и переопределяется для отдельных страниц — всё это мультиязычно.[3]
Simple XML Sitemap
Sitemap с автоматическими hreflang-альтернатами: каждая запись URL сопровождается ссылками на все языковые версии. Отдельные sitemap per domain, автогенерация index, инкрементальное обновление.
Pathauto + Language token
URL-алиасы per language — /uslugi/seo на русском и /services/seo на английском из одного паттерна с токеном языка. Редактор не задаёт алиасы вручную — они генерируются из заголовка по правилам.
Domain Access
Несколько доменов на одной установке. Каждый узел принадлежит одному или нескольким доменам, можно настраивать per-domain меню, блоки, темы. Работает поверх мультиязычности — один узел может быть на двух языках и трёх доменах.[4]
Сравнение: Drupal vs WordPress vs Bitrix vs Tilda
Сравниваем четыре платформы по ключевым параметрам, которые определяют стоимость и качество мультиязычного проекта с несколькими доменами. В WordPress считаем связку с платным плагином WPML, без которого мультиязычность ограничена.
| Параметр | Drupal | WordPress + WPML | 1C-Bitrix | Tilda |
|---|---|---|---|---|
| Мультиязычность в ядре | Да, 4 модуля | Нет, плагин | Частично | Нет |
| Перевод полей | Per-field | На уровне записи | Через инфоблоки | Дубль страницы |
| Автоматический hreflang | Из коробки | Через плагин | Вручную | Вручную |
| Перевод меню/блоков/вьюх | UI для редактора | Только через WPML | Вручную по языкам | Дубль |
| Multi-domain в одном ядре | Domain Access | Multisite + WPML | Многосайтовость | Только отдельные аккаунты |
| Стоимость лицензий/плагинов | 0 (open source) | ~$199/сайт/год (WPML) | От 60 000 ₽/редакция | Подписка за страницы |
| Редакционный workflow per-language | Content Moderation, статусы | Через плагин | Настраивается | Нет |
| Интеграция с translation services | TMGMT, Lingotek | WPML + TMS-интеграции | Своими силами | Нет |
| Масштаб (50+ языков) | Проверено на ЕС-порталах | Тяжело, но возможно | Не предназначен | Не предназначен |
| Sitemap per-domain + hreflang | Simple XML Sitemap | Yoast/Rank Math + ручная настройка | Ограничено | Без alternates |
Вывод по таблице. На простых задачах (2 языка, 1 домен, небольшой контент) разница между платформами не критична. На задачах уровня «4–6 языков × 2–3 домена × сотни страниц × редакционный workflow» Drupal выигрывает принципиально — именно эту конфигурацию он проектировался поддерживать.[5]
SEO-преимущества для мультиязычного проекта
SEO на мультиязычном сайте — это не только контент. Это ещё и корректная техническая разметка, чтобы Google и Яндекс понимали, какая страница какой аудитории предназначена. Ошибки здесь стоят дорого: два языка могут начать конкурировать за одну выдачу, canonical указывает на неправильную версию, пользователи из Германии видят английскую страницу вместо немецкой.
Что Drupal делает автоматически
Для каждой переведённой страницы: тег <link rel="alternate" hreflang="xx" href="..."> на все языковые версии, корректный canonical, lang-атрибут в <html>, правильный язык метаданных (og:locale, og:locale:alternate). Редактор не размечает это вручную — модель данных сама знает, какая страница какому языку соответствует.
Где ошибаются другие CMS
Типичные проблемы платформ без нативной мультиязычности: hreflang проставляется только на часть страниц, canonical ссылается на исходный язык вместо текущего, в sitemap alternates пропущены, языковой switcher переключает на главную вместо той же страницы в другом языке.[6] Всё это — потеря трафика и индексации.
Multi-domain на одном ядре
Сценарий типичного международного проекта: один бренд, несколько доменов (brand.com, brand.de, brand.pl), на каждом — свой набор языков и часть контента. Новости и статьи шарятся между доменами, карточки услуг — только в релевантных странах, цены и юридические тексты — свои на каждом.
На Drupal эта конфигурация реализуется двумя путями:
Несколько независимых установок
Каждый домен — отдельная установка Drupal с общим ядром. Плюс — полная изоляция, возможность разных тем и настроек. Минус — контент не шарится между сайтами из коробки, редакторы работают в разных админках, обновления модулей тестируются на каждом сайте отдельно. Подходит, когда сайты концептуально разные.
Один Drupal, несколько доменов
Один админ, одна база, одна установка. Каждый узел принадлежит выбранным доменам. Общий редакционный workflow, общий пул контента с переопределением по доменам. Per-domain настройка меню, темы, блоков, URL-алиасов. Работает поверх мультиязычности — немецкая страница на brand.de и английская на brand.com живут в одной сущности.
Как это работает в связке
Node с полем «цена» может иметь версию на русском и английском, и одновременно — разные значения поля для brand.com и brand.de. В итоге у редактора один интерфейс, у SEO — корректные hreflang и canonical, у бизнеса — один контур управления вместо трёх разрозненных сайтов.
Типичные ошибки мультиязычных сайтов
Сравним наиболее частые ошибки, которые встречаются на мультиязычных проектах на других платформах, с тем, как эти же задачи решает корректно настроенный Drupal.
Как ломают SEO
Один и тот же title/description на всех языках. Canonical указывает на английскую версию со всех языков (каннибализация). Hreflang расставлены частично или с опечатками в кодах стран. Языковой switcher ведёт на главную. Sitemap без alternates. 301-редиректы по Accept-Language ломают индексацию. Меню переведено, а названия пунктов берутся из темы и остаются на английском.
Как сделано в Drupal
Meta-шаблоны per-language через Metatag. Canonical ссылается на текущий язык, hreflang — на все альтернативы. Switcher использует entity-relations и ведёт на ту же страницу в другом языке. Simple XML Sitemap добавляет alternates автоматически. Определение языка по URL + cookie (без принудительных редиректов). Interface Translation гарантирует перевод всех UI-строк, включая тему и модули.
Чек-лист запуска
7 шагов правильного запуска мультиязычного Drupal-проекта
- Определите целевые языки и страны до ТЗ на сайт. Список языков влияет на структуру URL, выбор домена (подпапка/поддомен/TLD) и дизайн (длина строк в меню, направление текста для RTL).
- Выберите архитектуру URL заранее. Подпапки для старта и простой SEO-консолидации, домены уровня страны — если приоритет локальный таргетинг. Смена архитектуры после релиза — болезненный процесс с редиректами.
- Решите, что перевод полный, а что частичный. В Drupal можно переводить отдельные поля — это полезно, когда каталог услуг общий, а посадочные страницы локализованы. Планируется на этапе контент-модели, не после релиза.
- Включите все четыре языковых модуля ядра. Language, Content Translation, Interface Translation, Configuration Translation. Это база, без которой Drupal работает как обычная одноязычная CMS.
- Настройте Metatag и Simple XML Sitemap сразу. Per-language шаблоны meta, canonical и sitemap с hreflang-альтернатами должны быть готовы до первой индексации.
- Определите контент, общий для доменов. Что шарится (новости, политика конфиденциальности) и что уникально для каждого домена (каталог, цены, юр. реквизиты). От этого решения зависит выбор между Domain Access и мультисайтом.
- Спроектируйте редакционный workflow. Кто переводит, кто ревьюит, как отслеживаются «устаревшие» переводы после правок исходника. Content Moderation + рабочие статусы «нужен перевод / в работе / готово».
Практика ONTOP
На проектах ONTOP мы работаем с мультиязычными Drupal-инсталляциями полного цикла: от выбора архитектуры URL и доменов до настройки Metatag, Simple XML Sitemap, Domain Access и интеграции со сторонними переводческими сервисами через TMGMT. Редакторы получают единый интерфейс, SEO-специалисты — автоматически корректные hreflang и canonical, бизнес — возможность масштабировать проект на новые языки и страны без смены платформы.
Подробнее про связанные процессы: единое агентство вместо нескольких подрядчиков, почему «сначала сайт, потом маркетинг» — это переделка, разработка сайтов на Drupal, SEO-продвижение.
Планируете мультиязычный проект или миграцию на Drupal? Получите бесплатную оценку архитектуры — покажем, какие модули понадобятся, как спроектировать URL и где возникнут точки сложности.
Обсудить проектFAQ
Drupal сложнее WordPress — не переплатим ли мы за внедрение?
На простых одноязычных сайтах WordPress действительно обходится дешевле на старте. На мультиязычных проектах с несколькими доменами картина меняется: WPML требует отдельной лицензии, ручной настройки hreflang в нескольких плагинах, и всё равно не покрывает перевод меню/виджетов так же чисто, как Drupal. В 12–18 месяцев TCO Drupal обычно оказывается ниже именно за счёт отсутствия плагинной цепочки.
Нужен ли Domain Access, если доменов всего два?
Не всегда. Если два домена — это разные языки одного бренда и контент общий, достаточно одного Drupal с подпапками или поддоменами. Domain Access нужен, когда сайты должны отличаться по контенту (каталог, цены, юр. реквизиты) и редакторы хотят управлять всем из одной админки. Для бизнес-сценариев «RU + EN одного и того же» Domain Access — избыточен.
Как Drupal работает с переводами, если их делает внешнее агентство?
Через модуль TMGMT (Translation Management Tool): можно выгружать контент в XLIFF или подключать API переводческих сервисов (Lingotek, Smartling, ModernMT). Drupal отслеживает статус перевода, автоматически импортирует готовые версии и помечает «устаревшие» при правке исходника. Ручная работа редактора сводится к проверке и публикации.
Как выбрать между подпапками и отдельными доменами?
Правило большого пальца: подпапки — если бизнес международный, но нет сильной локальной привязки, и контент пересекается. Отдельные страновые TLD — если вы хотите максимальный сигнал локального таргетинга для Google, и готовы накапливать SEO-вес на каждом домене с нуля. Промежуточный вариант — поддомены на общем TLD с настройкой геотаргетинга в Search Console.
Что делать с RTL-языками (иврит, арабский)?
Drupal поддерживает RTL на уровне ядра: тема автоматически переключает направление текста, меню и верстка зеркалируются. Единственное, что требуется — корректно подготовленная тема с RTL-стилями (большинство качественных тем поддерживают RTL из коробки). Контент и интерфейс — в том же редакторе, без отдельных инструментов.
Можно ли добавить новый язык через год после запуска без переделки?
Да. Drupal проектировался под расширение набора языков: добавление нового — это включение в админке и перевод существующего контента. URL-схема, hreflang, sitemap, meta-шаблоны автоматически подхватят новый язык. Переверстывать ничего не нужно. Это ключевое отличие от CMS, где каждая новая локализация — отдельный проект.
Как обстоит с кешированием на мультиязычном + multi-domain сайте?
Drupal использует cache contexts: ключи кеша автоматически разделяются по языку и домену. Одна и та же страница на русском под brand.com и на немецком под brand.de кешируются как отдельные записи. При правильной настройке BigPipe, Dynamic Page Cache и внешнего CDN (Varnish / nginx fastcgi) производительность не проседает.
Выводы
Мультиязычный проект — это не задача «добавить переключатель языков в шапку». Это задача архитектуры, которая пронизывает контент, интерфейс, конфигурацию, URL, SEO-разметку, кеширование и редакционный workflow. Выбор CMS здесь — стратегическое решение, которое влияет на стоимость владения в течение нескольких лет.
Drupal — одна из немногих платформ, где мультиязычность заложена на уровне ядра, а не собрана из плагинов. Это проявляется в мелочах: автоматическом hreflang, корректном canonical, переводе меню и конфигурации через UI, работе Domain Access поверх мультиязычной модели, интеграции с переводческими сервисами. На проектах уровня «3+ языков × 2+ доменов × полноценный редакционный процесс» это даёт заметную экономию — и денег, и редакторского времени.
Если проект сразу проектируется как международный, Drupal почти всегда — самый предсказуемый выбор. Если же старт ограничен одним языком и одним доменом, но в перспективе — выход на новые рынки, Drupal даёт возможность начать просто и масштабироваться без смены платформы.
Источники
- Drupal.org — Multilingual guide — официальное руководство по мультиязычной модели Drupal: языки, перевод контента, интерфейса и конфигурации.
- Google Search Central — Localized versions of your pages — официальная документация по hreflang, canonical и архитектурам URL для мультиязычных и мультирегиональных сайтов.
- Drupal.org — Metatag module — модуль для управления мета-тегами, включая мультиязычные шаблоны title, description, canonical, Open Graph.
- Drupal.org — Domain Access project — модуль для управления несколькими доменами на одной установке Drupal с общим или разделённым контентом.
- Moz — International SEO guide — практическое руководство по SEO мультиязычных и мультирегиональных сайтов, архитектура URL, hreflang, распространённые ошибки.
- Google Search Central — Multi-regional and multilingual sites — официальные рекомендации Google по разметке и индексации сайтов с несколькими языками и регионами.