Запуск сайта на нескольких языках или для нескольких регионов — это не «положили рядом папку en». Без правильной структуры URL, hreflang и контентной стратегии вы получите дубли, перетекание трафика между версиями и упущенные позиции в локальных выдачах. Расскажем, как сделать правильно.
Структура URL: три варианта
Поддомены: ru.example.com, en.example.com. Чёткое разделение, можно вести разные кампании, разные хостинги. Минус — каждый поддомен набирает SEO-вес отдельно, общий бренд работает слабее.
Подкаталоги: example.com/ru/, example.com/en/. Все версии под одним доменом, общий SEO-вес, проще управление. Стандарт для мультиязычных корпоративных сайтов и e-commerce. Наш дефолтный выбор.
Параметры в URL (?lang=en) — антипаттерн. Яндекс и Google плохо индексируют такие версии, путают канонические URL. Не используйте.
hreflang: что это и как ставится
hreflang — атрибут, говорящий поисковику: «эта страница на русском для России, есть на английском для США, на немецком для Германии». Поисковик показывает пользователю версию для его региона.
Ставится в <head> каждой страницы для всех её локализованных версий, включая саму себя:
<link rel="alternate" hreflang="ru" href="https://example.com/ru/about" />
<link rel="alternate" hreflang="en" href="https://example.com/en/about" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/about" />
x-default — версия для пользователей, чей язык не подходит ни под одну из перечисленных. Обязательно её указывать.
Региональные коды
Самая частая ошибка — путать язык и регион. en — английский для всего мира, en-US — для США, en-GB — для Великобритании. ru — русский, ru-RU — русский для России, ru-KZ — для Казахстана.
Если контент одинаковый для всех русскоязычных — используйте ru. Если для разных стран отличается (валюта, доставка, юрлицо) — ru-RU, ru-BY, ru-KZ.
Валюта, доставка, юр.требования
Локализация — это не только перевод. Цены в локальной валюте, способы оплаты для региона (СБП в РФ, Kaspi в Казахстане), договор по местному праву, политика конфиденциальности на нужном языке.
Для проектов в России обязательно: текст на русском по умолчанию, политика обработки ПДн под 152-ФЗ, согласие на обработку при отправке формы. Английская версия может ссылаться на ту же политику в переводе, но первичный документ — русский.
Реализация в Next.js 15
Стандартный подход — App Router с динамическим сегментом [locale]. Структура:
app/[locale]/page.tsx
app/[locale]/products/[slug]/page.tsx
generateStaticParams возвращает список локалей: [{ locale: 'ru' }, { locale: 'en' }]. Middleware определяет локаль из Accept-Language или cookie и редиректит, если URL без префикса.
Тексты — в JSON-словарях, подгружаются через next-intl или собственный хук. Картинки и медиа могут быть общими или per-locale (например, разные баннеры для России и Беларуси).
Sitemap для мультирегионального сайта
Sitemap должен включать все языковые версии. Каждый URL сопровождается тегом <xhtml:link rel="alternate"> с ссылками на остальные локали:
<url>
<loc>https://example.com/en/about</loc>
<xhtml:link rel="alternate" hreflang="ru" href="https://example.com/ru/about" />
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/about" />
</url>
В Next.js функция app/sitemap.ts генерирует это автоматически по списку страниц и локалей.
Распространённые ошибки
Перевод через автоматический Google Translate в meta-тегах — антипаттерн. Поисковики распознают и понижают такие страницы. Если бюджет на переводчика нет, лучше иметь сайт только на русском.
Hreflang ссылается на страницу, которой нет (404) или которая редиректит обратно. Поисковик игнорирует группу. Проверяйте через Yandex Webmaster и Google Search Console раз в неделю.
Канонический URL ссылается на другую языковую версию. Канонический должен быть такой же локали, как страница. Hreflang отдельно, canonical отдельно.
Контент: переводить или адаптировать
Машинный перевод подходит для каталогов товаров, где главное — характеристики. Для маркетинговых текстов, статей и оффера лучше адаптация под носителем языка. Это дороже (300–600 рублей за 1000 знаков), но окупается конверсией.
Юридические тексты, оферту, политику — только профессиональный перевод с проверкой у юриста в локальной юрисдикции. Машинный перевод оферты — это потенциальная судебная ошибка.
Итого
Мультирегиональный сайт — это структура URL (подкаталоги предпочтительнее), hreflang на каждой странице, валидный sitemap, локализованный контент с учётом валют, оплат и законов. Next.js 15 даёт удобный фреймворк через [locale], но финальное качество — это работа переводчика, юриста и SEO-специалиста, не разработчика.
Частые вопросы
Какую структуру URL выбрать для мультиязычного сайта?
Три варианта. Поддомены (ru.example.com, en.example.com) — чёткое разделение, но каждый поддомен набирает SEO-вес отдельно. Подкаталоги (example.com/ru/, example.com/en/) — все версии под одним доменом, общий SEO-вес, проще управление, дефолтный выбор для большинства проектов. Параметры в URL (?lang=en) — антипаттерн, поисковики плохо индексируют. Подкаталоги предпочтительнее в 90% случаев.
Как правильно ставить hreflang на сайте?
hreflang говорит поисковику: «эта страница на русском для России, есть на английском для США». Поисковик показывает пользователю версию для его региона. Ставится в head каждой страницы для всех её локализованных версий, включая саму себя. x-default — версия для пользователей, чей язык не подходит ни под одну из перечисленных, обязательно её указывать. Без правильного hreflang поисковик может показать неправильную локаль в выдаче.
Как правильно использовать региональные коды языка?
Самая частая ошибка — путать язык и регион. en — английский для всего мира, en-US — для США, en-GB — для Великобритании. ru — русский, ru-RU — русский для России, ru-KZ — для Казахстана. Если контент одинаковый для всех русскоязычных — используйте ru. Если для разных стран отличается (валюта, доставка, юрлицо) — ru-RU, ru-BY, ru-KZ. Это критично: неправильный код заставит поисковик показывать не ту версию пользователю.
Что нужно локализовать кроме текстов?
Локализация — это не только перевод. Цены в локальной валюте, способы оплаты для региона (СБП в РФ, Kaspi в Казахстане), договор по местному праву, политика конфиденциальности на нужном языке. Для проектов в России обязательно: текст на русском по умолчанию, политика обработки ПДн под 152-ФЗ, согласие на обработку при отправке формы. Английская версия может ссылаться на ту же политику в переводе, но первичный документ — русский.
Как реализовать мультиязычность в Next.js 15?
Стандартный подход — App Router с динамическим сегментом [locale]. Структура: app/[locale]/page.tsx, app/[locale]/products/[slug]/page.tsx. generateStaticParams возвращает список локалей. Middleware определяет локаль из Accept-Language или cookie и редиректит, если URL без префикса. Тексты в JSON-словарях, подгружаются через next-intl или собственный хук. Картинки и медиа могут быть общими или per-locale (например, разные баннеры для России и Беларуси).
Можно ли использовать машинный перевод для локализации?
Машинный перевод подходит для каталогов товаров, где главное — характеристики. Для маркетинговых текстов, статей и оффера лучше адаптация под носителем языка. Это дороже (300–600 рублей за 1000 знаков), но окупается конверсией. Юридические тексты, оферту, политику — только профессиональный перевод с проверкой у юриста в локальной юрисдикции. Машинный перевод оферты — это потенциальная судебная ошибка. Перевод через автоматический Google Translate в meta-тегах — антипаттерн, поисковики распознают и понижают.