Компания выходит на новый языковой рынок, переводит каталог и главную страницу — и через месяц обнаруживает, что английская версия не индексируется, а в Google Search Console копится десяток предупреждений про hreflang. Проблема почти всегда не в переводе, а в технической части: структуре URL, разметке языковых версий и связях между ними, которые поисковик использует, чтобы понять, какую версию страницы показать какому пользователю.
Эта статья — о том, как правильно завести многоязычность на 1С-Битрикс технически: от выбора схемы URL до расстановки hreflang и локализации того, что обычно забывают — меню, чекаута, юридических страниц. Если задача — именно многоязычный каталог (торговые предложения, цены и остатки по языкам), это отдельная тема — подробно она разобрана в статье «Многоязычный каталог в 1С-Битрикс»; здесь мы разбираем сайт целиком. Материал опирается на нашу практику разработки многоязычных сайтов на 1С-Битрикс.
Коротко
- Штатный модуль многоязычности Битрикса привязывает контент и структуру к нескольким сайтам ядра — по одному на язык, с общим ядром данных.
- Для большинства проектов лучший вариант структуры URL — подпапки (/en/, /de/): проще в поддержке и наследуют вес домена.
- Hreflang должен быть двусторонним и полным: каждая языковая версия ссылается на все остальные, включая саму себя.
- Локализация — это не только каталог: меню, футер, чекаут, юридические страницы и уведомления должны переключаться вместе с языком.
- Валюта и единицы измерения — отдельная сущность от языка, их нельзя жёстко привязывать друг к другу.
С чего начинается многоязычный сайт
Прежде чем открывать модуль многоязычности в админке, стоит развести два разных, но часто путаемых понятия. Локализация — это перевод и адаптация контента: текстов, интерфейса, форм, юридических документов. Интернационализация — это техническая инфраструктура, которая делает локализацию возможной: структура URL, кодировки, разметка языковых версий для поисковика, механизм переключения языка. Ошибка большинства проектов — начинать с перевода текстов, не решив вопросы интернационализации, и потом переделывать URL и разметку задним числом на уже проиндексированном сайте.
Правильный порядок обратный: сначала фиксируется структура URL и техническая связка языковых версий, затем — перевод контента по приоритету (об этом отдельный раздел ниже). Такой порядок экономит месяцы, потому что смена схемы URL уже после индексации означает по сути повторный запуск сайта для поисковика — с временной просадкой трафика на всех языках, а не только на новом.
Модуль многоязычности в 1С-Битрикс
Технически многоязычность в 1С-Битрикс строится не на «переключателе текста», а на модуле «Многосайтовость» в связке с языковыми версиями (LANG_ID) ядра. Каждый язык — это фактически отдельный «сайт» в терминах Битрикса: свой SITE_ID, свой корневой каталог шаблонов (или общий шаблон с языковыми файлами), своя привязка контента инфоблоков.
Из этого устройства вытекают практические следствия:
- Инфоблоки можно делать общими или раздельными по языкам. Общий инфоблок с элементами, привязанными к нескольким сайтам одновременно, удобен, когда структура каталога одинакова для всех языков и меняются только тексты. Раздельные инфоблоки по языку нужны, если ассортимент или структура категорий в разных странах отличаются.
- Языковые файлы (.php в /lang/) отвечают за интерфейс. Статические строки — кнопки, подписи полей, системные сообщения — берутся из языковых файлов компонентов и модулей, а не из контента инфоблоков. Их нужно локализовать отдельно от контента.
- Один физический движок обслуживает все языки. В отличие от отдельных инсталляций на разные страны, здесь общая кодовая база, общее ядро, общие модули — обновления и доработки применяются один раз и распространяются на все языковые версии.
Часть контента типично делают общей для всех языков (структура каталога, логика скидок, интеграция с 1С), а часть — переводимой построчно (названия, описания, метатеги, статьи блога). Проектировать эту границу — общее/переводимое — нужно на старте, а не когда переводчик уже начал работу над контентом.
Структура URL: подпапки, поддомены, ccTLD
Выбор схемы URL для языковых версий влияет и на SEO, и на стоимость поддержки. У Битрикса нет жёсткого технического ограничения — все три схемы реализуемы через модуль многосайтовости и настройку доменов сайтов, — поэтому решение принимается по бизнес-критериям.
| Схема | Пример | Плюсы | Минусы |
|---|---|---|---|
| Подпапки | site.ru/en/ | Наследует вес и траст домена, дешевле SSL и DNS, проще запустить | Все языки формально «под одной крышей» для геосервисов |
| Поддомены | en.site.ru | Можно развести на разную инфраструктуру/CDN по языку | Каждый поддомен поисковик отчасти оценивает отдельно, нужен wildcard SSL |
| ccTLD (домены стран) | site.de | Сильнейший сигнал локальности для пользователя и поисковика | Дорого: отдельные домены, хостинг, юрлицо, SSL, независимый SEO-вес с нуля |
Практическая рекомендация для большинства B2B- и B2C-сайтов, выходящих на 1–3 новых языка без открытия локальных юрлиц: подпапки. Они дают предсказуемое поведение hreflang, единый TLS-сертификат на домен и минимальные накладные расходы на инфраструктуру. Поддомены оправданы, когда под язык/регион действительно нужна независимая техническая инфраструктура — например, отдельные серверы в юрисдикции страны по требованиям локального законодательства. ccTLD имеет смысл только при полноценном локальном присутствии: местный склад, локальные платёжные методы, локальная поддержка.
Hreflang: как работает разметка и почему её так легко сломать
Тег hreflang — это не про перевод сайта, а про указание поисковику соответствия между языковыми версиями одной и той же страницы. Он отвечает на вопрос «какую из версий этой страницы показать пользователю с таким-то языком интерфейса или регионом» и не влияет напрямую на ранжирование — только на выбор правильной версии в выдаче.
Разметка выводится либо тегами <link rel="alternate" hreflang="..."> в <head> каждой страницы, либо через HTTP-заголовки (для не-HTML документов), либо через отдельный hreflang-sitemap. Для большинства сайтов на Битрикс удобнее теги в head — их проще вывести программно из компонента страницы, где заведомо известны все языковые аналоги текущего URL.
Ключевое правило, которое чаще всего нарушают: разметка должна быть полной и двусторонней. Если страница на русском ссылается на английскую версию через hreflang, английская версия обязана содержать обратную ссылку на русскую — и обе страницы должны включать ссылки на все остальные языковые версии, включая саму себя (self-referencing hreflang).
На практике самый надёжный способ не сломать этот граф вручную — генерировать hreflang программно на основе структуры «одна сущность (раздел/элемент инфоблока) — несколько языковых версий», а не копипастом в шаблоне. Если карточка товара существует на трёх языках, компонент должен на основе внешнего идентификатора элемента (XML_ID, общего для всех языковых версий одного товара) собрать полный список альтернатив и вывести их за один проход, без ручных правок под каждый язык.
Локализация шире каталога: меню, чекаут, юридические страницы
Перевод карточек товаров — самая заметная, но не самая рискованная часть локализации. Реальные провалы запуска чаще случаются в местах, которые не тестируют на этапе приёмки, потому что они «и так работают»:
- Главное меню и футер. Пункты меню часто зашиты в шаблон компонента напрямую строкой, а не через языковой файл — при переключении языка меню остаётся на русском, хотя контент страницы уже переведён.
- Оформление заказа (чекаут). Это самая критичная для конверсии часть сайта: подписи полей формы, тексты ошибок валидации, письма подтверждения заказа. Незамеченная непереведённая строка на середине оформления заказа — прямая причина брошенной корзины у иноязычного покупателя.
- Юридические страницы. Политика конфиденциальности, публичная оферта, условия возврата — их часто забывают переводить вовсе, считая «неважными», хотя для B2B-покупателя из другой страны это может быть обязательным условием оформления сделки, а для локального регулятора — юридическим требованием.
- Системные уведомления и e-mail-рассылки. Письма о статусе заказа, восстановлении пароля, промо-рассылки генерируются шаблонами модуля продаж и рассылок — их языковые версии настраиваются отдельно от контента страниц и легко остаются непереведёнными.
- Формат даты, телефона и адреса. Даже если весь текст переведён, формат «ДД.ММ.ГГГГ» и телефон с кодом +7 в разделе доставки для англоязычного покупателя выглядят чужеродно и подрывают доверие к сайту как к «настоящей» локальной версии.
Валюта, единицы измерения и региональные форматы
Частая ошибка проектирования — жёстко привязать валюту и единицы измерения к языку интерфейса. Это работает только для примитивного случая «один язык — одна страна», но ломается на реальных рынках: франкоязычный посетитель может быть в Швейцарии (франки) или в Бельгии (евро), а немецкоязычный — в Германии, Австрии или Швейцарии с разными валютами.
В 1С-Битрикс валюта и региональные типы цен — самостоятельные сущности каталога, не завязанные напрямую на LANG_ID. Правильная архитектура: язык переключает интерфейс и контент, а валюту пользователь выбирает независимо (вручную или по определённой по IP стране — но с возможностью переопределить). Единицы измерения (метры/футы, кг/фунты) в карточках товаров также стоит привязывать к региону показа, а не к языку — через свойства инфоблока или множитель пересчёта в шаблоне.
| Параметр | Привязывать к | Почему |
|---|---|---|
| Текст интерфейса и контент | Языку (LANG_ID) | Один язык может обслуживать несколько стран |
| Валюта | Региону/выбору пользователя | Один язык — несколько валют (франкоговорящие страны, например) |
| Единицы измерения | Региону показа | Метрическая/имперская система не совпадает с языковыми границами |
| Формат даты и телефона | Региону/локали | Локаль (en-US, en-GB) может отличаться при общем языке |
Запуск многоязычного сайта пошагово
- Определите схему URL. Подпапки, поддомены или ccTLD — зафиксируйте решение на старте, миграция между схемами дорога.
- Настройте сайты в модуле многосайтовости. По одному SITE_ID на язык, с корректной привязкой доменов/путей и языковых файлов.
- Определите модель данных. Какие инфоблоки общие для языков, какие — раздельные; как хранится связь «одна и та же карточка на разных языках» (общий внешний XML_ID).
- Выведите hreflang программно. На основе связки элементов по языкам, а не вручную в шаблоне — чтобы граф ссылок оставался полным при добавлении новых страниц.
- Отделите валюту и регион от языка. Дайте пользователю переключать их независимо, с разумным значением по умолчанию по геолокации.
- Переведите по приоритету. Сначала — путь покупки целиком (каталог → карточка → корзина → чекаут → письма), затем — второстепенный контент.
- Проверьте в Google Search Console и Яндекс.Вебмастере. Отчёты по международному таргетингу и hreflang покажут конкретные ошибки разметки до того, как их найдут пользователи.
Реализация в 1С-Битрикс: где это настраивается
Основные точки настройки многоязычности живут в разделе управления сайтами и в языковых файлах компонентов. Условно интерфейс выглядит так:
Canonical и склейка языковых дублей
Отдельная проблемная зона — взаимодействие hreflang и canonical. Частая ошибка: на каждой языковой версии стоит canonical, указывающий на основную (например, русскую) версию сайта. Это противоречит самой идее hreflang: canonical говорит «это дубль, настоящая версия — там», а hreflang говорит «это равноправная версия для своего языка» — при конфликте между ними поисковики в лучшем случае игнорируют hreflang, в худшем — не индексируют переводные версии вовсе.
Правильное правило: каждая языковая версия страницы — self-canonical, то есть указывает сама на себя, а не на версию на другом языке. Canonical на другую версию уместен только внутри одного языка — например, для страниц с параметрами сортировки или UTM-метками, которые должны канонизироваться на чистый URL того же языка.
- Self-canonical на каждой языковой версии. /en/catalog/ канонизируется сама на себя, а не на /catalog/.
- Hreflang не заменяет canonical и наоборот. Это две разные сигнальные системы, и путать их в шаблоне — источник половины проблем с индексацией переводов.
- Один язык — один канонический URL. Внутри языка обычные правила канонизации (сортировки, пагинация, GET-параметры) работают как на одноязычном сайте.
Стратегия контента: что переводить в первую очередь
Переводить весь сайт целиком и сразу — редко посильная и редко оправданная задача, особенно для крупного каталога. Разумная стратегия — приоритизация по вкладу в конверсию и трафик, а не по формальной полноте:
| Приоритет | Что переводить | Почему в первую очередь |
|---|---|---|
| 1 | Путь покупки: главная, топ-категории, чекаут, письма | Без этого локализация не конвертирует трафик вообще |
| 2 | Топ-товары по спросу на новом рынке | Основной источник органического трафика на новом языке |
| 3 | Юридические страницы, условия доставки/оплаты | Часто обязательны юридически и снимают возражения перед покупкой |
| 4 | Остальной каталог | Можно наращивать поэтапно, машинный перевод как черновик |
| 5 | Блог и второстепенный контент | Низкий приоритет для запуска, важен для долгосрочного SEO |
Частые ошибки, которые путают поисковики
- Hreflang проставлен только «в одну сторону» — с русской версии на английскую, но не обратно. Поисковик такую разметку в лучшем случае частично игнорирует.
- Нет self-referencing hreflang — страница не ссылается сама на себя в списке альтернатив, из-за чего граф соответствий неполный.
- Canonical всех языковых версий указывает на основной язык — прямой конфликт сигналов с hreflang.
- Значения атрибута hreflang заданы неверно (например, «ua» вместо корректного кода языка/региона) — поисковик не может сопоставить такие значения со стандартом и разметку игнорирует.
- Языковая версия создана, но не переведена — пустая или машинно переведённая заглушка, размеченная как полноценная альтернатива.
- Меню, футер и системные сообщения остаются на исходном языке, хотя контент страницы переведён.
- Валюта жёстко привязана к языку интерфейса, из-за чего часть пользователей видит цены в неудобной или неверной для их страны валюте.
- Переключатель языка на сайте — это ссылка на главную страницу другого языка, а не на языковой аналог текущей страницы, что раздражает пользователей и роняет поведенческие метрики.
Чек-лист запуска многоязычного сайта
- Схема URL зафиксирована. Подпапки/поддомены/ccTLD выбраны осознанно и не планируются к смене в обозримом будущем.
- Каждая языковая версия — отдельный SITE_ID. С корректной привязкой домена/пути и языковых файлов интерфейса.
- Hreflang выводится программно и полон. Двусторонние ссылки между всеми языками, включая self-reference и x-default.
- Canonical не конфликтует с hreflang. Каждая версия — self-canonical.
- Путь покупки переведён целиком. Меню, каталог, корзина, чекаут, письма — без непереведённых фрагментов.
- Валюта и единицы измерения отделены от языка. Пользователь может переключить их независимо.
- Юридические страницы локализованы. Оферта, политика конфиденциальности, условия доставки — под требования конкретной страны.
- Отчёты Search Console/Вебмастера без ошибок hreflang. Проверено после индексации всех языковых версий.
Вывод
Многоязычный сайт на 1С-Битрикс технически устроен просто — модуль многосайтовости и языковые файлы решают базовую задачу. Сложность не в запуске механизма, а в дисциплине: правильно выбранная раз и навсегда структура URL, полная двусторонняя разметка hreflang без конфликта с canonical и локализация, которая не останавливается на каталоге, а доходит до чекаута и юридических страниц. Сделайте это на старте — и каждый новый язык будет добавляться без риска обрушить позиции уже работающих версий.
