Мультиязычный сайт для бизнеса: как сохранить структуру, SEO, контент и заявки
Вторая языковая версия ломается не на переводе текстов. Проблемы появляются раньше: бизнес выбирает неудобный адрес, размечает страницы только для одного поисковика, проектирует интерфейс под короткий язык или не передает язык обращения менеджеру.
Короткий ответ такой. Адрес выбирают по модели управления версией и целевым странам. Для Google и Яндекса на каждой странице ставят взаимные ссылки hreflang в элементе head; Google дополнительно принимает разметку через HTTP-заголовки и Sitemap. Переводят маршрут до заявки, а в данные обращения передают язык, справочники и нужный формат контактов.
Архитектуру, структуру страниц и формы закладывают до перевода. Иначе вторая версия быстро превращается в отдельную копию сайта, которую приходится синхронизировать вручную.
Как выбрать адрес языковой версии сайта
Google описывает четыре варианта адреса в рекомендациях по международным сайтам: национальный домен, поддомен, каталог и параметр в адресе. Национальный домен вроде example.kg дает сильный сигнал о стране, но требует отдельной инфраструктуры и подходит только для одной страны. Поддомен en.example.com проще отделить от основного сайта, однако по адресу не всегда понятно, обозначает en язык или страну. Подпапка example.com/en/ живет на одном сервере и требует меньше поддержки, зато версии сложнее разделить между командами. Параметр ?loc=en Google не рекомендует.
Сам адрес не определяет язык страницы для Google. Поисковик анализирует видимый текст, а hreflang сообщает о связанных версиях. Google не использует hreflang и атрибут lang для определения языка страницы. Яндекс также не связывает обработку hreflang со структурой сайта: версии могут находиться на разных доменах, поддоменах и в каталогах.
Поэтому адрес выбирают по процессу управления. Общая команда и единый выпуск материалов обычно требуют общей структуры. Если языковую версию ведет отдельная команда или партнер, ее удобнее отделить на уровне домена или поддомена. Это организационный выбор, который нельзя заменить настройкой SEO.
После запуска менять адрес дорого: Google рекомендует составить карту старых и новых URL, настроить постоянные редиректы и следить за обеими версиями. Для сайта среднего размера переход на новые адреса может занимать несколько недель или дольше, а позиции в этот период колеблются.
Как разметить языковые версии для Google и Яндекса
В Google для hreflang подходят теги в head, HTTP-заголовки и Sitemap. У всех трех способов одинаковый статус. Яндекс больше не поддерживает Sitemap для языковых версий и рекомендует ставить ссылки в head. Если сайт должен одинаково работать в Google и Яндексе, разметку в head проще сделать общей точкой контроля.
Каждая версия страницы указывает саму себя и все доступные альтернативы. Если русская страница ссылается на английскую, а английская не возвращает ссылку, Google игнорирует такую пару. Полный список языков на каждой странице не обязателен: поисковик обработает те пары, которые ссылаются друг на друга.
x-default задает запасную страницу для пользователя, чей язык или регион не перечислен. Это может быть страница выбора языка. Для страниц с автоматическим определением языка Яндекс рекомендует добавлять x-default. Коды указывают по ISO: язык — двумя буквами, регион — при необходимости двумя буквами после дефиса. Один код региона без кода языка не используют.
Проверку начинают с исходного кода страницы: на каждой версии должны быть одинаковый набор альтернатив и взаимные ссылки. Затем сравнивают индексирование в Search Console и Яндекс Вебмастере. Если поисковик показывает основную версию вместо локализованной, это сигнал проверить разметку, канонический адрес и содержание страницы. О том, как поисковые и ответные системы читают страницу, рассказали в статье «Как подготовить сайт к AI-поиску и AI-ответам».
Кейс

Что меняется в структуре сайта, когда языков становится три
При двух языках редактор еще может вручную отслеживать расхождения. На трех языках у каждой страницы появляются три версии, а любое изменение в структуре, форме или справочнике нужно согласовать сразу в нескольких местах.
В проекте для Кредитно-инвестиционного банка Кыргызстана мультиязычность заложили на этапе архитектуры. Сайт поддерживает русский, кыргызский и английский языки. Реализацию выполнили через мультисайтовость «1С-Битрикс» на ядре D7: кодовая база общая, языковые версии отдельные.
Такой подход оставляет логику калькуляторов, форм и обмена данными в одном месте. Тексты и набор страниц можно вести отдельно для каждого языка. Это сокращает повторную разработку, но не отменяет редакторскую работу с переводами.
Интерфейс проектируют с запасом по длине текста. W3C приводит данные IBM, согласно которым короткие строки при переводе с английского могут вырасти в два-три раза, а строки длиннее 70 символов — примерно на 30%. Поэтому узкие кнопки, фиксированная ширина полей и текст внутри изображений становятся риском для второй версии. На проекте КИКБ до запуска подготовили около сотни прототипов.
Что переводить, что писать заново и что закрывать от индексации
Объем перевода определяют по назначению страницы и ее роли в продажах. Одинаковая глубина перевода для всего сайта редко оправдана.
-
Продуктовые и посадочные страницы переводит человек, который понимает терминологию и задачу страницы
-
Юридические документы проверяют с участием специалистов, которые отвечают за требования целевой страны
-
Новости и статьи переводят выборочно, если для них есть спрос и ресурс на поддержку
-
Корзину, оформление заказа, формы, уведомления об ошибках и письма переводят полностью
-
Архивные страницы, которые не будут поддерживаться и не отвечают отдельному спросу, после проверки можно закрыть от индексации
В каталоге объем растет вместе с числом языков: переводить приходится названия товаров, характеристики, категории, фильтры и сообщения интерфейса. Логику индексации фильтров и пагинации разбирали в статье «SEO для интернет-магазина».
Автоматический перевод сам по себе не делает страницу спамом. Риск возникает, когда перевод используют для массового создания малополезных страниц, в том числе из чужого контента. Google относит автоматический перевод чужого контента без ценности для пользователя к масштабному созданию контента. Для собственного сайта проверка практическая: понимает ли посетитель текст, получает ли нужную информацию и может ли пройти по странице до действия.
Почему заявки теряются на второй языковой версии
Первая причина — автоматический редирект по языку браузера. Google советует не отправлять посетителя с одной языковой версии на другую автоматически: такой редирект мешает людям и поисковым роботам увидеть остальные страницы. Посетитель, которому нужна английская версия, может сразу попасть на русскую и закрыть сайт.
Вторая причина — форма передает данные без контекста. Форма на английской странице отправляет заявку в ту же систему учета обращений, что и русская, но язык обращения не попадает в данные. Менеджер видит контакт, однако не знает, на каком языке человек изучал предложение и как с ним связаться.
Третья причина — справочники основной версии. Список стран, формат телефона, адреса, валюты и тексты ошибок остаются русскими. Страница открывается, форма отправляется, но посетитель не может ввести номер или выбрать нужную страну.
На проекте КИКБ для разных банковских продуктов сделали отдельные формы во всплывающих окнах. Обмен с внутренней системой банка и системой работы с клиентами настроили через API, с проверкой источника и валидацией данных. Для мультиязычного сайта к этому набору добавляют язык обращения и проверяют его передачу вместе с остальными полями.
Такую ошибку нельзя обнаружить только по внешнему виду сайта. Форму нужно заполнить на каждом языке и проследить весь путь: письмо, запись в системе учета, уведомление менеджера и сохранение источника обращения.

С чего начинать разработку мультиязычного сайта
Сначала фиксируют языки, страны, владельцев версий, список страниц первой очереди и действие после формы. Эти решения определяют адрес, структуру и состав первой версии.
Затем проектируют адреса и разметку hreflang для Google и Яндекса, связывают версии страниц и закладывают переключатель языка без принудительных редиректов. После этого проверяют расширение текста в интерфейсе и маршрут заявки.
Перевод считают после инвентаризации страниц. Смета зависит от числа языков, объема каталога, количества форм, юридических материалов и страниц, которые будут поддерживаться после запуска.
Если планируете вторую языковую версию или уже вручную синхронизируете страницы, обратитесь за UX/UI-дизайном и проектированием. Nineseven поможет определить структуру, проверить маршрут заявки и оценить объем первой версии.



