Заказчик говорит: «Сделайте нам сайт на русском и английском». Разработчик кивает, ставит плагин переводов, загружает тексты — и все довольны. Проходит три месяца. Английская версия не индексируется. Немецкие клиенты видят кракозябры вместо умлаутов. Кнопка «Купить» на арабской версии уехала куда-то влево. Знакомая история?
Мультиязычность — это не просто переключатель языка в углу экрана. Это архитектурное решение, которое нужно принимать до того, как написана первая строчка кода.
Локализация — это не перевод
Первая и главная ошибка: путать локализацию с переводом. Перевод — это когда берёшь текст на русском и делаешь то же самое на английском. Локализация — когда адаптируешь весь опыт под конкретную аудиторию.
Пример. На российском сайте вы пишете цену как «15 000 ₽». В Германии это будет «15.000 €» (точка вместо пробела как разделитель тысяч). В США — «$15,000» (запятая). Если вы просто поменяли валюту, но оставили формат — немецкий пользователь увидит пятнадцать, а не пятнадцать тысяч.
То же с датами. 05.06.2026 — это 5 июня или 6 мая? Зависит от страны. В ISO-формате это YYYY-MM-DD, и если хотите избежать путаницы — используйте его в базе данных, а отображение форматируйте через локаль.
Телефоны, адреса, единицы измерения — всё это требует отдельной логики. Нельзя просто взять контент и перевести его через DeepL.
Архитектура URL: три варианта и у каждого свои проблемы
Как хранить разные языковые версии — это технический выбор с долгосрочными последствиями.
Поддомены: en.example.com, de.example.com. Google считает их отдельными сайтами, поэтому каждый поддомен придётся продвигать с нуля. Плюс — можно хостить на разных серверах рядом с аудиторией.
Подпапки: example.com/en/, example.com/de/. Самый распространённый вариант. Весь SEO-вес домена работает на все версии. Проще в реализации и поддержке.
Отдельные домены: example.de, example.fr. Максимальное доверие локальных поисковиков, но это отдельный сайт с отдельным SEO, отдельным хостингом и отдельными расходами.
Для большинства проектов подпапки — оптимальный выбор. Но если вы выходите на рынок, где доверие к местному домену критично (например, Германия или Франция), стоит задуматься об отдельном домене.
hreflang — тег, который все ставят неправильно
Есть тег hreflang. Он говорит Google: «Вот эта страница — для русскоязычных пользователей в России, а вот эта — для русскоязычных на Украине». Без него поисковик сам гадает, какую версию показывать, и часто угадывает неверно.
Как ставить правильно:
<link rel="alternate" hreflang="ru" href="https://example.com/ru/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />
Главное: теги должны быть взаимными. Если русская страница ссылается на английскую, английская должна ссылаться обратно на русскую. Иначе Google игнорирует весь блок.
Ещё одна частая ошибка — использовать только en там, где нужно en-US и en-GB. Американец и британец говорят на одном языке, но «pants» у них означает разное. Если у вас разный контент для этих рынков — используйте региональные теги.
Вёрстка, которая ломается при переводе
Немецкий — один из самых жестоких языков для дизайнеров. Слово «Datenschutzerklärung» (политика конфиденциальности) содержит 21 символ. «Kraftfahrzeughaftpflichtversicherung» — это просто «автострахование», но в одно слово.
Если в вашей кнопке написано «Settings» и она рассчитана на 80px ширины — всё хорошо. Но «Einstellungen» уже не влезет. «Параметры» — тоже короче немецкого варианта, но представьте, что вы делаете сайт сразу для десяти языков.
Что делать:
— Не фиксируйте ширину кнопок и контейнеров с текстом. Используйте min-width вместо width.
— Закладывайте в дизайне запас 30–40% для расширения текста.
— Не обрезайте текст через overflow: hidden без text-overflow: ellipsis — иначе получите обрезанные слова.
— Проверяйте все языки в реальных браузерах, не только в дизайн-инструментах.
Отдельная история — языки с иероглифами. Китайский и японский текст занимает меньше места по горизонтали, зато требует другого межстрочного интервала и размера шрифта. То, что читается комфортно в 14px на латинице, в иероглифах будет слишком мелким.
RTL: арабский, иврит и всё, что пишут справа налево
Если вы когда-нибудь запускали сайт на арабском или иврите — вы знаете эту боль. Весь интерфейс должен зеркалиться: навигация уходит вправо, текст выравнивается по правому краю, иконки «назад» и «вперёд» меняются местами.
CSS для этого есть — атрибут dir="rtl" на <html> и свойство direction: rtl. Современный CSS также поддерживает логические свойства: margin-inline-start вместо margin-left. Это значит, что одно и то же правило работает правильно и для LTR, и для RTL.
Проблема в том, что большинство компонентов и библиотек написаны с расчётом на LTR. Берёте готовый слайдер — он едет не в ту сторону. Берёте форму — иконка телефона стоит с неправильной стороны поля. Каждый компонент нужно проверять вручную.
Ещё нюанс: числа в арабском пишутся слева направо, даже если текст идёт справа налево. Цена «١٢٣٤» читается так же, как «1234». Это надо учитывать при верстке таблиц и прайсов.
Шрифты и кодировки
UTF-8 решил большинство проблем с кодировками, но не все. Если вы используете кастомный шрифт — убедитесь, что он содержит нужные символы. Стандартный Google Font может не иметь кириллицы. Кириллический шрифт не будет содержать грузинские или армянские символы.
Для мультиязычного проекта либо выбирайте шрифты с максимальным покрытием Unicode (Noto от Google — отличный вариант, он покрывает практически все письменности мира), либо подключайте разные шрифты для разных языков через CSS:
:lang(ar) {
font-family: 'Cairo', sans-serif;
}
:lang(zh) {
font-family: 'Noto Sans SC', sans-serif;
}
Так каждая языковая версия получит оптимальный шрифт, а не попытку отрендерить иероглифы через Times New Roman.
Машинный перевод: где можно, а где нельзя
DeepL и GPT-4 переводят очень хорошо. Но «очень хорошо» — не то же самое, что «пригодно для публикации на коммерческом сайте».
Машинный перевод отлично работает для:
— Технической документации с чётко определёнными терминами
— FAQ и служебных текстов
— Черновиков, которые потом редактирует носитель языка
Машинный перевод плохо работает для:
— Маркетинговых текстов и слоганов (игра слов, культурные отсылки)
— Юридических документов (договоры, политики)
— Контента с устойчивыми выражениями, которые не переводятся дословно
Классический пример: KFC вышел на китайский рынок со слоганом «Finger-lickin' good» («Пальчики оближешь»). Машинный перевод выдал что-то вроде «Откуси свои пальцы». Это не легенда — это реальная история из 1980-х, и с тех пор ничего принципиально не изменилось.
Практический совет: используйте машинный перевод как инструмент, но всегда подключайте носителя для финальной проверки хотя бы ключевых страниц — главной, лендингов, карточек товаров.
CMS и управление переводами
Самая недооценённая проблема — как вы будете обновлять переводы, когда изменится оригинальный контент.
Вы поменяли описание услуги на русском. Английская версия теперь устарела. Через неделю — немецкая. Если у вас нет системы отслеживания — через полгода половина переводов будет описывать то, чего уже нет.
Popular CMS справляются с этим по-разному:
WordPress + WPML или Polylang — зрелые решения с системой уведомлений об устаревших переводах. WPML стоит от $39/год, Polylang есть в бесплатной версии.
Strapi, Contentful — headless CMS с нативной мультиязычностью. Каждая единица контента хранится с привязкой к локали. Удобно, но требует технических знаний при настройке.
Собственная разработка — максимальная гибкость и максимальная ответственность. Имеет смысл для крупных проектов с нестандартными требованиями.
Что точно нужно настроить: уведомления редактору, когда оригинал изменился, а перевод — нет. Без этого поддерживать актуальность невозможно.
SEO для каждой языковой версии
Одна из частых иллюзий: «мы переведём контент, и он сам появится в поиске». Нет. Каждая языковая версия требует отдельной SEO-работы.
Запросы разные. «Купить ноутбук» и «buy laptop» — это разные ключевые слова с разными объёмами и разными конкурентами. Прямой перевод запросов работает плохо: нужно собирать семантику отдельно для каждого рынка.
Мета-теги нужно переводить и оптимизировать отдельно. Title и description на каждой языковой версии должны быть написаны с учётом местных запросов, а не просто переведены с русского.
Sitemap должен содержать все языковые версии всех страниц с правильными hreflang. Многие генераторы sitemap это умеют, но не все включают по умолчанию.
Google Search Console нужно настроить отдельно для каждого поддомена или региона — иначе вы не увидите, как индексируются конкретные языковые версии.
Сколько это стоит и когда закладывать в бюджет
Мультиязычность дешевле добавить на этапе разработки и дороже — потом. Если вы изначально строите сайт без учёта локализации, а потом решаете добавить второй язык — ждите рефакторинга.
На практике добавление второго языка к уже готовому корпоративному сайту занимает 20–40% от стоимости исходной разработки. Плюс расходы на переводчика: профессиональный технический перевод стоит от 1 500 до 3 000 ₽ за 1 000 слов, маркетинговый — дороже.
Если вы планируете мультиязычность — говорите об этом на этапе постановки задачи. Тогда архитектура, структура базы данных и шаблоны вёрстки будут сделаны правильно с самого начала.
В REEXY мы начинаем с вопроса: «Планируете ли вы когда-нибудь выйти на другие рынки?» Даже если ответ «пока нет» — лучше заложить возможность, чем переделывать потом. Корпоративный сайт с нуля у нас стоит от 15 000 ₽, и мультиязычная архитектура при правильном планировании не удваивает эту цену.
Тестирование: что проверять перед запуском
Чеклист для финальной проверки мультиязычного сайта:
— Все hreflang взаимные и не содержат ошибок (проверяйте через Screaming Frog или hreflang.org)
— Вёрстка не ломается на длинных немецких словах
— Числа, даты, валюты форматируются по локали
— Формы принимают международные телефонные номера и адреса
— RTL-версия проверена в реальном браузере, не только в инструментах разработчика
— Шрифты загружаются для всех языков
— Мета-теги заполнены для каждой языковой версии
— В sitemap есть все языковые версии
— Переключатель языка работает и запоминает выбор пользователя (через cookie или localStorage)
— Поиск по сайту работает на всех языках
Отдельно — проверьте поведение при смешанном контенте. Что происходит, если пользователь выбрал английский, но часть страниц ещё не переведена? Показывать оригинал? Скрывать страницу? Перенаправлять на главную? Это должно быть продуманным решением, а не случайностью.
Главная мысль
Мультиязычный сайт — это отдельный продукт, а не перевод существующего. Технически: правильная структура URL, hreflang, RTL-поддержка, форматирование данных по локали. Организационно: процесс обновления переводов, контроль актуальности, SEO для каждого рынка.
Если всё это сделано правильно — вы получаете реально работающий инструмент для выхода на новые рынки. Если нет — красивый сайт, который никто не находит и который раздражает иностранных пользователей.