hreflang и многоязычное SEO магазина на Битрикс

Магазин выходит на второй язык — и начинается путаница. Русская и английская версии карточки одного товара конкурируют между собой в выдаче, поисковик показывает пользователю из Алматы русскоязычную страницу с ценами в рублях, а Google считает переводы дублями и режет позиции обеим версиям. Причина почти всегда одна: языковые версии не связаны корректно атрибутом hreflang, а структура сайта не даёт поисковику однозначно понять, кому какую версию показывать.

Ниже — практическое руководство по многоязычному SEO магазина на 1С-Битрикс: как устроен hreflang, чем язык отличается от региона, какую архитектуру выбрать (папки, поддомены или национальные домены), как всё это реализуется на платформе и как не наплодить дублей. Это выжимка из наших проектов по поисковому продвижению и SEO магазинов на 1С-Битрикс — без теории ради теории.

Что такое hreflang и зачем он магазину

hreflang — это атрибут, которым вы сообщаете поисковой системе, что у страницы есть версии на других языках или для других регионов, и указываете их адреса. Формально это набор тегов <link rel="alternate" hreflang="...">, которые связывают между собой все языковые варианты одного и того же контента.

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

Практический эффект от корректного hreflang на многоязычном магазине складывается из нескольких вещей:

• Правильная версия в выдаче. Пользователь из нужной страны или с нужным языком браузера видит подходящую версию, а не случайную.
• Отсутствие каннибализации. Языковые версии перестают конкурировать друг с другом за одни и те же запросы.
• Консолидация сигналов. Поисковик понимает, что версии связаны, и учитывает их авторитет как группы, а не как разрозненных дублей.
• Меньше отказов. Человек сразу попадает на понятный ему язык и корректную валюту — он не уходит с первого экрана.

Важно сразу зафиксировать границы: hreflang — это подсказка, а не жёсткая директива. Google обрабатывает его как сильный сигнал, но окончательное решение о показе принимает сам; Яндекс исторически опирается на другие механизмы геотаргетинга (об этом ниже). Поэтому hreflang работает не в вакууме, а вместе с грамотной архитектурой сайта, canonical и настройками региональности.

Язык, регион и локаль: не путайте понятия

Половина ошибок в hreflang рождается из-за путаницы между языком и регионом. Разберём аккуратно, потому что от этого зависит и синтаксис, и вся архитектура.

Значение атрибута hreflang состоит из двух частей:

• Код языка — обязателен, по стандарту ISO 639-1 в нижнем регистре: ru, en, de, kk (казахский), uk (украинский).
• Код региона (страны) — необязателен, по стандарту ISO 3166-1 Alpha-2 в верхнем регистре, через дефис: ru-RU, ru-KZ, en-US, en-GB.

Отсюда три типовых сценария, и их важно различать:

Ключевое правило: не указывайте регион, если у вас нет реально отдельной версии под этот регион. Частая ошибка — прописать en-US, en-GB, en-AU для одной и той же английской страницы. Если контент, цены и валюта идентичны — это один язык en, а не три региональные версии. Регион уточняет таргетинг только тогда, когда за ним стоит действительно разный контент: другая валюта, другой прайс, другие условия доставки, другой юридический текст.

Локаль — это уже про интерфейс и форматирование: формат даты, разделитель дробей, направление письма, валюта по умолчанию. В 1С-Битрикс локаль привязана к языку интерфейса сайта, но для SEO важно помнить, что locale и hreflang — разные слои. hreflang адресован поисковику и решает вопрос «какую версию показать», локаль адресована пользователю и решает «как отформатировать».

Архитектура многоязычного магазина

Прежде чем настраивать hreflang, нужно выбрать, где будут жить языковые версии. Это стратегическое решение: оно определяет и SEO-эффект, и трудоёмкость поддержки. Есть три базовых варианта размещения.

Подпапки на основном домене

Версии живут в путях: site.ru/, site.ru/en/, site.ru/kz/. Это самый простой и, для большинства магазинов, оптимальный вариант. Плюсы: языковые версии наследуют авторитет основного домена, всё под одним SSL и одной панелью, легко администрировать. Минус: геосигнал слабее, чем у национального домена, и одна страна не «привязывается» к версии автоматически.

Поддомены

Версии на поддоменах: en.site.ru, kz.site.ru. Поисковик воспринимает поддомен как относительно самостоятельный сайт, что даёт более чёткое разделение и возможность гибко таргетировать регион. Минус — авторитет распределяется, и каждый поддомен нужно «раскачивать» отчасти отдельно. Подробно про поддомены под регионы мы разбираем в отдельном материале о мультирегиональности и поддоменах для SEO.

Отдельные национальные домены (ccTLD)

Версии на доменах стран: site.kz, site.de. Это самый сильный геосигнал: домен .kz сам по себе говорит поисковику и пользователю о таргетинге на Казахстан. Но это и самый дорогой путь: каждый домен — отдельный сайт со своим авторитетом, своим SSL, своей регистрацией и продвижением. Оправдан, когда вы всерьёз выходите на рынок конкретной страны, а не просто добавляете перевод.

Для большинства магазинов на 1С-Битрикс мы рекомендуем начинать с папок: они дают быстрый старт, не размывают авторитет и легко разворачиваются штатной многосайтовостью платформы. К поддоменам и ccTLD переходят, когда бизнес реально работает как отдельный субъект в другой стране — с локальным юрлицом, складом и логистикой.

Как устроен hreflang: атрибуты и синтаксис

Технически hreflang — это набор тегов <link> в секции <head>. Каждый тег связывает текущую страницу с одной из её версий. Вот как выглядит полный блок для страницы, у которой есть русская, английская и казахстанская версии:

<link rel="alternate" hreflang="ru" href="https://site.ru/catalog/nasosy/" />
<link rel="alternate" hreflang="en" href="https://site.ru/en/catalog/pumps/" />
<link rel="alternate" hreflang="ru-KZ" href="https://site.ru/kz/catalog/nasosy/" />
<link rel="alternate" hreflang="x-default" href="https://site.ru/catalog/nasosy/" />

Разберём по частям:

• rel="alternate" — говорит, что это альтернативная версия текущей страницы.
• hreflang="ru" — язык (и опционально регион) версии.
• href="https://..." — абсолютный URL версии, обязательно с протоколом и доменом. Относительные пути здесь недопустимы.

Несколько правил синтаксиса, которые критично соблюдать:

1. Абсолютные URL. Всегда полный адрес https://site.ru/en/..., а не /en/....
2. Единый регистр кодов. Язык — строчными (en), регион — прописными (GB): en-GB. Ошибка регистра не критична для Google, но лучше держать стандарт.
3. Корректные коды. Язык по ISO 639-1, страна по ISO 3166-1 Alpha-2. Частая ошибка — en-UK вместо правильного en-GB (код Великобритании — GB, а не UK).
4. Одна страница — один язык. Каждый URL представляет ровно одну языковую версию; нельзя указывать один и тот же href для двух разных hreflang, если контент реально не разный.
5. Согласованность с canonical. Указанные в hreflang URL должны быть каноническими, а не редиректящими или закрытыми в noindex.

x-default и выбор языка по умолчанию

Специальное значение hreflang="x-default" отвечает на вопрос: «а что показать пользователю, который не подошёл ни под один из перечисленных языков и регионов?» Например, у вас версии ru, en, de, а на сайт зашёл человек с французской локалью. Ему поисковик покажет ту версию, которая помечена как x-default.

На x-default обычно назначают одну из двух вещей:

• Страницу-переключатель языков — если у вас есть отдельная посадочная, где пользователь сам выбирает язык/страну.
• Основную (наиболее универсальную) версию — чаще всего английскую или главную языковую, если отдельного переключателя нет.

x-default не обязателен, но настоятельно рекомендуется: без него поисковик сам решает, что показать «всем остальным», и это решение может оказаться не в вашу пользу. Для магазина, у которого есть аудитория за пределами перечисленных языков, x-default — способ не потерять этих людей.

Взаимность и самоссылка: главные правила

Два правила, из-за нарушения которых hreflang чаще всего «молча не работает». Их нужно запомнить как аксиомы.

Правило взаимности (двусторонности). Если страница A ссылается на страницу B через hreflang, то страница B обязана ссылаться обратно на A. Связи должны подтверждаться с обеих сторон. Если русская страница указывает на английскую, а английская на русскую не ссылается, Google проигнорирует такую одностороннюю связь целиком. Это самая массовая причина «hreflang настроен, но не учитывается».

Правило самоссылки. Каждая страница должна включать hreflang-ссылку саму на себя. То есть в блоке hreflang русской страницы обязательно присутствует тег с hreflang="ru", ведущий на неё же. Это не избыточность — так поисковик понимает, к какой группе относится текущий URL и какой у него собственный язык.

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

Три способа отдать hreflang поисковику

hreflang можно передать поисковику тремя способами. Они равноправны по эффекту, но различаются по трудоёмкости и области применения. Выбирайте один основной — смешивать не нужно.

Для магазина на 1С-Битрикс самый практичный вариант — теги в head при небольшом и среднем числе языков (2–4). Их просто сформировать в шаблоне, легко визуально проверить в исходном коде страницы и удобно отлаживать. Пример вывода в head приведён выше.

Если языков много и URL десятки тысяч, head начинает распухать (на каждой странице по блоку из всех версий), и тогда переносят hreflang в sitemap. Там связи задаются через элементы xhtml:link:

<url>
  <loc>https://site.ru/catalog/nasosy/</loc>
  <xhtml:link rel="alternate" hreflang="ru" href="https://site.ru/catalog/nasosy/"/>
  <xhtml:link rel="alternate" hreflang="en" href="https://site.ru/en/catalog/pumps/"/>
</url>

HTTP-заголовок Link нужен редко — в основном для PDF-каталогов и других не-HTML файлов, у которых нет head. Для обычных страниц магазина это избыточно.

Реализация в 1С-Битрикс

Многоязычность в 1С-Битрикс строится на модуле управления структурой и понятии «сайт» внутри одной установки. Одна физическая копия ядра может обслуживать несколько сайтов — и именно каждый такой сайт становится языковой версией. Разберём внедрение по шагам.

1. Создайте языки и сайты. В админке «Настройки → Настройки продукта → Сайты» заведите отдельный сайт под каждую языковую версию, укажите язык интерфейса и папку или домен (например, / для основного и /en/ для английского).
2. Настройте DocumentRoot и папку сайта. Для варианта с папками английский сайт указывает на подпапку /en/; ядро при этом общее. Для поддоменов и доменов настраивается многосайтовость на уровне веб-сервера.
3. Разведите инфоблоки или разделы контента. Под перевод каталога и статей заводят либо отдельные инфоблоки на каждый язык, либо языковые свойства/разделы внутри одного инфоблока. Оба подхода рабочие — выбор зависит от объёма и того, кто ведёт контент.
4. Свяжите страницы между версиями. Заведите карту соответствий: русская карточка ↔ английская карточка. Обычно это символьное свойство-ссылка (ID или код связанного элемента) в инфоблоке, по которому шаблон находит парную версию.
5. Сформируйте hreflang в шаблоне. В общем прологе или шаблоне компонента соберите блок <link rel="alternate" hreflang=...> на основе карты соответствий и выведите его через $APPLICATION->SetAdditionalCSS-подобный механизм или напрямую в head.
6. Настройте переключатель языков. В меню сайта добавьте переключатель, который ведёт на парную версию текущей страницы (а не всегда на главную), — это и UX, и дополнительный внутренний сигнал связи.

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

Многоязычный каталог и карточки товаров

Каталог — самая объёмная и самая чувствительная к ошибкам часть многоязычного магазина. Здесь важно правильно организовать хранение переводов и связей.

Есть два базовых подхода к хранению языкового контента каталога:

• Отдельные инфоблоки на язык. Русский каталог — один инфоблок, английский — другой. Плюс: чистое разделение, независимые разделы и ЧПУ. Минус: товары и остатки нужно синхронизировать между инфоблоками, и обмен с 1С усложняется.
• Один инфоблок с языковыми свойствами. Название, описание и метатеги хранятся в свойствах NAME_EN, DETAIL_TEXT_EN и т. п., а шаблон подставляет нужное по языку сайта. Плюс: единый источник товара, простой обмен с 1С. Минус: разрастание свойств и более сложный шаблон.

Для магазина, у которого один склад и один прайс на все языки, чаще удобнее второй подход — единый инфоблок с языковыми полями. Товар, цена и остаток одни, а меняется только витринный текст. Для случая, когда ассортимент и цены по странам реально разные, подходит разделение на инфоблоки. Тонкости многоязычной организации каталога мы отдельно разбираем в материале про многоязычный каталог на 1С-Битрикс.

Отдельная тема — метатеги карточек. Каждая языковая версия карточки должна иметь свой уникальный, переведённый title, description и H1. Автоперевод русского title в английский «на лету» даёт кривые, неоптимизированные под англоязычный спрос заголовки. Метатеги нужно задавать по языковому шаблону с подстановкой переведённых значений — это и есть контентная работа, без которой hreflang просто связывает плохие страницы.

URL, ЧПУ и структура языковых версий

URL языковых версий заслуживают отдельного внимания, потому что от них зависит и hreflang, и восприятие структуры поисковиком. Базовый принцип — предсказуемость и стабильность.

Есть два подхода к переводу самих ЧПУ:

• Перевод сегментов пути. /catalog/nasosy/ → /en/catalog/pumps/. Максимально дружелюбно к пользователю и к англоязычному SEO: слова в URL на языке версии. Требует ведения переведённых символьных кодов разделов и товаров.
• Единый ЧПУ с языковым префиксом. /catalog/nasosy/ → /en/catalog/nasosy/. Проще в поддержке: транслит один на все языки, меняется только префикс. Менее оптимально для англоязычной выдачи, но существенно дешевле.

В обоих случаях фундамент — корректно настроенные человекопонятные URL. Как настраивать символьные коды, транслитерацию и правила обработки адресов в 1С-Битрикс, мы подробно разобрали в статье про ЧПУ и человекопонятные URL в 1С-Битрикс. Для многоязычного магазина к этим правилам добавляется только языковой префикс и требование стабильности: URL версии не должен меняться при обмене с 1С, иначе hreflang и переключатель языков «поплывут».

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

Дубли, canonical и склейка версий

Главный страх при запуске многоязычья — «поисковик сочтёт версии дублями». hreflang как раз и снимает эту угрозу, но только в связке с правильным canonical. Разберём, как они работают вместе, потому что здесь легко всё сломать.

canonical решает проблему дублей внутри одного языка: разные URL с одинаковым содержимым (с параметрами сортировки, фильтра, UTM-метками) склеиваются к одной канонической версии. hreflang решает задачу связи между языками. Это разные слои, и их нельзя смешивать.

Золотое правило: каждая языковая версия канонична сама на себя. Английская страница ставит canonical на английскую же страницу, русская — на русскую. Нельзя ставить canonical английской страницы на русскую: так вы скажете поисковику «английская — это дубль русской, не индексируй её», и английская версия выпадет из выдачи. hreflang при этом ссылается на все версии, а canonical — только на себя.

Отдельный источник дублей — параметры и фильтры, помноженные на языки. Если у вас есть SEO-страницы умного фильтра, их тоже нужно связывать hreflang между языками и канонизировать внутри языка. Иначе комбинация «много языков × много фильтров» порождает лавину почти одинаковых URL. Управляйте этим строго: только осмысленные посадочные получают индексируемый URL и hreflang, остальное канонизируется и закрывается.

Разные страны в выдаче: геотаргетинг

hreflang сообщает поисковику про язык и регион, но геотаргетинг — это шире, чем один атрибут. Чтобы магазин показывался нужным пользователям в нужных странах, работают несколько сигналов вместе.

• hreflang. Связывает версии и подсказывает язык/регион каждой.
• Тип домена. ccTLD (.kz, .de) — сильнейший геосигнал для страны; папки и поддомены слабее.
• Настройки в панелях вебмастеров. Для Google — таргетинг по стране в Search Console (для gTLD-доменов), для Яндекс.Вебмастера — регион сайта в разделе «Региональность».
• Локальные сигналы. Адрес, телефон, валюта, локальный хостинг, ссылки с региональных ресурсов, разметка организации.

Важно понимать разницу подходов Google и Яндекса. Google активно использует hreflang и таргетинг по стране в Search Console. Яндекс исторически опирается на региональность из Вебмастера и Яндекс Бизнеса, а hreflang воспринимает слабее — для него регион сайта задаётся в явном виде. Поэтому для проекта, ориентированного на СНГ и Россию, региональность в Яндекс.Вебмастере — обязательный шаг наравне с hreflang. Про мультирегиональность в рамках одной страны и поддомены под города подробно рассказано в статье о мультирегиональности и поддоменах для SEO.

Перевод контента, а не машинный дубль

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

Что важно при подготовке языковых версий:

• Локализация, а не дословный перевод. Заголовки и метатеги нужно писать под спрос целевого языка: люди ищут не дословный перевод русского запроса, а свои формулировки. Здесь нужна работа с семантикой на языке версии.
• Адаптация фактуры. Валюта, единицы измерения, форматы, юридические тексты, условия доставки и оплаты — всё под рынок версии.
• Уникальность. Каждая версия — самостоятельная страница с уникальным текстом на своём языке, а не автоперевод в реальном времени.
• Полнота. Не оставляйте англоязычную версию наполовину на русском (кнопки, футер, служебные тексты) — смешанный язык путает и пользователя, и поисковик при определении языка страницы.

Хорошая новость: hreflang не требует, чтобы все страницы были переведены. Можно связывать только те, у которых есть парная версия, и постепенно наращивать охват. Плохая новость: то, что переведено, должно быть переведено качественно — иначе многоязычность превращается в генератор слабых страниц.

Как проверять hreflang

hreflang легко настроить с незаметной ошибкой, которая обнулит весь эффект. Поэтому после внедрения обязательна проверка. Пройдитесь по инструментам и приёмам:

1. Исходный код страницы. Откройте страницу, посмотрите head — убедитесь, что блок hreflang присутствует, URL абсолютные, коды языков корректные, есть самоссылка и x-default.
2. Взаимность вручную. Перейдите на английскую версию из блока hreflang русской — и проверьте, что в её head есть обратная ссылка на русскую. Так вы ловите односторонние связи.
3. Google Search Console. В отчёте по международному таргетингу (и в общих отчётах индексации) отслеживайте ошибки hreflang: «нет обратной ссылки», «неизвестный код языка».
4. Специализированные валидаторы и краулеры. Screaming Frog, Netpeak Spider и онлайн-проверялки hreflang массово обходят сайт и показывают несогласованные и односторонние связи.
5. Проверка canonical. Отдельно убедитесь, что каждая версия канонична сама на себя, а не на другой язык.

Диагностику стоит повторять после каждого крупного изменения структуры, добавления языка или большого обмена с 1С, который мог затронуть символьные коды и URL. Многоязычье — это система, и она ломается тихо: страница выглядит нормально, а поисковик связи уже не учитывает.

Частые ошибки

• Односторонние связи. A ссылается на B, а B на A — нет. Google игнорирует такой hreflang целиком. Всегда проверяйте взаимность.
• Нет самоссылки. Страница не включает hreflang сама на себя — поисковику непонятна её принадлежность к группе.
• canonical на другой язык. Английская версия канонизирована на русскую — и выпадает из индекса как «дубль».
• Относительные URL в hreflang. /en/... вместо https://site.ru/en/... — часть систем не разбирает такие ссылки.
• Неверные коды. en-UK вместо en-GB, регион там, где нужен только язык, выдуманные коды локалей.
• Ссылка на главную вместо парной страницы. Английская версия карточки ведёт на английскую главную, а не на английскую карточку этого товара.
• hreflang на несуществующие или noindex-страницы. Ссылка на пустую, редиректящую или закрытую от индексации версию.
• Автоперевод и подмена по IP на одном URL. Робот видит одну версию, остальные не индексируются; выглядит как отсутствие переводов.
• Смешанный язык на странице. Половина интерфейса не переведена — поисковик неверно определяет язык версии.
• Забыли про Яндекс. Настроили hreflang, но не задали регион сайта в Яндекс.Вебмастере — в Яндексе геотаргетинг не срабатывает.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность многоязычного магазина перед запуском:

1. Архитектура выбрана. Определено размещение версий — папки, поддомены или ccTLD — исходя из целей (языки или полноценные рынки).
2. Языки и сайты заведены. В 1С-Битрикс созданы сайты под каждую версию с корректным языком интерфейса и папкой/доменом.
3. Карта соответствий готова. Каждая страница знает адреса своих парных версий на всех языках через свойство-ссылку в инфоблоке.
4. hreflang сформирован. Блок выводится в head (или sitemap), URL абсолютные, коды корректные, есть самоссылка и x-default.
5. Взаимность соблюдена. Все связи двусторонние, блок hreflang идентичен на всех версиях страницы.
6. canonical настроен. Каждая версия канонична сама на себя, дубли параметров склеены внутри языка.
7. Метатеги переведены. У каждой версии свои уникальные title, description и H1 под спрос своего языка.
8. Переключатель языков ведёт на пару. Кнопка смены языка открывает соответствующую страницу, а не главную.
9. Геотаргетинг задан. В Google Search Console и Яндекс.Вебмастере выставлены страна/регион для каждой версии.
10. Проверка пройдена. Краулер и валидатор не показывают односторонних и несогласованных связей; canonical корректны.

Вывод

Многоязычное SEO магазина на 1С-Битрикс — это не «включить hreflang», а собранная система: продуманная архитектура версий, корректная карта соответствий страниц, взаимный hreflang с самоссылкой и x-default, правильный canonical у каждого языка и качественная локализация контента. Соберите эти звенья — и языковые версии перестанут конкурировать как дубли, а пользователь из каждой страны увидит именно свою версию с нужным языком, валютой и условиями. Ошибётесь в одном звене — и hreflang «молча» перестанет работать, поэтому проверка после запуска так же важна, как сама настройка.