Собственный проект · Технический разбор
Два домена и две локали в одном Next.js-приложении
Разбор архитектуры Web/Brand: общий интерфейс, русская и английская версии по домену, metadata и риски смешения контента.
Задача: сохранить общую основу двух версий
У двух языковых версий часто совпадают меню, карточки услуг, компоненты формы и визуальная система. Если скопировать весь сайт, исправление общей ошибки придётся повторять, а со временем версии начнут расходиться случайным образом. В исходном Web/Brand интерфейс и серверные модули общие, а тексты и параметры сайта собраны в отдельных словарях.
Речь идёт о двух доменах одного Brand-приложения. Сайт сопровождения Web/Admin — самостоятельный проект. Объединение всех направлений в один процесс из этой схемы не следует.
Как запрос превращается в нужную версию
Серверная функция getContent получает заголовки запроса и определяет локаль по имени хоста. Для web-brand.site выбирается английский словарь, для основного русского домена — русский. Компоненты получают один и тот же тип данных: меню, заголовки, услуги, контакты и SEO-поля.
В коде также есть принудительный выбор через SITE_LOCALE. Такой параметр полезен для локальной проверки и отдельных процессов развёртывания. Но при проверке доменного поведения его нужно учитывать: переменная окружения имеет приоритет над заголовком хоста.
Что действительно переиспользуется
Общими остаются визуальные компоненты, стили и механизм заявки. Словарь определяет язык подписи кнопки и текст ошибок. Это позволяет проверять поведение формы в одном месте, сохраняя отдельные формулировки для аудитории каждой версии.
При этом один код не требует одинаковых коммерческих страниц. Новые русские технические разборы доступны только в русской версии. На английском домене они должны возвращать 404 и не попадать в его sitemap, пока не подготовлена полноценная английская редакция. Иначе поисковик и посетитель получат русскую страницу под английским адресом.
Metadata — часть той же доменной логики
В корневом layout metadataBase, title, description и Open Graph зависят от выбранного словаря. У отдельных страниц есть собственный canonical. Это связывает содержимое страницы и адрес, который она предлагает поисковику считать основным.
Для действительных языковых пар применимы ссылки alternate. Но объявлять английский эквивалент для страницы, которой там нет, неправильно. Поэтому новый раздел разборов имеет русский canonical и не заявляет несуществующий перевод. Само наличие metadata не гарантирует индексацию или место в выдаче.
Компромиссы общей кодовой базы
Преимущество — общую правку не нужно вручную переносить между копиями. Риск тот же: изменение компонента способно повлиять на обе версии. Даже если публикуется только русский сайт, английские ветви кода не стоит случайно ломать. Нужны ограничения области публикации и проверки разных локалей.
У привязки к Host есть и эксплуатационные требования: reverse proxy должен передавать ожидаемое имя хоста, а процесс не должен случайно принуждать неверную локаль. Проверка только localhost этого не покажет. Для приёмки требуется запрос с реальным или явно заданным доменным контекстом.
Что проверять перед выпуском
Я бы проверял три слоя: видимый язык и ссылки, серверную доменную логику и поисковые метаданные. Для каждой доступной страницы — один ожидаемый H1, правильный canonical, соответствующий словарь и корректные ссылки навигации. Для отсутствующего перевода — 404, отсутствие в sitemap и отсутствие alternate на него.
Этот разбор показывает рабочий принцип разделения общих механизмов и содержания. Для нового проекта решение нужно выбирать по требованиям: отдельные домены, языковые пути или независимые приложения имеют разную цену сопровождения. Сначала стоит определить аудитории и будущие изменения, затем выбирать устройство кода.
Обсудить похожую задачу
Покажите проблему и желаемый результат. Если причина скрыта в коде, сначала согласуем диагностику и её границы.
Создание и реконструкция веб-проекта →