Обсудить проект

Hreflang: настройка, типовые ошибки и проверка

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

Vladislav Krivorutsko20 июля 2026 г.7 мин чтения
Содержание

TL;DR — коротко о главном

  • Hreflang не повышает позиции. Его задача — показать нужную языковую версию нужному пользователю и не дать версиям конкурировать между собой
  • Три правила, на которых ломается почти всё: ссылки взаимные, каждая страница ссылается сама на себя, все URL абсолютные и отдают 200
  • Одна ошибка в одном кластере обычно отключает hreflang для всего кластера, а не для одной страницы
  • Способ размещения (в `<head>`, в sitemap или в HTTP-заголовке) на результат не влияет — выбирайте тот, который сможете поддерживать автоматически
  • Google относится к hreflang как к подсказке: даже при корректной разметке он иногда покажет другую версию

Короткий ответ

Hreflang — это разметка, которой вы сообщаете Google, что несколько страниц являются языковыми версиями друг друга. Она не повышает позиции: её задача — показать нужному пользователю нужную версию и не дать версиям конкурировать между собой в одной выдаче. Настройка сводится к трём правилам: ссылки взаимные, каждая страница ссылается сама на себя, все URL абсолютные и отвечают кодом 200.

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


Зачем hreflang нужен на самом деле

Формулировка «чтобы Google понимал языки» слишком расплывчата, чтобы по ней что-то настраивать. Практически hreflang решает две задачи.

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

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

Чего hreflang не делает:

  • не заменяет качественный контент на языке — если страница переведена машинно и не попадает в формулировки запросов, разметка её не спасёт (почему так, я разбирал в статье о том, на каком языке продвигать сайт в Эстонии);
  • не защищает от дублирования — языковые версии дублями и не считаются;
  • не является командой. Google называет hreflang сигналом, который он учитывает, но не обязан исполнять.

Как выглядит корректная разметка

Возьмём страницу услуги на сайте с тремя языками. В <head> каждой из трёх версий должен быть один и тот же набор тегов:

<link rel="alternate" hreflang="et" href="https://example.ee/teenused/seo" />
<link rel="alternate" hreflang="ru" href="https://example.ee/ru/uslugi/seo" />
<link rel="alternate" hreflang="en" href="https://example.ee/en/services/seo" />
<link rel="alternate" hreflang="x-default" href="https://example.ee/teenused/seo" />

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

Разместить разметку можно тремя способами, и на результат выбор не влияет:

СпособКогда удобенОграничение
Теги в <head>Обычные HTML-страницы, большинство сайтовРаздувает <head> при большом числе языков
XML-sitemapМного языков или нет доступа к шаблонуТруднее проверить глазами
HTTP-заголовок LinkPDF и другие не-HTML файлыНастраивается на уровне сервера

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

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


Шесть ошибок, которые встречаются чаще всего

Ниже — то, что я регулярно нахожу на многоязычных эстонских сайтах при техническом аудите. Порядок примерно соответствует частоте.

ОшибкаКак проявляетсяЧто делать
Невзаимные ссылкиGoogle игнорирует hreflang для всего кластераГенерировать разметку из общего источника, а не по странице
Нет самоссылкиСвязь считается неполной, разметка не учитываетсяДобавить hreflang на саму себя во всех версиях
Относительные URLРазметка не парситсяТолько абсолютные URL со схемой и доменом
Ссылка на редирект или 404Связь рвётся молчаПроверять статусы всех URL из разметки краулером
Конфликт с canonicalCanonical указывает на другую языковую версию — hreflang аннулируетсяCanonical каждой страницы указывает на неё саму
Автоматический редирект по языку браузераGooglebot видит только одну версиюЯзык предлагать баннером, а не навязывать редиректом

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

И ещё один момент, специфичный для Эстонии: код языка — не код страны. hreflang="ee" — распространённая опечатка, потому что домен .ee стоит перед глазами. Кода языка ee не существует, эстонский — это et. Такой тег просто игнорируется, и разметка становится неполной.


Как проверить, что Google принял разметку

Проверять нужно на трёх уровнях, и первые два не заменяют третий.

  1. Исходный код. Откройте страницу через «просмотр кода страницы», а не через инспектор элементов. Если теги появляются только в инспекторе, значит их подставляет JavaScript после загрузки — такая разметка может не попасть в индекс. Проверьте так по одной странице каждого типа: главная, категория, статья, карточка.
  2. Краулер. Screaming Frog или аналог обходит сайт и показывает то, что руками не найти: невзаимные пары, ссылки на редиректы, отсутствие самоссылки, конфликт с canonical. Это единственный практичный способ проверить сайт больше чем на полсотни страниц.
  3. Search Console. Финальная инстанция: она показывает, что Google принял, а не что вы отдали. Смотреть нужно отчёт по покрытию и статистику сканирования — если после внедрения hreflang часть страниц ушла в «Страница является копией», значит конфликтует canonical.

Ждать отражения изменений стоит недели, а не дни: Google должен переобойти все страницы кластера, чтобы увидеть взаимность ссылок. Это та же логика отложенной реакции, о которой я писал, разбирая, почему смена хостинга не ухудшает SEO — изменения видны только после переобхода.


Что я вижу на практике

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

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

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

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


Что сделать прямо сейчас

Короткая последовательность, если у вас есть вторая языковая версия и вы не уверены в разметке.

  1. Откройте исходный код одной страницы каждой версии и сверьте наборы тегов — они должны совпадать полностью, включая самоссылку.
  2. Проверьте canonical на неосновных языковых версиях: он должен указывать на саму страницу, а не на основной язык.
  3. Прогоните сайт краулером и отфильтруйте невзаимные связи и URL с кодами ответа, отличными от 200.
  4. Уберите автоматический редирект по языку браузера, если он есть, заменив его ненавязчивым баннером с предложением сменить язык.
  5. Убедитесь, что разметка генерируется, а не проставляется вручную. Если вручную — это первое, что стоит переделать на этапе веб-разработки, пока страниц немного.

Если после этих пяти шагов картина не сложилась или Search Console показывает что-то невнятное — напишите мне. Разбор многоязычной разметки обычно занимает пару часов и входит в технический SEO-аудит; чаще всего проблема оказывается не в hreflang, но найти это стоит до того, как вы вложитесь в контент второй версии.

Частые вопросы

Влияет ли hreflang на позиции в Google?
Напрямую — нет. Google заявляет, что hreflang не является фактором ранжирования: он помогает выбрать, какую из языковых версий показать конкретному пользователю. Косвенный эффект всё же есть: когда пользователю показывают версию на его языке, он реже возвращается в выдачу, и накопленные сигналы распределяются по версиям корректнее. Но ждать роста позиций от одной только настройки hreflang не стоит.
Обязательно ли hreflang должен быть взаимным?
Да, это жёсткое требование. Если страница A указывает на страницу B как на языковую версию, а B не указывает обратно на A, Google игнорирует такую связь. На практике это чаще всего означает отключение hreflang для всего кластера страниц, а не для одной ссылки. Поэтому разметку нужно генерировать из общего источника данных, а не проставлять вручную на каждой странице.
Нужен ли x-default и что в него ставить?
X-default не обязателен, но полезен: он указывает версию по умолчанию для пользователей, чей язык не совпал ни с одной из указанных. Обычно в него ставят либо главную языковую версию сайта, либо страницу выбора языка. Для эстонского бизнеса с эстонской, русской и английской версиями логично указывать в x-default основную версию, а не заводить отдельную страницу-переключатель.
Что писать в hreflang: только язык или язык со страной?
Если вы разделяете аудиторию по языку — достаточно кода языка: et, ru, en. Код страны (например, ru-EE) нужен только тогда, когда у вас есть отдельные версии для одного языка в разных странах — например, русская версия для Эстонии и русская для Латвии с разными ценами. Указывать регион без такой необходимости — лишний источник ошибок: код страны без кода языка недопустим вовсе.
Как проверить, что hreflang работает?
Есть три уровня проверки. Первый — исходный код страницы: посмотрите, что теги действительно отдаются в HTML, а не подставляются JavaScript после загрузки. Второй — краулер вроде Screaming Frog: он покажет невзаимные ссылки, ссылки на редиректы и 404. Третий и главный — отчёт по международному таргетингу и покрытию в Search Console, который отражает то, что Google реально принял, а не то, что вы отдали.
Считается ли разный язык дублированием контента?
Нет. Языковые версии одной страницы дублями не считаются, санкций за них не бывает, и hreflang нужен не для защиты от них. Реальная проблема — каннибализация внутри одного языка, когда две страницы на одном языке борются за один и тот же запрос. Hreflang в этом случае не поможет: нужно разводить страницы по интентам или склеивать их canonical.

Выводы

Hreflang — это гигиена многоязычного сайта, а не рычаг роста. Правильно настроенный, он не даст вам позиций, но убережёт от ситуации, когда эстоноязычному пользователю в выдаче показывается русская версия страницы, и он уходит, не дочитав заголовок. Настраивайте его один раз генерацией из кода, а не руками, и проверяйте отчёт в Search Console после каждого изменения структуры URL. Если у вас две-три языковые версии и вы не уверены, что Google связал их между собой, — напишите, я посмотрю разметку и скажу, где она рвётся.

Автор статьи

Владислав Криворучко — основатель ADLAB
Владислав Криворучко

Основатель ADLAB OÜ · SEO и Google Ads

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

  • 20+ лет в поисковом трафике
  • 50+ проектов под ключ
  • Собственные сайты в конкурентных нишах
  • SEO для ru/et/en в одной выдаче
Подробнее обо мне

Читать дальше