Посетитель читает услугу на английском, открывает форму и получает письмо на русском. Слова на странице переведены, но путь клиента остался незавершённым. В Гуси-Лебеди предлагаем создавать мультиязычный сайт как набор работающих сценариев: от поиска нужной страницы до ответа компании. Перевод интерфейса является только частью этой работы.
Разберём состав языковых версий, адреса страниц, связи переводов, hreflang и проверку перед запуском. Язык, страна и валюта здесь являются отдельными параметрами. Английская страница сама по себе не означает, что компания продаёт товар или оказывает услугу во всех англоязычных странах.
Какие языковые версии действительно нужны сайту
Начните с доступности предложения. Для каждой аудитории уточните услуги или товары, географию обслуживания, язык ответа, условия доставки и ответственного сотрудника. Если компания не может выполнить обещание в конкретном регионе, буквальный перевод страницы не решает проблему.
Определите законченный набор страниц для запуска. Можно перевести часть сайта, если посетитель понимает границы и проходит нужный сценарий целиком. Главная страница на другом языке с непереведённой формой, документами и подтверждением не является готовой локализацией.
| Объект | Что можно сохранить общим | Что проверить для аудитории |
|---|---|---|
| Услуга | Метод работы и описание задачи | Географию, условия и язык обслуживания |
| Товар | Модель и проверенные характеристики | Наличие, комплектацию и доставку |
| Форма | Цель обращения | Поля, получателя и сообщение о результате |
| Контакты | Название компании | Каналы связи, язык ответа и часы работы |
| Документы | Связь с услугой или товаром | Актуальную версию и понятность для читателя |
Для разработки многоязычного сайта такая матрица полезнее требования «сделать одинаковые копии». Она показывает, какие данные общие, где нужны местные условия и кому передать проверку. Семантику собирайте отдельно для каждой аудитории: принятый компанией термин и реальная формулировка запроса могут различаться.
Как выбрать адреса: каталоги, поддомены или отдельные домены
Для индексируемых языковых страниц выбирайте устойчивые отдельные адреса. В рекомендациях Google для многоязычных сайтов предлагается использовать разные URL вместо изменения языка только через cookie или настройки браузера. Это также позволяет человеку сохранить ссылку на нужную версию.
Каталоги внутри одного сайта удобны для общего процесса публикации. Поддомены позволяют организационно разделить приложения или команды. Отдельные домены добавляют задачи владения, продления, инфраструктуры и контроля. Выбирайте структуру вместе с будущим способом обслуживания.
Условные варианты адресов: example.com/ru/service/, ru.example.com/service/ или самостоятельный региональный домен. Здесь example.com используется только для объяснения структуры. Ни один вариант не обещает автоматического преимущества в ранжировании всех языковых страниц.
Зафиксируйте правила адресов до наполнения: язык в пути, допустимые символы, завершающий слеш, поведение старых ссылок. Не меняйте URL вслед за каждой правкой заголовка. Если перенос неизбежен, обновите ссылки и подготовьте карту соответствий, как в плане миграции сайта.
Как связать переводы и поддерживать их актуальность
Связывайте версии по общему идентификатору материала. У одной услуги могут быть разные адреса и названия, а перевод может ещё отсутствовать. Замена части пути /ru/ на /en/ не является надёжной моделью соответствий.
В CMS полезно хранить состояние каждой версии: перевод отсутствует, черновик, проверка специалистом, опубликовано, требуется обновление. Изменение исходной характеристики должно создавать заметную задачу для зависимых переводов. Иначе редактору придётся помнить все копии вручную.
Разделите общие факты и локальные условия. Например, характеристика модели может быть общей, а контакт, доступность услуги и условия исполнения отличаться. Автоматическое обновление всех полей не должно стирать локальные сведения. Назначьте владельцев исходного материала и проверки перевода.
Приёмка включает терминологию, единицы измерения, формат дат, ссылки и документы. Машинный перевод можно использовать как черновик, но фактические свойства и обещания компании проверяет ответственный специалист. В задании на разработку сайта укажите эти состояния и правила обновления, а не только список языков.
Как настроить переключатель языка, hreflang и canonical
Переключатель должен вести на соответствующий материал. Если перевода нет, покажите понятный вариант выбора и его границы. Не создавайте ссылку на несуществующий URL и не выдавайте главную страницу за перевод текущей услуги. Оставляйте человеку возможность выбрать язык самостоятельно.
hreflang обозначает языковые или региональные альтернативы страницы. В справке Яндекса о локализованных страницах указано: Яндекс больше не поддерживает Sitemap для языковых версий и рекомендует разметку страниц. Поэтому нельзя рассчитывать только на языковые ссылки в XML-карте для этой поисковой системы.
Для HTML-страниц можно разместить набор link rel="alternate" в head. Согласно руководству Google по языковым альтернативам, указывают полные URL, собственную версию и взаимные ссылки между переводами. Значение x-default предназначено для варианта выбора или другого случая, когда конкретная языковая версия не подходит. Google также поддерживает HTTP-заголовки и Sitemap.
Учебный пример для двух переводов одной услуги. Он не относится к настройкам этого сайта:
<link rel="alternate" hreflang="ru" href="https://example.com/ru/service/">
<link rel="alternate" hreflang="en" href="https://example.com/en/service/">Одинаковый набор размещают на обеих соответствующих страницах. Не добавляйте отсутствующие или непубликованные переводы. После удаления версии пересоберите набор альтернатив. Проверяйте действительные коды языков и регионов по требованиям поисковых систем.
canonical решает другую задачу: обозначает предпочтительный адрес среди дублирующихся вариантов. Не назначайте всем полноценным переводам canonical на русскую страницу только ради объединения. Для обычных самостоятельных переводов проверяют собственные канонические адреса; одинаковые региональные страницы на одном языке разбирают отдельно. Подробности есть в материале о настройке canonical.
Что перевести в формах, интерфейсе и мобильной версии
Локализуйте не только основной текст. Проверьте меню, кнопки, поля, подсказки, ошибки, уведомления, письма и вложения. Ссылка с английской услуги на русскую инструкцию должна быть понятна посетителю, если перевода пока нет. Не оставляйте неожиданную смену языка внутри важного шага.
В форме сохраняйте контекст обращения: язык, услугу и при необходимости рынок. Передавайте его сотруднику вместе с заявкой. Настройка маршрута в CRM должна соответствовать реальной работе компании: получатель способен ответить на выбранном языке и понимает условия предложения.
Длина перевода меняет интерфейс. Испытайте длинные названия в меню, заголовки, сообщения об ошибке и кнопки на узком экране. Для письменностей с другим направлением текста понадобится отдельная проверка компоновки. В материале об адаптивном дизайне объясняем, почему один красивый экран не подтверждает весь интерфейс.
Заранее согласуйте формат цен, дат и единиц измерения, если они используются. Перевод не должен молча менять валюту или условия услуги. Полезнее короткое точное пояснение, чем внешне привычная запись, которую компания не может выполнить.
Как проверить мультиязычный сайт перед запуском и после изменений
Проверяйте каждую версию отдельно. Выберите обычную страницу и пограничные случаи: перевод отсутствует, услуга снята, описание обновлено, подключение формы недоступно. Пройдите путь посетителя от страницы до полученного сотрудником обращения.
| Проверка | Ожидаемый результат |
|---|---|
| Прямой URL | Открывается нужная опубликованная версия |
| Переключение языка | Открывается соответствующий материал или понятный выбор |
| Альтернативы | Действительные адреса и согласованные взаимные ссылки |
| Индексация | Важные страницы доступны роботу и не закрыты случайно |
| Форма и CRM | Получены поля, услуга и язык обращения |
| Изменение исходника | Зависимый перевод отмечен для проверки |
| Мобильный экран | Текст читается, элементы не перекрываются |
После выпуска разделяйте наблюдение по языку страницы и нужным рынкам. Общая сумма посещений не покажет, что одна версия потеряла рабочую форму. Сверяйте обращения с получением в CRM, а технические ошибки с конкретными адресами. Не обещайте разным языкам одинаковые позиции: спрос и выдача требуют отдельного исследования.
Для сопровождения мультиязычного сайта согласуйте проверки связей страниц, форм и уведомлений после изменения шаблонов. Ответственного за смысл перевода назначьте отдельно от технического исполнителя. В Гуси-Лебеди предлагаем считать версию готовой, когда человек может понять предложение, пройти нужный путь и получить подходящий ответ компании.