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

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

Представьте ситуацию: ваш сайт example.ru успешно работает на русском, и вы решаете выйти на международный рынок. Создаёте английскую версию example.com, немецкую example.de, французскую example.fr. Контент переведён, структура настроена, страницы опубликованы. Но через несколько месяцев вы обнаруживаете, что в поисковой выдаче Google по запросу «best products» показывается русскоязычная версия страницы, а англоязычный пользователь уходит с сайта через три секунды, ничего не поняв. Знакомо?

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

Когда hreflang настроен правильно, Google понимает структуру вашего многоязычного сайта и показывает каждому пользователю ту версию, которая соответствует его языку интерфейса и географическому положению. Когда разметка отсутствует или содержит ошибки, поисковик вынужден самостоятельно определять, какую версию показывать, и часто ошибается. Русский пользователь в Калининграде может получить английскую версию, а американец из Нью-Йорка — русскую, просто потому что алгоритм не смог понять вашу структуру.

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

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

Четыре элемента правильного hreflang

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

<link rel="alternate" hreflang="en" href="https://example.com/" />

Он размещается в секции страницы и сообщает поисковой системе: «существует альтернативная версия этой страницы на английском языке по адресу example.com». Для полноценной работы hreflang на многоязычном сайте необходимо соблюсти четыре ключевых условия.

Полнота набора языковых версий

Первое и самое важное правило: набор hreflang-ссылок должен быть полным и взаимным. Если у вас есть русская версия страницы на example.ru и английская на example.com, то на русской странице должны стоять обе ссылки: и на русскую версию (саму на себя), и на английскую. На английской странице — тоже обе. Если вы укажете на русской странице только ссылку на английскую версию, но не укажете ссылку на саму себя, Google не сможет построить полную карту соответствий.

Представьте, что у вас три языка: русский (example.ru), английский (example.com) и немецкий (example.de). На каждой версии страницы должны быть указаны все три URL. Если на русской странице вы забыли указать немецкую версию, Google будет считать, что для немецкоязычных пользователей русская версия не существует, и потенциально проигнорирует её в выдаче для Германии. При этом если на немецкой странице ссылка на русскую есть, а обратной ссылки нет — это тоже ошибка: связь должна быть двунаправленной.

Полный набор hreflang на русской версии страницы будет выглядеть так:

<link rel="alternate" hreflang="ru" href="https://example.ru/" />
<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="de" href="https://example.de/" />

И ровно такие же три тега должны стоять на английской и немецкой версиях страницы, только каждый со своим href в качестве самоссылки.

X-default: страница по умолчанию

Второй элемент правильного hreflang — специальный код x-default. Это не языковой код, а служебное значение, которое указывает поисковой системе: «если язык пользователя не совпадает ни с одним из перечисленных, покажи эту страницу». Например, пользователь из Японии с японским интерфейсом браузера заходит на ваш сайт, где есть русская, английская и немецкая версии. Какую версию ему показать? Если среди hreflang-тегов есть x-default, Google покажет страницу, указанную в этом теге. Обычно это английская версия как наиболее универсальная, но вы можете выбрать любую.

Разметка с x-default выглядит так:

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

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

Корректный формат кодов языка

Третий элемент — правильный формат кодов. Hreflang использует коды, основанные на стандарте ISO 639-1 (для языков) и ISO 3166-1 Alpha 2 (для регионов). Код может состоять из двух букв (ru, en, de, fr), либо из двух букв языка, дефиса и двух букв региона (en-US, en-GB, pt-BR, zh-Hans). Важно понимать разницу: hreflang="en" указывает на английский язык в целом, а hreflang="en-US" — на английский для США, hreflang="en-GB" — на английский для Великобритании. Если у вас есть версии для США и Великобритании, коды должны различаться. Если версия одна на всех англоговорящих — используйте просто en.

Некорректные коды — например, hreflang="english" или hreflang="eng" (это код ISO 639-2, не 639-1), или hreflang="en_US" с подчёркиванием вместо дефиса — приведут к тому, что поисковая система проигнорирует тег. Google просто не поймёт, что вы имели в виду, и будет обрабатывать страницы как независимые, что может привести к дублям и неправильной выдаче.

Важно помнить про сочетания язык-регион: если вы указываете hreflang="en-US", это не означает автоматически, что пользователи из Великобритании получат эту версию. Для них нужна отдельная версия с кодом en-GB, либо общий код en без региона. Смешивать общие коды и региональные в пределах одной страницы можно, но нужно быть внимательным: если на странице указаны и en, и en-US, Google может не понять, какую версию показывать пользователю из Канады или Австралии.

Самоссылка (self-reference)

Четвёртый элемент — самоссылка. Согласно рекомендациям Google, каждая страница должна включать hreflang-ссылку сама на себя. То есть на русской версии страницы должен быть тег с hreflang="ru" и href, указывающим на эту же страницу. Это не ошибка и не дублирование — это способ подтвердить поисковой системе, что данная страница действительно является версией для русского языка. Отсутствие самоссылки не является критической ошибкой, но может привести к тому, что Google не включит страницу в карту соответствий hreflang, особенно если на странице есть ссылки на другие версии.

Самоссылка особенно важна при использовании параметров отслеживания или UTM-меток: если на странице example.ru/?utm_source=newsletter стоит hreflang-тег с href="https://example.ru/" без параметров, это нормально — инструмент сравнивает URL без query-параметров. Но если в href указан URL с параметрами, а каноническая версия — без параметров, могут возникнуть расхождения.

Как работает наш инструмент проверки hreflang: честный разбор

Теперь перейдём к практической части. В нашем GEO-агентстве мы разработали инструмент проверки hreflang, доступный по адресу /instrumenty/hreflang-check. Он создан для быстрой диагностики одной страницы, и мы хотим честно рассказать, что именно он умеет, как формирует результат и какие у него ограничения.

Принцип работы максимально прост: вы вводите URL страницы, инструмент делает один HTTP-запрос и анализирует HTML-код полученной страницы. Он ищет все теги <link rel="alternate" hreflang="..." href="...">. Важно отметить, что инструмент поддерживает оба варианта порядка атрибутов: сначала hreflang, потом rel, и наоборот — сначала rel, потом hreflang. Это сделано потому, что в реальной разметке встречаются оба варианта, и оба являются валидными с точки зрения HTML.

После сбора всех тегов инструмент проводит серию проверок и выдаёт итоговый статус. Вот пошаговый алгоритм:

Шаг 1. Проверка наличия тегов. Если на странице не найдено ни одного тега hreflang, инструмент сразу возвращает статус pass с сообщением «На странице нет тегов hreflang — это нормально для одноязычного сайта». Это принципиальная позиция: отсутствие hreflang — не ошибка. Для сайтов с одним языком разметка не нужна, и инструмент не считает это проблемой по умолчанию. Многие разработчики ошибочно полагают, что hreflang нужно добавлять всегда, но это не так: для одноязычного сайта это лишний код, который не даёт никаких преимуществ.

Шаг 2. Подсчёт найденных версий. Если теги найдены, инструмент считает количество уникальных языковых кодов и показывает эту цифру. Например, если вы указали ru, en и de — инструмент покажет «Найдено 3 языковые версии». Это полезно для быстрой сверки: вы видите, все ли версии, которые должны быть, присутствуют на странице.

Шаг 3. Проверка x-default. Инструмент ищет среди найденных кодов специальное значение x-default. Если оно присутствует — статус pass. Если отсутствует — статус warn с пояснением: «рекомендуется для страницы по умолчанию, если пользователь не попадает ни под одну из перечисленных версий». Это предупреждение, а не ошибка: x-default желателен, но не обязателен для каждой страницы.

Шаг 4. Проверка формата кодов. Каждый код (кроме x-default) сверяется с регулярным выражением, которое проверяет соответствие ISO 639-1-подобному формату. Допустимые варианты: две-три латинские буквы (например, ru, en, de, fr, zh), опционально дефис и две-четыре буквы региона (например, en-US, pt-BR, zh-Hans). Если код не соответствует формату — инструмент выдаёт статус fail с перечислением некорректных кодов. Например, если вы написали hreflang="ru_RU" с подчёркиванием, инструмент покажет ошибку и укажет, какой именно код некорректен.

Шаг 5. Проверка самоссылки. Инструмент сравнивает проверяемый URL (без query-параметров) с href каждой найденной hreflang-ссылки (тоже без query-параметров). Если среди найденных ссылок есть та, что указывает на проверяемую страницу — статус pass. Если нет — статус warn с пояснением, что самоссылка рекомендуется согласно руководству Google. Это предупреждение, а не ошибка: отсутствие самоссылки не критично, но может снизить эффективность разметки.

Шаг 6. Формирование итогового статуса. Общая логика проста: если хотя бы одна проверка формата кодов завершилась с ошибкой, итоговый статус — fail. Если ошибок формата нет, но есть хотя бы одно предупреждение (warn) — итоговый статус warn. Если все проверки прошли успешно — pass. Это стандартная логика агрегации: ошибки имеют приоритет над предупреждениями, предупреждения — над успешным прохождением.

Честный технический нюанс: как словарь скрывает дублирующиеся коды

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

Внутри инструмента все найденные пары «код языка → href» собираются в обычный PHP-массив, где ключом является код языка. Это стандартный, эффективный и удобный способ хранения данных: он позволяет быстро проверять наличие кода, получать значение href по коду и так далее. Но у такого подхода есть серьёзное ограничение, которое напрямую влияет на точность проверки.

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

<link rel="alternate" hreflang="ru" href="https://example.ru/old-page" />
<link rel="alternate" hreflang="ru" href="https://example.ru/new-page" />

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

Что произойдёт в нашем инструменте? Поскольку данные хранятся в массиве с ключом-кодом языка, второй встретившийся тег с тем же кодом просто молча заменит первый. Массив после обработки будет содержать только одну запись: ключ «ru» со значением href нового URL. Никакой ошибки или предупреждения инструмент не выдаст. Счётчик найденных версий покажет на единицу меньше, чем реальное количество тегов на странице, но вы об этом не узнаете — вы видите только итоговую цифру, а не исходный HTML. Ни одна из проверок (ни x-default, ни формат, ни самоссылка) не выявит проблему, потому что все они работают с уже обработанным массивом, где дубль уже схлопнулся в одну запись.

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

Почему это так важно? Потому что дублирующиеся коды — одна из самых опасных ошибок hreflang. Поисковая система, видя два тега с одинаковым кодом, но разными URL, не может понять, какая версия является правильной. Она может выбрать любой из них, может проигнорировать оба, может посчитать страницу дублем. В результате вы получаете непредсказуемое поведение в выдаче, а отладка такой ошибки крайне сложна, потому что визуально страница выглядит правильной — все теги на месте, коды корректны, x-default присутствует.

Что делать, чтобы поймать эту ошибку самостоятельно? Во-первых, после любых изменений в шаблоне или миграции открывайте исходный код страницы (Ctrl+U в браузере) и ищите все вхождения «hreflang». Считайте, сколько раз встречается каждый код. Если какой-то код встречается более одного раза — это ошибка, даже если адреса совпадают. Во-вторых, можно использовать консоль разработчика в браузере и выполнить JavaScript-код, который посчитает теги с одинаковыми hreflang. В-третьих, если вы работаете с большим сайтом, имеет смысл использовать серверные инструменты анализа, которые обрабатывают HTML-строку как последовательность тегов, а не как словарь.

Частые ошибки при настройке hreflang за пределами проверок инструмента

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

Несоответствие между hreflang и canonical. Если у вас на странице указан rel="canonical" на другой URL, чем href в hreflang-ссылке, поисковая система может запутаться. Например, на странице example.ru стоит canonical на example.com (скажем, вы используете пример.com как главное зеркало), а hreflang="ru" указывает на example.ru. Google не поймёт, какую страницу считать основной. Рекомендация проста: canonical должен указывать на ту же страницу, которая указана в hreflang для соответствующего кода. Если вы используете отдельные домены для разных языков, у каждой версии должен быть свой canonical на себя.

Отсутствие обратных ссылок. Мы уже упоминали это в контексте полноты набора, но повторим отдельно: если страница example.ru/ru ссылается на example.com/en через hreflang, то страница example.com/en должна обязательно ссылаться обратно на example.ru/ru. Если обратная ссылка отсутствует, Google может не признать пару и будет обрабатывать страницы как независимые. Это особенно часто случается при автоматической генерации hreflang, когда шаблон для одной версии страницы заполнен, а для другой — нет.

Несоответствие контента заявленному языку. Hreflang — это декларация. Если вы указываете hreflang="en" на странице, где контент на русском языке, поисковая система рано или поздно это обнаружит (пользователи будут быстро возвращаться в выдачу, поведенческие факторы ухудшатся) и может применить санкции. Проверьте, что реальный язык страницы соответствует коду в hreflang. Это особенно важно для региональных вариантов: если вы заявляете en-GB, контент должен быть адаптирован для Великобритании (орфография, терминология, возможно, цены в фунтах), а не просто скопирован с en-US.

Использование hreflang для страниц с разным смыслом. Hreflang предназначен для обозначения переводов одной и той же страницы. Если страницы различаются по смыслу (например, example.ru/products — каталог, а example.com/products — статья о продуктах), hreflang не нужен. Это не переводы, а разные страницы. Попытка связать их через hreflang приведёт к путанице.

Ошибки в URL. Кажется мелочью, но очень часто в href попадают опечатки, лишние слеши, неправильные протоколы (http вместо https), или параметры отслеживания. Инструмент сравнивает URL без query-параметров, но если в href стоит адрес с ошибкой, поисковая система не сможет найти эту страницу и просто проигнорирует тег.

FAQ по hreflang и работе инструмента

Нужен ли hreflang, если у меня сайт на двух языках, но поддомены разные?

Да, нужен. Независимо от того, используете ли вы отдельные домены (example.ru и example.com), поддомены (ru.example.com и en.example.com) или поддиректории (example.com/ru/ и example.com/en/), механизм hreflang работает одинаково. Он сообщает поисковой системе о связи между страницами и их языковой принадлежности.

Что делать, если у меня одна версия страницы, но я хочу показывать её пользователям из разных стран?

Если контент одинаковый для всех англоговорящих стран, используйте просто hreflang="en" без указания региона. Не нужно создавать отдельные версии для en-US, en-GB, en-AU, если контент не отличается. Если контент отличается (цены, доставка, контактная информация), тогда нужны отдельные страницы с кодами en-US, en-GB и так далее.

Может ли инструмент найти дублирующийся hreflang-код?

Нет, не может. Это техническое ограничение, связанное с хранением данных в виде словаря «код → URL». Если на странице два тега с одинаковым hreflang, но разными href, инструмент увидит только последний из них и не выдаст никакого предупреждения. Для поиска такой ошибки нужно открыть исходный код страницы и посчитать теги вручную или использовать специализированные инструменты, которые обрабатывают каждый тег отдельно. Мы рекомендуем всегда проверять исходный код после миграций или редактирования шаблонов.

Что такое x-default и когда его использовать?

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

Влияет ли hreflang на позиции в поисковой выдаче?

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

Можно ли использовать hreflang в XML-карте сайта?

Да, Google поддерживает указание hreflang-альтернатив в XML-карте сайта через элементы <xhtml:link>. Это альтернативный способ разметки, который может быть удобнее, чем размещение тегов в HTML каждой страницы. Однако если вы используете HTML-теги, XML-карта не обязательна. Главное — не дублировать разметку с противоречиями в обоих местах.

Практические рекомендации для разработчиков

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

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

Во-вторых, всегда проверяйте самоссылку. Когда вы генерируете hreflang-теги для страницы, убедитесь, что среди них есть тег с кодом языка этой страницы, указывающий на неё саму. Это особенно важно при использовании ЧПУ (человеко-понятных URL), когда адрес страницы может меняться при изменении структуры сайта.

В-третьих, после любой миграции (смена домена, переход на HTTPS, изменение структуры URL) полностью проверяйте все hreflang-теги на всех языковых версиях. Именно в такие моменты возникают дубликаты кодов и битые ссылки.

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

И наконец, используйте наш инструмент /instrumenty/hreflang-check для регулярных проверок, но помните о его ограничениях. Он отлично справляется с проверкой формата кодов, наличия x-default и самоссылки. Но для обнаружения дублирующихся кодов вам придётся заглянуть в исходный код. Мы сознательно не скрываем это ограничение, потому что честность важнее маркетинга. Лучше знать о слабом месте инструмента, чем слепо доверять ему и пропустить критическую ошибку.

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