Как должен работать мультиязычный сайт — домены, языковые версии, SEO и требования разных стран

Компания выходит на новый рынок, заказывает перевод главной и карточек товара, добавляет флаги в шапку — и считает, что международный сайт готов. Потом немецкая версия ведёт в русскую корзину, канадский клиент видит цену без понятной валюты, а человек из Бельгии получает страницу не на том языке. Поисковик при этом индексирует несколько похожих адресов и сам выбирает, какой показать.

Мультиязычность не равна переводу. Это способ устроить один или несколько рынков так, чтобы человек, поисковая система и команда видели одну и ту же логику: какая версия для кого, что в ней можно купить, кто обновляет информацию и что произойдёт на следующем шаге.

Язык отвечает на вопрос, как человек читает интерфейс и содержание. Страна — где он находится. Рынок — более широкая конструкция: язык, валюта, ассортимент, налоги, доставка, способ оплаты, договорные условия, реклама и поддержка. Они совпадают не всегда.

Английская версия может быть достаточной для международного B2B-каталога, где предложение одинаково, а продажа всё равно проходит через менеджера. Но английский для Великобритании, США и Сингапура уже может означать разные цены, сроки, юридические документы и способы доставки. Французский — не один рынок: Франция, Бельгия, Канада и Швейцария различаются не только валютой. И наоборот, для одного рынка иногда нужны несколько языков.

Поэтому до дизайна переключателя полезно собрать матрицу. В строках — языки и страны, в столбцах — каталог, цена и валюта, наличие, доставка, оплата, документы, контакты, реклама, поддержка и владелец данных. Если в двух строках ничего не различается, возможно, компании не нужны две самостоятельные версии. Если различается половина столбцов, это уже не «перевод сайта», а отдельный операционный контур.

Версия сайта должна описывать реальное предложение для выбранной аудитории, а не просто язык текста.

Обычно используют три схемы:

У каждой схемы есть цена. Национальный домен ясно считывается как локальный, но требует отдельных доменов, инфраструктуры и проверки правил регистрации. Поддомен даёт техническое разделение, но не всегда очевидно, обозначает ли de язык или страну. Папки проще обслуживать в общем контуре, однако в нём особенно важны роли, доступы и правила публикации. Параметры вроде ?lang=de для индексируемых языковых страниц — плохая основа: их труднее поддерживать и объяснять поисковым системам.

Универсально лучшей схемы нет. У производителя с одним каталогом, общей командой и разными языками часто разумнее начать с папок. У группы компаний с локальными юридическими лицами, отдельными ценами и маркетингом могут быть оправданы национальные домены. Решение должно отвечать на практические вопросы: кто владеет доменами, где хранятся данные, сколько контуров команда действительно сможет поддерживать и что изменится для пользователя.

Это другая задача, чем региональное продвижение. Там компания выбирает, как честно показать предложение в разных городах. Здесь нужно связать языки и рынки, включая страны, в которых один и тот же язык не гарантирует одинаковые условия.

Переключатель нужен на каждой странице, где доступна альтернатива. Он должен вести на соответствующую страницу той же сущности: с карточки товара — на карточку этого товара, со статьи — на статью, из корзины — в сопоставимый сценарий или честно объяснять, что его нет. Возврат на главную после каждого выбора кажется мелочью, пока пользователь не потерял собранную спецификацию или не ищет нужный документ второй раз.

Лучше называть варианты языками: «Deutsch», «English», «Français», а не только флагами. Флаг обозначает страну, а не язык; он плохо работает там, где языки и страны не совпадают. Если пользователь выбирает рынок, интерфейс должен показать именно рынок: например, «Germany — EUR» или «Canada — English».

Геолокация и язык браузера могут подсказать подходящий вариант, но не должны запирать пользователя в нём. Google прямо предупреждает, что разные версии, выдаваемые по IP, могут быть недоступны для обхода. Автопереход допустим как мягкое предложение, но у человека должна быть видимая возможность остаться на текущей версии или выбрать другую.

Поисковая система не обязана угадать, что две похожие страницы — варианты одного материала. Для этого используют hreflang: набор ссылок, где каждая языковая или языково-региональная версия указывает на все остальные, включая себя. Значение состоит из кода языка и, при необходимости, страны: de, en-GB, fr-CA. Код страны сам по себе не подходит: DE без языка не сообщает, на каком языке написана страница.

У набора должен быть запасной маршрут — x-default. Он полезен, когда язык браузера не совпадает ни с одной подготовленной версией: например, чтобы вести на страницу выбора рынка или на базовую версию. hreflang можно передавать в HTML, HTTP-заголовках или карте сайта; способ выбирают по типу контента и возможностям CMS. Для PDF и других не-HTML-файлов заголовок может быть удобнее, чем попытка встроить тег в документ.

Но hreflang не заменяет содержимое. Страница должна реально быть на указанном языке, иметь доступный URL и не быть закрыта от обхода. Отдельно проверьте канонические адреса, карту сайта, внутренние ссылки, метаданные и атрибут lang у HTML-документа. lang нужен браузерам и вспомогательным технологиям, но Google определяет язык прежде всего по видимому содержанию; один атрибут не сделает русскую страницу немецкой. Базовые принципы индексации страниц и SEO для бизнеса здесь важны, но международная версия добавляет к ним взаимные связи между рынками.

Когда языковую версию делают простым дубликатом, проблемы начинаются после первого обновления. В базовой карточке меняется характеристика, а в трёх переводах остаётся старое значение. Публикуется новая категория, но у неё нет соответствия в меню другой версии. Редактор удаляет материал на одном языке, а переключатель продолжает вести на ошибку 404.

Контентная модель должна знать, что у одного товара, услуги или статьи есть языковые варианты. Для каждого варианта нужны как минимум язык, рынок, статус публикации, URL, SEO-поля и ответственный за перевод или адаптацию. Полезно отдельно хранить интерфейсные строки, редакционный контент, изображения, документы и юридические тексты: у них разная частота изменений и разные владельцы.

Важно заранее решить, что делает система с неполной версией. Иногда товар нельзя выпускать, пока не переведены обязательные поля и условия покупки. Иногда допустимо оставить язык только для справочного раздела, но не показывать его в селекторе на этапе заказа. Это не техническая мелочь, а правило продукта. О том, как CMS превращает бизнес-сущности в управляемый сайт, подробнее сказано в статье «Зачем бизнесу CMS, если сайт уже работает».

На международной версии человек оценивает не только грамотность перевода. Он проверяет, можно ли понять цену, завершить оплату, получить товар, связаться с компанией и предъявить документ при споре. Поэтому тестировать нужно полный сценарий, а не только страницы в редакторе.

В проверку входят:

У B2B есть свой набор: спецификация, сертификаты, единицы поставки, Incoterms или иной термин поставки, скачивание документа, запрос коммерческого предложения. Если менеджер потом вручную уточняет у каждого иностранного клиента валюту, страну отгрузки и доступность товара, сайт ещё не стал международным инструментом — он лишь перенёс первый вопрос в форму.

Владелец часто просит «добавить юридические страницы для Европы» или «сделать GDPR». Такой запрос слишком широк, чтобы обещать готовое решение в интерфейсе. Применимые требования зависят от того, какое юридическое лицо продаёт, на кого целенаправленно рассчитано предложение, где исполняется договор, какие данные собираются, какие платежи и маркетинговые каналы используются, а также от отрасли.

У сайта должна быть не универсальная юридическая плашка, а карта вопросов для проверки: кто продавец на этой версии; какая цена и валюта обещаны; какие условия доставки и возврата действуют; где и зачем хранятся персональные данные; какие согласия нужны; кто отвечает за актуальность локальных документов. Юрист или специалист по комплаенсу подтверждает применимость норм для конкретной схемы продаж. Разработчик и редактор переводят это решение в формы, тексты, логику доступа и журнал изменений.

Такой порядок защищает от двух крайностей: не выдавать общую страницу за юридическую гарантию и не останавливать запуск, пока команда пытается предусмотреть законодательство всего мира.

Если в отчёте есть только «иностранный трафик», управлять мультиязычным сайтом невозможно. Отдельно фиксируйте язык интерфейса, выбранный рынок, страну доставки или сделки, версию страницы и ключевое действие. При этом не превращайте аналитику в сбор лишних персональных данных: для большинства продуктовых вопросов достаточно технического признака версии и агрегированных результатов.

Сравнивайте не только посещаемость. Для каждого рынка полезны видимость в поиске, переходы на локальные страницы, начало формы или заказа, успешная оплата, причины отказа, возвраты и нагрузка на поддержку. Если франкоязычная версия получает трафик, но клиенты уходят после выбора доставки, проблема не в переводе и не в позиции. Она может быть в ассортименте, валюте, способе оплаты или невыполненном обещании.

События и параметры нужно согласовать до запуска, иначе три языковые версии превратятся в три несопоставимых отчёта. Базовый принцип описан в веб-аналитике сайта: событие полезно, только если команда понимает, что именно оно измеряет и какое решение по нему примет.

Первый шаг — не добавить в меню десять флагов. Выберите один рынок, на котором есть подтверждённый спрос, понятное предложение и владелец операционных данных. Опишите его URL, языки, каталог, платёжный и логистический маршрут, обязательные документы, аналитику и условие остановки. Затем проведите несколько тестовых сценариев: поиск нужной страницы, смена языка, заполнение формы, заказ, письмо, обращение в поддержку, обновление цены или документа.

После пилота станет видно, что именно масштабировать: перевод, локальный контент, складскую интеграцию, поддержку, способы оплаты или процесс публикации. Иногда честный результат — оставить единый англоязычный сайт с ясной международной доставкой, а не создавать версии, которые компания не способна поддерживать.

Мультиязычный сайт работает, когда языковая версия ведёт человека к реальному для него предложению: понятной цене, доступной покупке, корректным документам и живой поддержке. URL, hreflang, переключатель и CMS нужны не для галочки SEO, а чтобы держать эту связь управляемой.

Перед запуском полезно проверить одну связку целиком: язык и рынок, адрес страницы, соответствующий контент, форму, оплату, доставку, документы, события аналитики и владельца обновлений. Если на любом шаге ответ звучит как «потом разберёмся», это не повод отказаться от нового рынка. Это повод не выдавать перевод сайта за готовую международную инфраструктуру.