Зачем вообще нужна мультиязычность (и когда она не нужна)

Первый вопрос, который стоит задать: «А точно нужен сайт на нескольких языках?» Иногда мультиязычность хотят «на всякий случай» или «потому что у конкурентов есть».

Мультиязычный сайт имеет смысл, когда:

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

Если же весь трафик идёт из одного региона и на одном языке — не усложняйте. Лучше потратьте бюджет на качественный контент для своей аудитории.

Три варианта структуры: поддомены, подкаталоги или отдельные домены

Это, наверное, самый частый вопрос в мультиязычной разработке. Однозначного ответа нет — выбор зависит от конкретной ситуации.

Подкаталоги — выбор по умолчанию

Структура вида `example.com/en/`, `example.com/de/`, `example.com/ru/`.

Для большинства проектов оптимальны именно подкаталоги. Причин несколько. Во-первых, весь ссылочный вес концентрируется на одном домене. Вы не «размазываете» авторитетность сайта по нескольким адресам. Во-вторых, это проще в обслуживании: один хостинг, один SSL-сертификат, одна админка.

Ещё один плюс — масштабируемость. Когда через полгода нужно добавить ещё один язык, достаточно создать новую папку с локалью. Не нужно поднимать отдельный сервер или покупать домен.

Если вы работаете с Next.js, подкаталоги — это нативная стратегия. В App Router достаточно создать динамический сегмент `[locale]` в структуре `app/`, и роутинг работает из коробки.

Поддомены — для крупных проектов с разными командами

Структура вида `en.example.com`, `de.example.com`.

Поддомены хороши, когда у каждой языковой версии — своя редакция или своя команда разработчиков. Крупные медиа и маркетплейсы часто идут этим путём, потому что им нужна автономия: разный контент, разная логика, иногда даже разный стек.

Но для типичного бизнес-сайта или стартапа это избыточно. Google формально воспринимает поддомены как отдельные сайты, и каждый из них нужно продвигать с нуля.

Отдельные домены (ccTLD) — максимальный локальный сигнал

Структура вида `example.ru`, `example.de`, `example.com`.

Национальные домены верхнего уровня дают самый сильный сигнал поисковым системам о географической привязке. Но это самый дорогой и сложный в поддержке вариант. Каждый домен — отдельная сущность: свой хостинг, свой SSL, своя история в поисковых системах. Для подавляющего большинства проектов это overkill.

ccTLD рекомендуется только тем, кто серьёзно работает на конкретный рынок и готов вкладываться в продвижение каждого домена отдельно.

Настройка hreflang: почему это важнее, чем кажется

Теперь к технической части, которая у многих вызывает головную боль. Атрибут `hreflang` — это способ сообщить поисковым системам, какая версия страницы предназначена для какого языка и региона.

Без hreflang поисковик может решить, что ваши языковые версии — это дубликаты одного и того же контента. В результате в индекс попадает только одна версия, а остальные просто «висят» без трафика. На практике это встречается часто — русская версия сайта ранжируется в Google для англоязычных запросов, а английская вообще не попадает в выдачу.

Базовый синтаксис

В `<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="de" href="https://example.com/de/about/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/about/" />

Ключевые правила работы с hreflang:

Каждая страница ссылается на все версии, включая себя. Это обязательное условие. Если на русской странице указана ссылка на английскую, но на английской забыли указать русскую — связь не подтверждена, и поисковик её проигнорирует. Google и Яндекс оба требуют двустороннюю (взаимную) разметку.

Используйте `x-default` для дефолтной версии. Это значение указывает, какую страницу показывать пользователям, чей язык не совпадает ни с одной версией. Обычно `x-default` ставится на английскую версию, но бывают исключения.

Коды языков — строго по ISO 639-1, коды регионов — по ISO 3166-1 Alpha-2. То есть `en`, `ru`, `de` для языков, `en-US`, `en-GB`, `pt-BR` для языково-региональных комбинаций. Самая частая ошибка — использование кодов вроде `eng` или `rus` вместо двухбуквенных.

URL должны быть абсолютными. Не `/en/about/`, а `https://example.com/en/about/`. Относительные пути поисковые системы не поймут.

Три способа внедрения hreflang

Можно прописать ссылки в HTML-теге `<link>` в `<head>` страницы (как в примере выше). Это самый распространённый способ, и для большинства сайтов его достаточно.

Второй вариант — HTTP-заголовки. Это полезно для файлов, у которых нет HTML-разметки, например для PDF-документов:

Link: <https://example.com/en/file.pdf>; rel="alternate"; hreflang="en",
      <https://example.com/ru/file.pdf>; rel="alternate"; hreflang="ru"

Третий — XML-карта сайта с аннотациями `xhtml:link`. Этот способ удобен на крупных проектах, где страниц сотни или тысячи. Прописывать hreflang в `<head>` каждой страницы становится накладно, а в sitemap всё собирается в одном месте:

<url>
  <loc>https://example.com/ru/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/" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/about/" />
</url>

Смешивать способы внутри одного сайта не рекомендуется — это приводит к конфликтам и путанице. Лучше выбрать один и придерживаться его.

Как реализовать мультиязычность в Next.js

В 2026 году для проектов на App Router оптимальный выбор — библиотека next-intl. Она специально создана для Next.js, нативно работает с Server Components, а размер клиентского бандла — около 2 КБ.

Структура проекта выглядит примерно так:

app/
├── [locale]/
│   ├── layout.tsx
│   └── page.tsx
messages/
├── en.json
├── ru.json
└── de.json
middleware.ts
i18n/
└── request.ts

В `middleware.ts` настраивается определение локали по заголовкам запроса и редирект на нужную версию. В `layout.tsx` — обёртка `NextIntlClientProvider`, которая прокидывает переводы в клиентские компоненты.

Для генерации `hreflang`-тегов обычно пишется утилита в `layout.tsx`, которая автоматически подставляет ссылки на все языковые версии текущей страницы. Это избавляет от ручной работы и исключает ошибки.

Что касается переводов — они хранятся в JSON-файлах по локалям. Каждый файл разбит по неймспейсам (например, `common`, `home`, `about`), чтобы не тащить все переводы на каждую страницу.

Раньше, на Pages Router, использовалась библиотека next-i18next. Она до сих пор работает, но для новых проектов лучше брать next-intl — она лучше интегрирована с современным Next.js и не требует отдельного конфига для серверных компонентов.

Локализация — это не только перевод текстов

Типичная ошибка: перевели тексты и считают, что сайт локализован. На практике локализация — это гораздо больше.

Форматирование дат и чисел. В России пишут «11.03.2026» и «1 500,00 ₽», а в США — «03/11/2026» и «$1,500.00». Если на немецкоязычной версии сайта отображаются даты в американском формате — это сразу выглядит чужеродно.

Валюта и цены. Если вы продаёте что-то — показывайте цены в локальной валюте. Пользователь не должен в уме переводить доллары в евро.

Изображения и иконки. На некоторых рынках определённые визуальные элементы могут восприниматься по-разному. Не всегда это критично, но стоит об этом помнить.

Направление текста. Если среди ваших языков есть арабский или иврит — это RTL (right-to-left). Вся вёрстка должна быть зеркальной. В CSS для этого используются логические свойства: `margin-inline-start` вместо `margin-left`, `padding-inline-end` вместо `padding-right`.

Длина текстов. Немецкие слова в среднем длиннее английских на 30-40%. Если кнопка идеально вмещает слово «Submit», то «Absenden» ещё влезет, а вот «Подтвердить отправку» — уже может не поместиться. Закладывайте запас в интерфейсных элементах.

SEO для мультиязычного сайта: что ещё нужно учесть

Помимо hreflang, есть ряд вещей, которые стоит проверить на каждом мультиязычном проекте.

Атрибут `lang` в HTML. На каждой странице в теге `<html>` должен быть указан язык контента: `<html lang="ru">`, `<html lang="en">`, и так далее. Это не влияет напрямую на ранжирование, но помогает браузерам, скринридерам и различным инструментам правильно обрабатывать текст.

Канонические URL. Каждая языковая версия должна иметь свой собственный `canonical`, указывающий на саму себя. Не ставьте canonical русской страницы на английскую — это частая ошибка, которая приводит к деиндексации языковых версий.

Отдельные sitemap для каждой локали (или общий с hreflang-аннотациями). Предпочтительнее один общий sitemap с аннотациями — так проще контролировать и обновлять.

Уникальные [meta title и description](/blog/meta-tegi-title-i-description) для каждого языка. Не просто перевод, а адаптация под поисковые запросы на соответствующем языке. Ключевые слова на разных языках — это разные ключевые слова, с разной частотностью и конкуренцией.

Яндекс.Вебмастер — отдельная история. Если вы продвигаетесь в Яндексе, не забудьте указать регион сайта в панели вебмастера. Яндекс учитывает hreflang, но дополнительно ориентируется на свои собственные настройки региона.

Типичные ошибки и как их избежать

Вот самые частые ошибки, которые встречаются на мультиязычных проектах.

Односторонний hreflang. Страница A ссылается на B, но B не ссылается обратно на A. Поисковик видит несоответствие и игнорирует разметку. Проверяйте двустороннюю связь всегда.

Несуществующие URL в hreflang. Бывает, что страница на одном языке есть, а на другом — нет. Если в hreflang указана ссылка на страницу, которая возвращает 404 — вся цепочка ломается. Указывайте только реально существующие и доступные для индексации страницы.

Автоматический редирект по IP или языку браузера. Вроде бы логично — определить, что пользователь из Германии, и сразу перенаправить на немецкую версию. Но Googlebot обычно ходит из США с английской локалью. Если его принудительно перенаправляют — он никогда не увидит другие версии сайта. Вместо редиректа лучше показывать баннер с предложением переключить язык.

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

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

Инструменты для проверки

После настройки стоит прогнать сайт через несколько инструментов:

  • Google Search Console — раздел «Международный таргетинг» покажет ошибки в hreflang-разметке. Плюс можно отследить, какие языковые версии попали в индекс.
  • Screaming Frog — умеет сканировать сайт и проверять hreflang на корректность связей между страницами.
  • Ahrefs Site Audit — тоже хорошо находит проблемы с hreflang.
  • Hreflang Tag Checker от Merkle — простой онлайн-инструмент для быстрой проверки одной страницы. Удобно для точечного контроля.

Чеклист перед запуском

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

  1. Все страницы каждой локали доступны и возвращают HTTP 200.
  2. Hreflang-разметка присутствует на всех страницах, связи двусторонние.
  3. Указан `x-default` для дефолтной версии.
  4. Атрибут `lang` в `<html>` соответствует языку контента.
  5. Canonical URL на каждой странице ведёт на саму себя.
  6. Sitemap содержит все языковые версии с корректными аннотациями.
  7. Нет принудительных редиректов по IP для поисковых ботов.
  8. Meta-теги (title, description) уникальны для каждой языковой версии.
  9. Форматирование дат, чисел и валют адаптировано под локаль.
  10. Переключатель языка работает корректно и доступен с любой страницы.

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