Содержание11
- Когда бизнесу пора делать многоязычный сайт
- Интернационализация и локализация: разница, которая влияет на бюджет
- Структура URL для языковых версий: подпапки, поддомены или отдельные домены
- Hreflang и техническое SEO: как поисковики понимают языковые версии
- CMS для многоязычных сайтов: ограничения и реальные возможности
- RTL-языки: арабский, иврит и другие — что ломает привычную вёрстку
- Сколько стоит и сколько занимает: бюджет и сроки локализации
- Юридические ловушки: GDPR, cookie, защита данных по рынкам
- Чек-лист: готовность к запуску многоязычной версии
- Частые вопросы
- Источники
Многоязычный сайт — не кнопка «перевести» в шапке. Это отдельный проект с собственной архитектурой, SEO-рисками и юридическими ловушками. Разберём, когда локализация окупается, какую структуру URL выбрать под разные рынки и сколько реально стоит запуск второй языковой версии — с конкретными сроками и цифрами.
Когда бизнесу пора делать многоязычный сайт
Компания заказала перевод каталога на немецкий, но не проверила, отгружает ли склад в Германию. Три месяца и 400 000 руб. ушли на контент, который конвертировался в ноль. Локализация требует готовности — без неё многоязычный сайт становится дорогим декором.
Три сигнала из аналитики говорят, что время пришло: органический трафик из-за рубежа превышает 15%, конверсия иностранных пользователей в 2–3 раза ниже российской, прямые конкуренты запустили локальные версии. Но цифры — только половина дела.
Проверьте пять условий перед стартом:
- Логистика или цифровая доставка работают в целевой стране
- Есть ресурс поддерживать контент: обновления, ответы на отзывы, правки
- Продукт не привязан к местному регулированию, которое вы пока не прошли
- Целевая аудитория говорит на языке, отличном от английского, или ожидает локального сервиса
- Бюджет покрывает не только перевод, но и адаптацию дизайна, SEO, тестирование
Если заказы разовые, аудитория свободно читает английский, или поддержка на новом рынке невозможна — локализация не окупится. В таких случаях достаточно англоязычной landing page с формой захвата.
Интернационализация и локализация: разница, которая влияет на бюджет
i18n — это разводка электрики в квартире, l10n — выбор розеток под вилки разных стран. Менять розетки просто, если проводка рассчитана. Переделывать стены ради одной розетки — в 2–3 раза дороже.
Интернационализация (i18n) предшествует локализации. На этом этапе готовят код и архитектуру: выносят тексты в отдельные файлы, настраивают форматы дат и валют, закладывают поддержку RTL-языков, разделяют контент по регионам. Без i18n каждый новый язык требует лезть в ядро системы.
Локализация (l10n) — адаптация под конкретный рынок: перевод, подмена валюты, корректировка изображений, юридических формул, единиц измерения. Один и тот же продукт в США и Японии — разные описания, разные акценты, иногда разные цвета.
Ошибка «сделаем перевод и потом подумаем» встречается в 60% проектов, к которым обращаются за доработкой. Переделка вёрстки, перестроение базы данных, переписывание шаблонов — всё это ложится сверху бюджета перевода.
Структура URL для языковых версий: подпапки, поддомены или отдельные домены
Выбор структуры определяет, как поисковики распределят вес, сколько стоит поддержка и насколько быстро запуститесь. Три варианта конкурируют по разным критериям — у каждого своя аудитория.
| Критерий | Подпапки (/en/, /de/) | Поддомены (en.site.ru) | ccTLD (site.de) |
|---|---|---|---|
| SEO-вес | Концентрируется на основном домене | Раздельный, слабее связь | Максимальный локальный сигнал |
| Стоимость поддержки | Минимальная | Средняя | Высокая: домены, хостинг, сертификаты |
| Сложность реализации | Низкая | Средняя | Высокая: отдельная инфраструктура |
| Скорость запуска | 1–2 недели | 2–3 недели | 4–8 недель |
| Доверие локальной аудитории | Среднее | Среднее | Высокое: «свой» домен |
| Пример применения | SaaS, единый продукт | Изоляция рисков, разные команды | Франшиза, локальный бренд |
Подпапки выигрывают для большинства b2b-сервисов: проще управлять, дешевле поддерживать, ссылочный вес не распыляется. ccTLD-домены оправданы, когда локальное доверие критично — например, ритейл в Германии или юридические услуги во Франции. Поддомены — компромисс, если нужна изоляция технических проблем, но единый бренд.
Главная ошибка — смешивать структуры в одном проекте: часть языков на подпапках, часть на поддоменах. Поисковик не поймёт иерархию, вес утекает в никуда.
Hreflang и техническое SEO: как поисковики понимают языковые версии
Hreflang говорит поисковику: эта страница — для пользователей из Германии, говорящих на немецком, а та — для англоязычных в Индии. Без него Google может показать русскую версию австрийцу или объединить страницы в дубли, исключив обе из выдачи.
Синтаксис прост: <link rel="alternate" hreflang="de-AT" href="https://site.com/de-at/seite" />. Язык по ISO 639-1, регион по ISO 3166-1 alpha-2. Атрибут x-default указывает страницу для всех, кто не попал ни в одну языковую пару — обычно выбор языка вручную или английская версия.
Три способа реализации: в <head> каждой страницы, через HTTP-заголовок, или в отдельном sitemap. Для сайтов до 500 страниц — заголовок проще, для крупных — sitemap централизует управление.
Главная ошибка hreflang — настроить теги только на одной версии. Обратные ссылки обязательны: если есть ru->en, должна быть и en->ru.
Частые ловушки: код en-us для контента, который фактически для Индии; отсутствие обратных ссылок между версиями; несуществующие языковые коды вроде ru-RU вместо ru. Каждая ошибка — потеря трафика в конкретном регионе.
Дублирование контента предотвращается через hreflang в сочетании с каноническими URL: каждая языковая версия ссылается сама на себя, а не на «основную». Отдельный sitemap.xml для каждой версии помогает поисковику индексировать быстрее — особенно при запуске, когда краулер ещё не знает о новых страницах.
CMS для многоязычных сайтов: ограничения и реальные возможности
CMS определяет, сколько языков вы ведёте без боли и где вас ждёт точка слома. Универсального решения нет — есть проекты, где WordPress удобнее Битрикса, и наоборот.
WordPress. WPML — функционален, но платный и тяжеловат: на 10+ языках замедляет админку. Polylang проще и дешевле, но не тянет мультисайт. MultilingualPress — для сети сайтов, когда каждый язык — отдельная установка с общей базой. Для корпоративного сайта на 3–5 языков — Polylang, для маркетплейса с разными командами — MultilingualPress.
1С-Битрикс. Встроенная многоязычность есть, но кастомные компоненты требуют ручной адаптации: языковые константы, шаблоны писем, фильтры каталога. Интернет-магазин на Битрикс с 50 000 товаров и 4 языками — проект на 3–4 месяца, если i18n не заложена изначально.
Shopify Markets. Многоязычность встроена, но кастомные поля метаданных и SEO-URL ограничены. Для стандартного ритейла — запуск за неделю, для сложной витрины с уникальными описаниями — упираетесь в потолок платформы.
Tilda, Flexbe, Webasyst. Быстрый старт на 2–3 языка, но масштабирование требует переезда. Подпапки часто не поддерживаются в принципе, hreflang — через костыли. Подходит для теста гипотезы, не для долгосрочной стратегии.
RTL-языки: арабский, иврит и другие — что ломает привычную вёрстку
Арабский читают справа налево, и это меняет всё: навигация, кнопки «Назад» и «Вперёд», формы с иконками, да логотипы со стрелками. RTL-языки требуют особой локализации — отдельной строки в бюджете и отдельного этапа тестирования.
Зеркальное отражение интерфейса — не прихоть, а ожидание пользователя. Кнопка «Назад» справа, прогресс-бар справа налево, выпадающие меню открываются влево. Иконки с направлением — стрелки, руки, глаза — переворачиваются или заменяются.
Числа и даты внутри арабского текста остаются LTR, что ломает выравнивание. Встроенные латинские термины и бренды создают «прыгающие» строки. Не все шрифты поддерживают арабские диакритики — проверяйте на реальных устройствах, эмуляторы пропускают до 30% багов.
RTL-локализация увеличивает сроки на 30–50% и требует носителя для тестирования. Экономия на этом этапе — сломанная вёрстка и отказ аудитории.
Сколько стоит и сколько занимает: бюджет и сроки локализации
Простой корпоративный сайт на 3 языка — 3–4 недели. Интернет-магазин с каталогом — 8–12 недель. Сложные проекты с RTL, юридическим аудитом и интеграцией CRM — до 6 месяцев.
Разбивка по этапам:
- Аудит i18n и архитектуры — 3–5 дней
- Перевод контента — основная переменная
- Адаптация вёрстки и шаблонов — 1–2 недели
- SEO: hreflang, sitemap, метаданные — 3–5 дней
- Тестирование: функционал, вёрстка, скорость из целевого региона — 1–2 недели
Ставки перевода за 1000 знаков с пробелами: европейские языки 800–1500 руб., азиатские 1200–2500 руб., редкие (арабский, иврит, скандинавские) до 4000 руб. Нейроперевод с постредактурой носителем снижает стоимость на 20–30%, но требует редактора-носителя — иначе рискуете фильтром за машинный контент.
Скрытые статьи, которые увеличивают бюджет: правка под RTL, юридический аудит GDPR или локальных законов, локализация изображений (не все фото работают в другой культуре), адаптация CRM под региональные воронки.
Юридические ловушки: GDPR, cookie, защита данных по рынкам
Многоязычный сайт подпадает под законы каждого рынка, на который вы выходите. Полный разбор — тема для юриста, но минимум проверить нужно до запуска.
GDPR для ЕС требует явного согласия на cookie до загрузки скриптов, права пользователя на удаление данных, уведомления о утечках в течение 72 часов. Меняются формы обратной связи: чекбокс согласия обязателен, предзаполненные галочки запрещены.
152-ФЗ РФ требует локализации данных граждан — персональные данные россиян хранятся в РФ, что влияет на выбор хостинга для русской версии. Отличия от GDPR: более жёсткие требования к локализации, мягче — к cookie.
LGPD в Бразилии и PIPL в Китае повторяют дух GDPR, но с местными нюансами: PIPL требует локализации данных в КНР, LGPD — назначения представителя в Бразилии. Для первичного выхода достаточно понимать масштаб: эти рынки требуют отдельной юридической подготовки.
Cookie-баннер не копируйте европейский шаблон для Азии. В Японии и Южной Корее ожидают минималистичное уведомление, в ЕС — детальное меню с отключением категорий. Неправильный баннер режет конверсию сильнее, чем его отсутствие.
Чек-лист: готовность к запуску многоязычной версии
Проверьте перед стартом или передачей в разработку:
До запуска - hreflang настроен в обе стороны между всеми версиями - x-default указан для нерелевантных запросов - canonical на каждой странице ведёт на себя, а не на «основную» версию - sitemap.xml отдельный для каждого языка, валидирован в Search Console - метаданные, alt-изображений, URL-параметры переведены, не только основной текст - скорость загрузки проверена из целевого региона, не из офиса
В первую неделю - мониторинг 404-ошибок по языковым версиям - проверка отображения в региональной выдаче Google и Яндекс - тикеты в поддержку: на каком языке приходят, куда маршрутизируются
Первый месяц - конверсия по версиям сравнивается с базовой - доработка: что просили перевести, но пропустили - обновление контента на всех языках синхронно, чтобы версии не расходились
