Hreflang для мультиязычных сайтов

Hreflang — атрибут, который сообщает поисковикам, какая языковая или региональная версия страницы должна показываться в выдаче конкретному пользователю. Без него Google и Яндекс самостоятельно решают, что показать россиянину на запрос «купить кроссовки» — русскую или украинскую версию сайта, и нередко ошибаются. Разбираем способы внедрения hreflang, правила парных ссылок, типичные ошибки и особенности для белорусских проектов с продвижением сайтов на нескольких языках.

Hreflang: значение атрибута и область применения

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

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

Важно понимать разницу между понятиями «язык контента» и «целевой регион». Hreflang может указывать только язык (например, en — английский для всех регионов), только регион через комбинацию языка и страны (например, en-GB — британский английский), или оба параметра одновременно. Атрибут не определяет физическое размещение сервера, доменную зону или платёжную валюту страницы — только аудиторию, которой предназначен контент.

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

Когда нужен hreflang, а когда нет

Hreflang применяется не для всех сайтов с несколькими языковыми версиями — есть конкретные сценарии, когда атрибут действительно нужен, и сценарии, где он избыточен или даже вреден. Прежде чем тратить ресурсы разработчиков на внедрение, важно проверить, попадает ли проект в одну из категорий, где hreflang оправдан. Для проектов с продвижением сайтов на международном уровне правильная настройка hreflang часто оказывается решающим фактором между захватом локальных рынков и потерей трафика на «соседние» регионы.

Когда hreflang обязателен

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

Вторая ситуация — региональные версии на одном языке для разных стран. Например, интернет-магазин с версиями example.com/ru/ для России, example.by/ru/ для Беларуси, example.kz/ru/ для Казахстана. Контент похож, но цены, доставка, валюта различаются. Без hreflang алгоритм объединяет страницы как почти дубли и оставляет в индексе только одну — то есть пользователи из других стран не получают свою версию.

Третья ситуация — комбинация языка и региона. Например, испаноязычный контент для Испании и Латинской Америки: es-ES и es-MX. Тексты на испанском, но с разными платёжными системами, доставкой, нормативами. Hreflang помогает разнести эти версии для разных регионов внутри одного языка.

Когда hreflang не требуется

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

Не требуется hreflang для дублирующего контента, который технически разнесён по разным URL (например, версия для печати или AMP-страница) — для этого используют canonical. Также атрибут не помогает в ситуациях, когда сайт работает только в одной стране, но имеет переключатель валют или языка интерфейса (без полного перевода контента) — это решается через cookies и куки-настройки, а не через hreflang.

Способы добавления hreflang на сайт

Существует три способа технической реализации hreflang. Каждый имеет свою область применения, преимущества и ограничения. Выбор зависит от типа сайта (HTML-страницы, PDF-документы, динамические URL), доступа к разработке и масштаба проекта.

На малых и средних сайтах с несколькими языковыми версиями обычно достаточно одного способа — добавления тегов в HTML-секцию head. Для крупных международных проектов с тысячами URL комбинируют способы: HTML-разметка для основных страниц, XML-карта для глубокого охвата, HTTP-заголовки для PDF-документов и медиафайлов. Главное правило — какой бы способ ни выбран, он должен применяться единообразно на всём сайте, потому что смешанные подходы создают противоречия в обработке атрибута поисковыми ботами.

Hreflang в HTML-секции head

Самый распространённый и интуитивный способ предполагает добавление тегов <link rel="alternate"> внутри секции <head> каждой страницы. Каждый тег связывает текущую страницу с альтернативной версией на другом языке или в другом регионе.

<link rel="alternate" hreflang="ru" href="https://example.com/ru/page/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/page/" />
<link rel="alternate" hreflang="be" href="https://example.com/be/page/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page/" />

Преимущество этого способа — простота реализации в большинстве CMS (Content Management System, система управления контентом) через плагины или встроенные функции (WordPress: WPML, Polylang; OpenCart: модуль мультиязычности; 1С-Битрикс: API многосайтовости). Недостаток — теги нужно добавить на каждую страницу всех языковых версий, что увеличивает HTML-разметку и при большом количестве версий может занимать десятки строк в head.

Hreflang в HTTP-заголовках

Для не-HTML файлов (PDF, изображения, документы) теги в head добавить нельзя — у таких файлов нет HTML-разметки. Здесь применяется HTTP-заголовок Link, передаваемый сервером при ответе на запрос файла. Формат заголовка:

Link: <https://example.com/ru/doc.pdf>; rel="alternate"; hreflang="ru",
      <https://example.com/en/doc.pdf>; rel="alternate"; hreflang="en"

Этот способ требует доступа к настройкам веб-сервера или платформы хостинга. На Apache настройка делается через .htaccess или конфигурацию виртуального хоста. На Nginx — через директивы add_header. На облачных платформах вроде Cloudflare или AWS — через настройки CDN или Lambda Edge. При неправильной настройке заголовок может транслироваться не на все запрашиваемые файлы, а это приведёт к разрыву связности hreflang.

Hreflang в XML-карте сайта

Третий способ опирается на указание hreflang внутри XML-карты сайта через расширение xhtml:link. Этот вариант особенно удобен для крупных проектов с тысячами страниц, потому что вся информация о языковых связях концентрируется в одном файле и не требует правки разметки каждой страницы.

<url>
  <loc>https://example.com/ru/page/</loc>
  <xhtml:link rel="alternate" hreflang="ru"
    href="https://example.com/ru/page/" />
  <xhtml:link rel="alternate" hreflang="en"
    href="https://example.com/en/page/" />
  <xhtml:link rel="alternate" hreflang="x-default"
    href="https://example.com/page/" />
</url>

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

Правила использования hreflang

Hreflang — формат с жёсткими правилами синтаксиса. Нарушение любого из них приводит к тому, что поисковик игнорирует разметку и возвращается к собственному определению языковой версии. Ниже разбираем ключевые правила, нарушения которых встречаются чаще всего на проектах.

Правила распадаются на три блока: формат значений (коды языка и региона по ISO-стандартам), архитектурные требования (парность ссылок и обязательная самоссылка) и резервные значения (x-default для пользователей, не подходящих ни под одну заявленную версию). Несоблюдение любого блока обнуляет смысл всей разметки — частичное применение hreflang работает хуже, чем полное отсутствие атрибута, потому что вводит поисковика в заблуждение и часто приводит к худшим позициям, чем при пустой разметке.

Коды языка и региона

Атрибут hreflang принимает значения по строго определённым стандартам. Язык кодируется по ISO 639-1 (двухбуквенные коды): ru — русский, en — английский, be — белорусский, uk — украинский. Регион (опциональная часть после дефиса) кодируется по ISO 3166-1 alpha-2 (двухбуквенные коды стран): BY — Беларусь, RU — Россия, KZ — Казахстан, UA — Украина.

Комбинация записывается через дефис: ru-BY — русский язык для Беларуси, en-GB — английский для Великобритании. Регион пишется в верхнем регистре, язык — в нижнем. Запись с обратным регистром (RU-by или EN-gb) формально не запрещена, но плохо распознаётся валидаторами и часто фиксируется как ошибка.

Распространённая ошибка — использование кода страны там, где нужен код языка. Например, uk в hreflang — это украинский язык, а не Великобритания (Великобритания будет GB, а в комбинации en-GB). Чтобы избежать путаницы, перед внедрением hreflang полезно сверяться с официальной таблицей IANA или валидаторами.

x-default и запасная версия

Специальное значение x-default указывает страницу, которая показывается пользователям, не подходящим ни под одну из заявленных языковых или региональных версий. Это «запасная» версия — обычно главная страница сайта на основном языке или специальная страница выбора региона/языка.

x-default не заменяет другие значения hreflang — он работает вместе с ними. Пример: сайт имеет версии для русского (ru), английского (en) и польского (pl), плюс главную страницу с переключателем языков как x-default. Пользователю из Бразилии (португальский) или Японии (японский) поисковик покажет именно x-default, потому что бразильского и японского варианта в hreflang не заявлено.

На практике в качестве x-default чаще всего используют одну из двух стратегий. Первая — указать главную страницу сайта на основном языке (для большинства русскоязычных проектов это company.by/). Вторая — создать специальную страницу выбора региона со списком стран и языков, доступных на сайте. Первая стратегия проще и подходит для большинства проектов. Вторая нужна для крупных международных компаний с реально разными версиями под десятки рынков, где «один основной язык» теряет смысл.

Парность ссылок на все языки

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

Например, у сайта есть три версии: русская, английская, белорусская. На странице русской версии должны быть три ссылки hreflang — на русскую (саму себя), английскую и белорусскую. На странице английской версии — также три ссылки на все три версии. И на белорусской — те же три ссылки. Это означает, что для трёх языков нужно 3×3 = 9 связей; для пяти языков — 5×5 = 25 связей.

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

Типичные ошибки при настройке hreflang

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

По характеру ошибки можно разделить на синтаксические (неверный код языка или региона, нарушения формата), структурные (отсутствие самоссылки, несимметричные ссылки между версиями) и взаимодействие с другими атрибутами (конфликт с canonical, noindex, robots.txt). Каждая категория требует своего инструмента диагностики: синтаксис проверяется через валидаторы, структура — через краулеры вроде Screaming Frog, взаимодействие — через Google Search Console и Яндекс Вебмастер.

Отсутствие самоссылки

Самая частая ошибка возникает, когда на странице русской версии указаны hreflang только для английской и белорусской, но нет ссылки на саму себя. Алгоритм расценивает такую разметку как неполную и применяет её ограниченно — например, использует для определения языковых пар, но не передаёт авторитет между версиями. Диагностика: проверить через Screaming Frog или Sitebulb наличие самоссылки на каждой странице с hreflang.

Решение — при формировании списка hreflang всегда включать в него текущий URL. В большинстве CMS-плагинов мультиязычности это делается автоматически, но при ручной разметке шаблонов часто упускается. Полезно прописать самоссылку в шаблоне как первую строку, а альтернативные версии добавлять после.

Ошибки в кодах языка и региона

Вторая распространённая ошибка — неправильные коды. Самые частые варианты: использование кода страны вместо языка (uk для Великобритании вместо en-GB), регион в нижнем регистре (en-gb вместо en-GB), несуществующие комбинации (en-EN — английский для «страны EN», такой страны нет), устаревшие коды (cz вместо cs для чешского).

Все эти ошибки выявляются через Search Console: в разделе «Отчёты о покрытии» появляются предупреждения о невалидных значениях hreflang. Также проверка делается через специализированные валидаторы — Aleyda Solis hreflang generator или встроенные функции в Screaming Frog.

Несимметричные ссылки

Третья ошибка состоит в том, что ссылки идут только в одну сторону. Русская страница ссылается на английскую, но английская — нет (или ссылается, но не на русскую, а на какую-то другую страницу). Поисковик расценивает такую разметку как ошибочную и игнорирует её. Это часто случается при миграции URL или при правке шаблонов на одной из версий без обновления других.

Диагностика: краулинг сайта через инструменты вроде Screaming Frog с включённым модулем проверки hreflang. Инструмент выявляет все несимметричные пары и показывает, какие связи нужно восстановить. Для крупных проектов имеет смысл настроить автоматическую генерацию hreflang на стороне сервера, чтобы исключить ручные ошибки.

Ссылки на страницы с редиректом

Четвёртая ошибка — hreflang указывает на URL, который возвращает 301 или 302 редирект. Когда такая ситуация возникает, поисковик не знает, на какую страницу ссылается hreflang — на исходный URL или на конечный. По правилам Google, hreflang должен указывать на конечный URL без редиректов и без noindex.

Эта ошибка часто появляется после рестайлинга сайта или смены URL-структуры. Решение — после любой миграции URL обновить все hreflang-ссылки на новые конечные адреса. Дополнительно стоит проверить, что страницы, указанные в hreflang, не закрыты от индексации через robots.txt или meta-тег noindex.

Hreflang на странице с noindex

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

Диагностика: проверить, что все URL, упомянутые в hreflang, доступны для индексации (нет noindex, нет блокировки в robots.txt, нет canonical на другой URL). Особенно частая ситуация — версия на втором языке создана как «черновик» с noindex для тестирования, но в hreflang уже указана. Решение: либо открыть страницу для индексации, либо убрать её из hreflang до публикации.

Особенности настройки hreflang для проектов в Беларуси

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

Для большинства белорусских компаний работа с hreflang начинается тогда, когда бизнес выходит на рынки России, Казахстана или дальнее зарубежье. До этого момента русскоязычной версии достаточно: и Google, и Яндекс корректно ранжируют белорусский сегмент по геопривязке через Вебмастер и Business Profile без всяких hreflang. Атрибут становится необходим только при появлении второй языковой или второй региональной версии — но в этот момент его внедрение нужно делать сразу полным и корректным, потому что частичная разметка часто работает хуже, чем её отсутствие.

Нормативные требования и языковые версии

В Беларуси действуют два государственных языка — русский и белорусский. Закон РБ «О языках» утверждается актами Совета Министров РБ и требует размещения информации на сайтах государственных органов и ряда регулируемых сфер (медицина, банки, ЖКХ) на обоих языках. Для коммерческого сайта формально требований нет, но при работе с госзаказчиками и в тендерах наличие белорусской версии повышает доверие.

Если на сайте есть русская и белорусская версии — обязательно настроить hreflang. Без него Яндекс и Google могут показывать только одну из версий, обычно русскую (как версию с большим объёмом контента и ссылок). Это лишает белорусскоязычных пользователей доступа к их версии через поиск. Правильная разметка: ru-BY для русской версии Беларуси и be-BY для белорусской.

Региональные различия русского языка для СНГ

Для белорусских компаний, работающих на рынки России, Беларуси, Казахстана и других стран СНГ, важна правильная региональная разметка одного и того же русского языка. У многих экспортёров возникает вопрос: достаточно ли одного ru или нужно разносить на ru-BY, ru-RU, ru-KZ. Ответ зависит от того, есть ли у сайта реально разные региональные версии — с разными ценами, доставкой, юрлицом-поставщиком.

Если контент на русском одинаков для всех стран — достаточно одного hreflang ru. Если есть отдельные страницы под Беларусь (с УНП — учётным номером плательщика, белорусскими телефонами, ЕРИП — Единым расчётным и информационным пространством), под Россию (с ИНН, российскими ценами в рублях), под Казахстан (с БИН, тенге), нужны отдельные региональные hreflang: ru-BY, ru-RU, ru-KZ. И на каждой странице должна быть полная парность с самоссылкой и x-default.

Города и региональная геопривязка

Hreflang не работает на уровне города — атрибут оперирует только странами. Для геопривязки на уровне Минска, Гомеля, Могилёва, Витебска, Гродно или Бреста используется отдельный механизм: Яндекс Вебмастер (раздел «Региональность», Lr-код 157 для Минска и 149 для Беларуси в целом) и Google Business Profile с отдельной карточкой компании в каждом городе.

Типичная архитектура для белорусского мультирегионального проекта: основной сайт company.by с hreflang ru-BY, внутри — разделы по городам /minsk/, /gomel/, /mogilev/, /vitebsk/, /grodno/, /brest/. Городская геопривязка задаётся через Яндекс Вебмастер и Google Business Profile, а hreflang остаётся одинаковым для всех городских разделов. Это позволяет работать одновременно с продвижением сайтов на всю Беларусь и с локальной выдачей в каждом областном центре.

Частая ошибка — попытка задать разные hreflang для разных городских разделов одного домена (например, ru-BY-MSQ для Минска, ru-BY-HMV для Гомеля). Такая разметка не работает: hreflang не поддерживает суб-регионы внутри страны, и поисковик игнорирует попытки задать их через ISO-расширения. Городская геопривязка решается только через инструменты Яндекс Вебмастера и Google Business Profile — но не через hreflang.

SEO-продвижение и контекстная реклама в Cropas

Команда Cropas настраивает hreflang для белорусских компаний, выходящих на рынки СНГ и зарубежные рынки: проектирует схему разметки на этапе разработки сайта, согласует её с языковыми версиями и интегрирует с региональной геопривязкой через Яндекс Вебмастер и Google Business Profile.

Для проектов, которые параллельно с органическим продвижением запускают платный трафик в Беларуси и СНГ, мы выстраиваем кампании контекстной рекламы в Яндекс Директ с разделением по странам — каждая региональная версия получает свой пул объявлений и собственные посадочные.

Часто задаваемые вопросы

Что произойдёт, если на сайте есть две языковые версии, но hreflang не настроен?

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

Можно ли использовать hreflang и canonical одновременно?

Да, и это рекомендуемая практика. Canonical указывает основную версию страницы (например, без UTM-параметров — Urchin Tracking Module, параметры отслеживания источников трафика), а hreflang — её альтернативные языковые версии. На странице должны быть оба тега: rel="canonical" с указанием на самую страницу (или базовый URL без параметров) и rel="alternate" с hreflang для каждой языковой версии. Главное — canonical и hreflang должны указывать на одну и ту же страницу: если canonical указывает на другой URL, hreflang будет проигнорирован.

Как проверить, корректно ли настроен hreflang?

Несколько инструментов. Google Search Console показывает ошибки hreflang в отчёте «Покрытие» и «Международные настройки». Яндекс Вебмастер — в разделе «Диагностика». Screaming Frog SEO Spider краулит сайт и выводит полный отчёт о hreflang-связях, включая несимметричные пары и битые ссылки. Также есть бесплатные онлайн-валидаторы — Aleyda Solis Hreflang Tags Generator, Merkle SEO Hreflang Generator.

Можно ли указать в hreflang страницу с другого домена?

Да, hreflang поддерживает межсайтовые связи. Часто используется в схеме «один бренд — несколько национальных доменов»: example.com для США, example.co.uk для Великобритании, example.de для Германии. В этом случае hreflang на странице example.com указывает на example.co.uk и example.de — и наоборот. Главное условие — все домены должны быть подтверждены одним владельцем в Search Console.

Какой код hreflang использовать для белорусскоязычной версии сайта?

Чистый язык — be (по ISO 639-1, белорусский). Если белорусскоязычная версия ориентирована именно на Беларусь (что в большинстве случаев так) — be-BY с указанием страны. Для русскоязычной версии того же белорусского сайта — соответственно ru или ru-BY. Если на сайте есть и русская, и белорусская версии для Беларуси — обязательно использовать оба полных кода (ru-BY + be-BY), чтобы Google и Яндекс не объединяли их в один кластер.

Влияет ли hreflang на ранжирование?

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

Что такое x-default и обязательно ли его указывать?

x-default — специальное значение hreflang для «запасной» страницы, которая показывается пользователям, не подходящим ни под одну из заявленных языковых или региональных версий. Например, бразильский пользователь португалоязычный, а сайт имеет только русскую и английскую версии — поисковик покажет x-default, обычно главную страницу с переключателем языков. Google рекомендует указывать x-default всегда, но формально это не обязательно. Без x-default Google определяет версию по своим алгоритмам, что чаще даёт менее предсказуемый результат.

Как настроить hreflang при использовании плагинов мультиязычности WordPress?

Популярные плагины (WPML, Polylang, TranslatePress) автоматически генерируют hreflang при правильной настройке. После активации плагина и создания языковых версий нужно проверить через View Source, что теги <link rel="alternate" hreflang="..."> присутствуют в head каждой страницы. Если их нет — войти в настройки плагина и активировать опцию «SEO» или «Hreflang». При использовании других CMS (OpenCart, 1С-Битрикс, Tilda, Webflow) логика аналогичная — встроенная мультиязычность обычно включает автоматическую разметку hreflang.

Как часто нужно обновлять hreflang при добавлении новых страниц?

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