# Локализация Next.js: как внедрить i18n без SEO-ловушек и дублей Международная экспансия сайта требует не просто перевода интерфейса, но грамотной технической реализации. В экосистеме Next.js разработчики часто сталкиваются с дилеммой: использовать динамическую смену языка на клиенте или создавать полноценные локализованные URL-адреса. Выбор неправильного пути ведет к катастрофическим последствиям для поисковой видимости — страницы перестают индексироваться в целевых регионах, а бюджеты сканирования тратятся впустую. ## Суть проблемы: почему client-side перевод убивает видимость Представьте ситуацию: ваш сайт доступен по адресу `/search/music`. Пользователь из России видит русский текст благодаря сохраненным cookie-файлам или настройкам браузера (`Accept-Language`). Пользователь из Германии открывает ту же ссылку и получает немецкий интерфейс. Для человека это удобно, но для поискового робота страница существует только в одном экземпляре. Поисковые системы, такие как Googlebot, при первом посещении могут увидеть одну языковую версию. При повторном заходе (или если робот игнорирует куки) он может проиндексировать другую. Это создает хаос в выдаче: * **Каннибализация:** Поисковик не понимает, какую страницу ранжировать по запросу "buy music". * **Потеря трафика:** Немецкие пользователи никогда не увидят вашу немецкую версию в поиске `.de`, потому что физически такой уникальной страницы нет. * **Размытие ссылочного веса:** Все обратные ссылки ведут на один адрес, независимо от того, какой язык предпочитает ссылающийся ресурс. Чтобы избежать этих проблем, необходимо выносить локаль непосредственно в путь URL. Структура должна быть иерархической: `site.com/ru/search/music` и `site.com/en/search/music`. ## Архитектура маршрутов: locale как часть пути В Next.js наиболее надежным подходом является использование встроенного роутинга с поддержкой интернационализации (i18n) или ручное управление через файл `next.config.js`. ### Настройка конфигурации Для начала необходимо явно указать поддерживаемые языки и дефолтную локаль. Это позволяет фреймворку автоматически генерировать правильные префиксы путей. ```javascript // next.config.js module.exports = { i18n: { locales: ['en', 'ru', 'de'], defaultLocale: 'en', localeDetection: true // Важно: разрешить автоопределение } } ``` При такой настройке запрос к корню сайта перенаправит пользователя на его предпочтительный язык (например, `/ru`), сохраняя чистоту структуры папок. ### Динамические сегменты Если ваше приложение использует динамические маршруты (например, `[slug]`), важно убедиться, что генерация статических параметров (`getStaticPaths`) учитывает все локали. Вы должны возвращать массив путей, где каждый параметр продублирован для каждого языка. Это гарантирует, что во время сборки будут созданы физические HTML-файлы для каждой языковой версии товара или статьи. ## Метаданные и тег Canonical: защита от дублирования Даже имея разные URL, можно совершить ошибку в управлении метаинформацией. Каждая языковая версия обязана иметь уникальные теги `