Архитектура доменов для мультиязычных сайтов: поддомены, подкаталоги или отдельные домены

Выбор архитектуры доменов для мультиязычного проекта влияет на всё: SEO и геотаргетинг, скорость и кэширование, SSL и безопасность, аналитику и операционные расходы, масштабирование команд и релизные процессы. Ошибка на старте тянет долгие миграции, цепочки 301 и просадки в органике. Ниже — практическое сравнение вариантов и набор проверенных рекомендаций.

Три базовых варианта

Схемы размещения локалей:

• Подкаталоги: example.com/ru/, example.com/en/
• Поддомены: ru.example.com, en.example.com
• Отдельные домены: example.ru, example.fr, example.de

Формально все три подхода валидны. Решение принимаем по совокупности факторов: SEO-консолидация ссылочного, требования к геотаргетингу, бренд и маркетинг в каждой стране, сложность инфраструктуры, политика безопасности, бюджет на продвижение и поддержку.

Критерии выбора: что важнее для вашего проекта

1) SEO и консолидация ссылочного

• Подкаталоги — максимум «суммирования» сигналов на одном домене: ссылки, поведенческие, авторитет бренда. Проще быстрее нарастить видимость всех локалей.
• Поддомены — поисковики часто трактуют как отдельные сайты. Сигналы частично перетекают, но эффекта «единого домена» меньше. Нужна аккуратная склейка через релевантные внутренние ссылки и корректный hreflang.
• Отдельные домены — полностью отдельные проекты. Придётся строить ссылочное и экспертизу заново для каждой зоны. Плюс — можно выиграть локальное доверие и CTR, особенно для национальных доменов.

2) Геотаргетинг и соответствие локальным рынкам

• Отдельные домены, особенно национальные, дают сильный сигнал «страна». Удобнее локализовывать цены, валюту, юридические блоки, налоги.
• Поддомены позволяют настраивать геотаргетинг по каждому хосту отдельно и держать независимые контенты/акции.
• Подкаталоги дают слабейший «страна-сигнал», но достаточны, если отличия в контенте минимальны и сайт международный по природе.

3) Маркетинг и бренд

• Отдельные домены — сильная локальная идентичность, лучше запоминаются и повышают доверие в стране.
• Поддомены — заметная привязка к главному бренду и одновременно чистое разделение локалей.
• Подкаталоги — единый бренд, но меньше «локального» эффекта в рекламе и офлайне.

4) Архитектура, SSL и безопасность

• Подкаталоги — один сертификат на домен. Минимум бюрократии и автоматизации. Проще HSTS и единые политики. Для старта это комфортно даже на виртуальный хостинг.
• Поддомены — удобно прикрывать wildcard-сертификатом. Важно учитывать HSTS с includeSubDomains: ошибка на главном домене мгновенно аффектит все локали. Для автоматизации выпуска wildcard-сертификатов см. материалы по DNS-01 и автообновлению wildcard SSL.
• Отдельные домены — больше сертификатов и автоматизации выпуска/продлева. Больше CAA-записей, отдельные политики безопасности и независимые HSTS. Для оформления и поддержки доменов используйте регистрацию доменов.

5) Эксплуатация: DNS, CDN, кэш, релизы

• Подкаталоги — единый CDN-воркфлоу и кэширование по путям. Проще общая статика, сложнее изолировать сброс кэша для одной локали, если всё лежит под одним хостом.
• Поддомены — гибкая маршрутизация: разные origin, разные CDN-настройки, отдельный кэш и политики безопасности на каждый хост. Удобно выделять отдельные окружения на VDS по странам.
• Отдельные домены — максимальная изоляция (DNS, CDN, WAF), но и максимальная операционная нагрузка: больше зон, больше точек отказа, больше мониторинга.

6) Cookies, SSO, CORS

• Подкаталоги — общий домен означает простое шаринг-cookie для авторизации. Удобно для SSO и корзины.
• Поддомены — можно выставлять домен куки на .example.com, но учитывайте SameSite, Secure и политику кросс-сабдоменного доступа.
• Отдельные домены — кросс-доменное SSO требует протоколов авторизации (OAuth/OIDC), CORS и продуманной безопасности.

7) Аналитика и атрибуция

• Подкаталоги — простая сегментация по префиксу пути, минимальные потери атрибуции.
• Поддомены — отдельные представления/ресурсы в аналитике по хосту, плюс сквозная связка при необходимости.
• Отдельные домены — максимальная гибкость, но настройка кросс-доменного трекинга и атрибуции сложнее.

Когда выбирать подкаталоги

Подкаталоги — лучший старт для международного проекта, где продукт един, а отличия между локалями ограничены переводом интерфейса и части контента. Они дают:

• консолидацию SEO-сигналов и ускоренную индексацию новых локалей;
• простое внедрение и обслуживание: один домен, один SSL, единая политика безопасности;
• упрощённую аналитику и минимальные риски разъезда конфигураций.

Важные условия успеха:

• чёткая URL-иерархия: всегда /{lang}/ как первый сегмент, а не query-параметр;
• строгая каноникализация: одна страница — один канонический URL, любые вариации — 301 в канон;
• hreflang для всех языковых версий и x-default для страницы выбора языка;
• единый шаблон навигации и карта сайта с разбивкой по локалям.

Подкаталоги не оптимальны, если вы планируете отдельно выводить товары, цены, акционные предложения и юридические разделы для стран — тут вам пригодится независимость поддоменов или отдельных доменов.

Когда выбирать поддомены

Поддомены — компромисс между единым брендом и независимостью локалей. Это удобно, если:

• у локалей разные фичи, релизные циклы и команды;
• нужны разные инфраструктурные профили: иной origin, свой rate limit, различная политика кеширования;
• требуется независимая защита: изоляция WAF-правил, ограничение доступа, A/B в пределах страны.

Особые моменты:

• Wildcard SSL облегчает жизнь, но продумайте HSTS: includeSubDomains привяжет все поддомены к HTTPS. Любая ошибка в сертификате заблокирует доступ к локали.
• Куки между сабдоменами работают при домене .example.com, но проверяйте SameSite, Secure и ограничения браузеров.
• В аналитике заведите отдельные представления по каждому хосту и одно сводное для сквозных путей пользователя.

Когда выбирать отдельные домены

Отдельные домены оправданы, когда нужна максимальная локализация: локальные юридические требования, цены и валюты, методы оплаты, мощная офлайн-реклама с локальным доменом, строгий геотаргетинг. Плюсы:

• сильный локальный сигнал для поисковиков и пользователей;
• полная инфраструктурная изоляция и независимые политики безопасности;
• гибкость для локальных команд: собственные релизы, платёжные шлюзы, интеграции.

Минусы — цена и сложность:

• каждый домен требует отдельного SEO, контента, ссылок, поддержки;
• больше сертификатов, больше автоматизации, больше зон DNS и точек отказа;
• кросс-доменные сценарии (SSO, аналитика, корзина) сложнее и чувствительнее к ошибкам.

Если отдельные зоны — ваш путь, начните с подбора и резервирования имён в приоритетных странах, а затем оформите их через регистрацию доменов. Для защиты портфеля доменов пригодится чек-лист по брендовому зонированию: защита доменного бренда.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

Hreflang, canonical и структура URL

• Используйте языковые коды ISO, при необходимости — пары язык-страна: en, en-GB, en-US, ru, fr-FR.
• Не смешивайте языки и страны без нужды: если контент один и тот же для en-GB и en-US, не плодите две версии.
• Ставьте hreflang для каждой пары альтернатив и x-default для страницы выбора языка или глобальной версии.
• Canonical должен указывать на саму страницу той же локали. Не ставьте каноникал между языками.
• Выбирайте единообразие со слешем: либо везде /en/page/, либо /en/page. Консистентность важнее вкусов.
• Не используйте параметры ?lang= или куки для определения канонического языка: поисковики индексируют URL, а не состояние сессии.

<!-- Пример hreflang в <head> -->
<link rel="alternate" hreflang="en" href="/en/">
<link rel="alternate" hreflang="ru" href="/ru/">
<link rel="alternate" hreflang="x-default" href="/">

Редиректы и автоопределение языка

• Избегайте жёсткого георедиректа по IP. Он ломает индексацию, кэш и шэринг ссылок.
• Лучше мягкий сценарий: определили язык по Accept-Language — показали баннер-подсказку «Перейти на локальную версию?» без 302.
• Если редирект неизбежен, используйте 302/307 только для первой сессии и указывайте ссылку на оригинал.
• Стабильно отдавайте для каждого URL один и тот же язык, который зафиксирован в пути или хосте.

SSL, HSTS и сертификаты

• Подкаталоги — достаточно одного сертификата и единой политики HSTS на корневом домене.
• Поддомены — выбирайте: wildcard-покрытие для *.example.com или SAN-список конкретных хостов. При includeSubDomains тестируйте заранее, чтобы не «забетонировать» ошибку.
• Отдельные домены — автоматизация выпуска и продления обязательна. Следите за лимитами выдачи, CAA-записями и OCSP stapling.

Закрывайте трафик TLS и централизуйте выпуск через SSL-сертификаты. Для автоматизации wildcard полезна статья о DNS-01: автовыдача wildcard.

# HSTS в Nginx (включайте после полного перевода на HTTPS)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

DNS и CDN

• Подкаталоги — один хост упрощает обслуживание, но сложнее выборочно сбрасывать кэш по локали.
• Поддомены — удобно ввести разные источники и политику кэширования. Можно разнести по регионам.
• Отдельные домены — независимые зоны, ALIAS/ANAME для апекса при использовании CDN, отдельные политики безопасности.

Производительность и кэш

• Язык закладывайте в путь или хост, а не в параметр. Так кэши и CDN будут эффективно разделять объекты.
• Локализуйте статический контент на уровне путей /en/static/, /ru/static/ для точечного инвалида.
• HTTP/2 и HTTP/3 снимают большинство проблем с количеством доменов, но не отменяют накладных расходов TLS и DNS.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Юридические и контентные требования

• Локализуйте юридические разделы: политика конфиденциальности, договоры, возрастные ограничения — по требованиям страны.
• Чётко указывайте валюту и налоги на уровне локали.
• Разделяйте пользовательские соглашения и контактные данные офисов по странам.

Миграция между схемами без потери трафика

Переносить локали между подкаталогами, поддоменами и отдельными доменами можно безопасно, если соблюдать дисциплину.

• Карта соответствия URL 1:1. На каждый старый адрес должен быть ровно один новый.
• Постоянные редиректы 301 без цепочек и петлей. Сразу на финальный URL.
• Обновление hreflang и sitemap: новые адреса, валидная сетка альтернатив.
• Стабильные каноникалы на новых страницах. Без ссылок на старые адреса.
• Сохранение контента и метаданных: заголовки, разметка, structured data.
• Мониторинг 404/5xx, краулинг-ошибок, скорости ответа и глубины индексации после релиса.
• Держите редиректы не меньше 12 месяцев, особенно если сайт сезонный.

# Пример 301 в Nginx при переезде ru.example.com на example.com/ru/
return 301 https://example.com/ru$request_uri;

Выбор по сценариям: краткая «датакарта»

• Нужна единая глобальная репутация бренда, отличия в локалях минимальны — берите подкаталоги.
• Нужны независимые релизы и конфигурации по странам, но единый домен важен — поддомены.
• Максимальная локализация, локальные маркетинговые кампании, юридические отличия — отдельные домены.

Технический чек-лист при запуске

• URL-стратегия и соглашение об именовании: только латиница в slug, константный регистр, единый шаблон.
• hreflang на всех уровнях, x-default, валидность кодов языков и регионов.
• Строгая каноникализация и отсутствие дубликатов с www/без www, со слешем/без слеша.
• Единый дизайн навигации: переключатель языка ведёт на соответствующий URL той же страницы.
• Отданный Content-Language и корректная кодировка для каждой локали. Страницы ошибок локализованы.
• SSL везде, HSTS после прогрева, автоматизация обновления сертификатов.
• CDN-конфигурация по локалям, инвалидация кэша по путям/хостам.
• Аналитика: цели, воронки, кросс-доменный учёт при отдельных доменах.
• Мониторинг аптайма и производительности по регионам, алерты на рост 404/5xx и падение индексации.

Распространённые ошибки

• Определение языка через параметр или куки без URL. Боты не смогут индексировать альтернативы корректно.
• Редирект на «локальный язык» без возможности остаться на исходной версии.
• Смешение языков на одной странице, отсутствие hreflang и несогласованность каноникалов.
• Непродуманная HSTS-политика с includeSubDomains и preload, которая ломает доступ к тестовым субдоменам.
• Цепочки 301 и 302, потеря метаданных при миграциях, разъезд контента и заголовков.
• Одинаковые URL-структуры, но разные смыслы по странам (конфликты при синхронизации и аналитике).

Итог

Единого «правильного» ответа нет — есть соответствие архитектуры целям. Если нужна быстрая мультиязычность с минимальными издержками и максимальной консолидацией SEO — подкаталоги. Нужна изоляция конфигураций и больше гибкости — поддомены. Требуется глубокая локализация и сильный локальный бренд — отдельные домены. Заранее зафиксируйте стратегию URL, hreflang и каноникализации, продумайте SSL и HSTS, подготовьте план миграции и мониторинга — тогда архитектура усилит и продукт, и маркетинг.