Решение сделать сайт на нескольких языках обычно принимают быстро: появился зарубежный партнёр, компания выходит на рынки соседних стран, нужен английский для инвесторов или выставки. А дальше выясняется, что «просто перевести тексты» не получается. Нужно выбрать схему адресов, решить, что делать с ценами и формами, кто будет обновлять переводы и как поисковые системы поймут, какую версию показывать. Разберём архитектуру многоязычного сайта по шагам и честно скажем, где чаще всего ошибаются.
Перевод или локализация: определитесь с целью
Первый вопрос — зачем нужна языковая версия. От ответа зависит и объём работ, и бюджет. Есть три типовых сценария, и они требуют очень разных решений.
Первый сценарий — представительская версия. Английский нужен, чтобы иностранный партнёр мог понять, кто вы, и найти контакты. Здесь достаточно перевести ключевые страницы: главную, «О компании», основные направления, контакты. Пять-восемь страниц, без блога и новостей. Второй сценарий — работа с иностранными клиентами на тех же условиях. Нужно перевести каталог или услуги целиком, адаптировать формы, возможно, цены и способы оплаты. Третий — полноценный выход на новый рынок. Здесь уже нужна локализация: другие примеры, другие кейсы, отзывы клиентов из этой страны, местные способы связи, иногда отдельная структура.
Разница между переводом и локализацией принципиальна. Перевод передаёт смысл текста. Локализация адаптирует предложение под культуру и привычки аудитории: единицы измерения, формат дат и телефонов, валюту, юридические страницы, тон общения. Казахстанскому дистрибьютору и немецкому закупщику нужны разные аргументы, даже если продукт один и тот же.
Архитектура адресов: три основных варианта
Техническое решение, которое сложнее всего поменять после запуска, — как языковые версии разнесены по адресам. От него зависят продвижение, аналитика, стоимость поддержки. Вариантов три.
| Схема | Пример адреса | Плюсы | Минусы |
|---|---|---|---|
| Папки | site.ru/en/catalog/ | Один сайт, общий авторитет домена, проще поддержка и аналитика | Слабее сигнал о стране, один хостинг на все рынки |
| Поддомены | en.site.ru/catalog/ | Можно разнести на разные серверы, проще разделить команды | Поисковики частично воспринимают как отдельные сайты |
| Отдельные домены | site.de, site.kz | Максимальный сигнал о стране, локальное доверие | Каждый домен продвигается с нуля, дороже в поддержке |
В большинстве проектов малого и среднего бизнеса мы рекомендуем папки. Это самый экономичный вариант: одна система управления, один хостинг, один сертификат, общий вес домена помогает новым версиям быстрее появиться в поиске. Отдельные домены оправданы, когда компания всерьёз строит бизнес в другой стране, имеет там юрлицо и готова вкладываться в отдельное продвижение. Поддомены — компромисс, который выбирают, когда языковые версии сильно различаются по содержанию и ими управляют разные команды.
Чего не делать с адресами
Не используйте переключение языка без смены адреса — через cookie или параметр сессии. Поисковый робот видит только одну версию, а пользователь не может поделиться ссылкой на английскую страницу. Не перенаправляйте автоматически по IP-адресу или языку браузера: русскоязычный пользователь в Европе получит немецкую версию и не всегда найдёт, как вернуться. Лучше показать ненавязчивую подсказку «Похоже, вам удобнее английский» с кнопкой перехода.
Как поисковые системы понимают языковые версии
Чтобы поисковик показывал немецкую страницу немецким пользователям, а русскую — русским, нужно явно связать версии между собой. Для этого используется атрибут hreflang: на каждой странице указываются все её языковые аналоги. Без него поисковая система может решить, что английская и русская страницы — дубли, или показывать в выдаче не ту версию.
Связка должна быть взаимной: если русская страница ссылается на английскую, английская обязана ссылаться на русскую. Ошибки в этом месте встречаются постоянно — например, когда у части страниц перевода нет, а ссылка на несуществующую версию остаётся. Поэтому генерацию hreflang нужно автоматизировать на уровне системы управления, а не прописывать вручную.
- У каждой языковой версии собственные адреса, которые индексируются.
- Атрибуты hreflang взаимны и указывают только на существующие страницы.
- Title, description и заголовки переведены, а не оставлены на исходном языке.
- Адреса страниц — на языке версии или нейтральные, без русского транслита в английской версии.
- Карта сайта включает все версии или отдельные карты для каждой.
- Атрибут lang в коде страницы соответствует языку контента.
- Переключатель языка ведёт на аналог текущей страницы, а не на главную.
Последний пункт — частая недоработка. Человек читает карточку товара, переключает язык и оказывается на главной английской версии. Приходится заново искать товар, и многие просто уходят. Если у страницы нет перевода, переключатель должен либо вести в ближайший раздел, либо явно показывать, что эта страница доступна только на одном языке.
Организация перевода
Машинный перевод сегодня даёт неплохое качество черновика, но публиковать его без редактуры рискованно. Ошибки в терминологии, неестественные обороты, буквально переведённые идиомы сразу выдают «переведённость», а в B2B подрывают доверие к экспертизе. Рабочая схема — машинный черновик плюс редактура носителем или профильным переводчиком. Это дешевле перевода с нуля и заметно лучше чистой машины.
До начала перевода стоит подготовить глоссарий: список ключевых терминов, названий продуктов и устойчивых формулировок с утверждёнными переводами. Без него один переводчик назовёт ваш продукт одним словом, другой — другим, и через полгода на сайте будет три варианта. Для технических компаний глоссарий из 50–150 терминов окупается многократно.
Определить объём
Выписать страницы, которые переводятся, и те, что остаются только в основной версии. Посчитать объём в знаках, включая интерфейс: кнопки, подписи форм, сообщения об ошибках, письма.
Составить глоссарий
Согласовать перевод ключевых терминов с теми, кто работает с иностранными клиентами.
Перевести и отредактировать
Получить черновик, отдать на редактуру носителю, проверить на страницах сайта в реальной вёрстке.
Проверить вёрстку
Немецкий текст в среднем на 20–30% длиннее русского, а китайский — короче. Кнопки, меню и заголовки могут поехать.
Настроить процесс обновлений
Определить, кто и в какие сроки переводит новые материалы, чтобы версии не расходились.
Что ещё нужно адаптировать
Помимо текстов, многоязычный сайт затрагивает массу мелочей, которые легко упустить. Формы: поле «Отчество» непонятно иностранцу, а маска телефона под российский формат не даст ввести номер другой страны. Валюта и цены: показывать ли рубли, пересчитывать ли по курсу или задавать цены вручную. Юридические страницы: политика конфиденциальности должна быть доступна на языке пользователя. Письма и уведомления: клиент, оформивший заявку на английском, должен получить подтверждение на английском.
Отдельный вопрос — менеджеры. Если заявка с английской версии придёт в CRM без пометки о языке, её может взять сотрудник, который не говорит по-английски. Поэтому язык заявки стоит передавать как отдельное поле и настраивать распределение. Это небольшая доработка, но она сильно влияет на впечатление клиента. Такие сценарии мы обычно закладываем вместе с интеграцией сайта с CRM.
Изображения с текстом — частая ловушка. Баннер с надписью на русском в английской версии выглядит небрежно. Если на картинках есть текст, готовьте отдельные варианты для каждого языка или выносите надписи в HTML поверх изображения.
Выбор платформы и стоимость
Большинство популярных систем управления поддерживают многоязычность — встроенно или через расширения. В 1С-Битрикс языковые версии реализуются через отдельные сайты в рамках одной лицензии, в WordPress — через специализированные плагины, во фреймворках вроде Laravel или Nuxt — на уровне кода, что даёт максимальную гибкость. Выбор зависит от того, насколько различаются версии: если структура одинаковая и меняется только текст, подойдёт почти любое решение; если у каждой версии свои разделы и свой каталог, нужна более гибкая архитектура.
По бюджету ориентир такой: техническая реализация второй языковой версии на этапе разработки добавляет 15–30% к стоимости сайта. Перевод оплачивается отдельно и зависит от объёма и тематики. Добавление языка к уже работающему сайту обычно дороже, особенно если изначально многоязычность не закладывалась: приходится дорабатывать шаблоны, где тексты были «зашиты» в код. Поэтому если выход на другие рынки хотя бы в планах, архитектуру стоит подготовить сразу — это одна из тем, которые мы обсуждаем на старте разработки корпоративного сайта.
Типичные ошибки многоязычных сайтов
Перевод сделан один раз и забыт: русская версия живёт, английская застыла с устаревшими ценами и уволенными сотрудниками. Переведена только главная, а все ссылки с неё ведут на русские страницы. Языковой переключатель спрятан в подвале или выполнен флагами — флаг обозначает страну, а не язык, и испанский флаг для латиноамериканского клиента выглядит странно. Аналитика не разделяет версии, и невозможно понять, приносит ли английский сайт хоть одну заявку.
Ещё одна ошибка — переводить всё подряд. Новостная лента о внутренних событиях компании или статьи о российском законодательстве иностранному читателю не нужны. Лучше меньше страниц, но качественных и актуальных, чем полная копия сайта, которую невозможно поддерживать. Начните с ядра, измерьте интерес и расширяйте версию по мере появления спроса.
Итог
Многоязычный сайт начинается с цели: представительская версия, работа с иностранными клиентами или выход на новый рынок требуют разной глубины. Для большинства компаний оптимальна схема с языковыми папками на одном домене, взаимными hreflang и переключателем, который ведёт на аналог текущей страницы.
Перевод лучше строить на глоссарии и редактуре носителем, а адаптация должна затрагивать не только тексты, но и формы, валюту, письма, юридические страницы и обработку заявок. Закладывайте многоязычность в архитектуру с самого начала и назначьте ответственного за актуальность версий — тогда вторая и третья языковые версии будут приносить клиентов, а не создавать проблемы.
Нужен сайт или интернет-магазин?
Обсудим задачу, подскажем подходящую платформу и оценим сроки и бюджет — бесплатно и без обязательств.
Обсудить проект
