Как правильно настроить локализацию в Next.js, чтобы не потерять трафик в Google
В блоге Habr-SEO вышел разбор, как в Next.js правильно настроить i18n, чтобы избежать SEO-дублей и обеспечить корректную индексацию языковых версий. Я прочитал это — и понял, что это не про техническую деталь, а про то, как сайт работает с аудиторией. И как он может терять выручку, если не учитывать, как поисковики видят локализацию.
О чём речь и почему я считаю это важным для бизнеса
Речь о том, как показывать разные языковые версии сайта так, чтобы Google их правильно понял. Не просто «перевести интерфейс», а сделать так, чтобы каждая версия — русская, английская, немецкая — была отдельной страницей с уникальным URL, metadata и hreflang-связями. Это не про красоту, а про то, кто видит ваш сайт в поиске. Если вы не сделаете это правильно, Google может не понять, что у вас есть версия на русском, и показывать ваш сайт только на английском — даже если вы в России. Или, хуже того, показывать две версии как дубли. Это не просто ошибка. Это — потеря трафика, который вы могли бы получить. Я считаю это важным, потому что зачастую владельцы сайтов думают: «а зачем нам другой язык?» — и не понимают, что даже если сайт на русском, он может не показываться в поиске, если структура не соответствует требованиям. А это — не технический сбой, а потеря выручки. Не позиций, а денег.
Как это устроено — что тут вообще происходит
Суть в том, что просто менять язык по cookie или настройкам браузера — это не работает для SEO. Googlebot не отправляет заголовок Accept-Language, и он не может понять, какой язык на странице. Поэтому он видит одну страницу, но с разным содержимым. Это вызывает дубли. Чтобы этого избежать, нужно, чтобы каждая языковая версия имела отдельный URL. Например: /en/search/music и /ru/search/music. При этом в HTML указывается lang="en" или lang="ru", а в метаданных — canonical и hreflang. hreflang — это ссылка, которая говорит: «эта страница на английском, а эта — на русском, и они — варианты одного материала». Это помогает поисковикам не считать дублями, а правильно индексировать. В Next.js это делается через App Router, где первый сегмент пути — [locale], и система проверяет, что значение допустимо (en, ru и т.д.). Если приходит /de/search — страница не загружается, а возвращается 404. Это важно: не пытаться показать язык по умолчанию, если он не в списке. Потому что иначе Google может запутаться. И в этом — ключ к правильной работе.
Что изменилось на рынке: как делали раньше и как делают сейчас
Раньше было проще: сайт на одном языке, и всё. Потом появился спрос на переводы. И начали делать «переключатель языка» — кнопка, которая меняла текст. Но при этом URL оставался один. Это было удобно для пользователя, но смертельно для SEO. Google не мог понять, что это разные версии. Теперь — другое. Рынок стал требовать не просто «перевод», а «полноценную локализацию». Это значит: отдельные URL, отдельные метаданные, отдельные canonical, связь через hreflang. И это не просто рекомендация — это требование. Google прямо говорит: «делайте отдельные URL». И если вы не делаете — вы рискуете потерять видимость. Раньше можно было «обмануть» поисковик, используя cookie. Сейчас — нельзя. Потому что Google стал более точным. А значит, те, кто не перешёл на правильную структуру, уже отстают. И не потому что сайт «сломался», а потому что он не виден там, где нужно.
Кому это касается и как понять, что это про ваш проект
Если ваш сайт показывает разный язык в зависимости от настроек браузера, cookie или местоположения — и при этом URL один и тот же, то это про вас. Если вы видите, что поисковик показывает ваш сайт только на английском, хотя вы в России и хотите привлекать русскоязычных клиентов — это про вас. Если у вас есть разделы, где контент на одном языке, а интерфейс — на другом — это тоже про вас. Особенно если вы работаете с международной аудиторией, даже если не думали об этом. Если у вас есть кнопка «переключить язык» — и она меняет только текст, а не URL — это точно про вас. Потому что вы, возможно, уже теряете трафик. Проверить можно просто: откройте страницу в браузере, смените язык, и посмотрите, изменился ли URL. Если нет — значит, поисковик видит дубль. А значит, вы не используете лучшую практику. Это не про технический изъян. Это про то, как сайт работает с каналами привлечения.
Что с этим делать — порядок действий в общем виде
Начинаем с аудита: проверяем, как сейчас устроена локализация. Есть ли у разных языков разные URL? Проверяем, есть ли hreflang, canonical, lang в HTML. Если нет — это проблема. Далее: определяем, какие языки нужны. Не обязательно все. Но если вы работаете с аудиторией на русском — нужно, чтобы русская версия была отдельной страницей с правильным URL. Затем: настраиваем маршруты. В Next.js это делается через [locale] в структуре каталогов. Делаем проверку на допустимые значения: только en, ru, de — и всё, что не в списке, возвращает 404. Дальше: генерируем статические маршруты для каждого языка. Это нужно, чтобы сборщик знал, какие страницы нужно собрать. Потом: настраиваем метаданные, canonical, hreflang — для каждой версии. И, главное: проверяем, что внутренние ссылки ведут с учётом языка. Если у вас ссылка /events/12345 — она может вывести пользователя в другую локаль. Нужно, чтобы все ссылки строились через функции, которые принимают locale. И, наконец: проверяем, как это работает в Google Search Console. Следим за индексацией. Это не разовая работа. Это часть архитектуры сайта.
Локализация — это не про перевод, а про видимость
Многие думают: «нам нужен перевод». А на деле — нужна правильная структура. Потому что даже если вы переведёте всё на русский, Google может не показать ваш сайт, если URL не указывает на русскую версию. Или может показать две версии как дубли. Это не техническая ошибка. Это потеря выручки. В таких проектах мы в Cetera начинаем с анализа структуры, а не с перевода. Потому что если архитектура не правильная — перевод не поможет. А если она правильная — перевод работает. Мы работаем с клиентами более чем в 30 отраслях. Это значит, что мы сталкиваемся с разными требованиями. Но одно общее: если сайт не виден в поиске — он не работает. И локализация — это не «дополнение». Это основа видимости. И она должна быть построена правильно с самого начала.
Это часть нашей работы — Программирование. Создание функциональных возможностей на сайте. В части создания сайтов выражается в интеграции верстки с данными в базе данных и формировании тем самым логики работы сайта. Программирование
Автор: Святослав Семенов из Cetera Labs