Теги hreflang: Полное руководство по внедрению 2026 года от ConveyThis

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

· Алекс Б · Блог

Подведите итог этому посту следующим образом: 11 мин чтения

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

Если Google показывает URL-адрес на неправильном языке в результатах поиска или ваши переведенные страницы трудно обнаружить, это руководство предназначено для вас. Google документирует поддерживаемые подходы в своем руководство по локализованным версиям.

hreflang — одна из тех технических тем SEO, которая объясняется снова и снова, но никогда не дает четкого ответа, поскольку большинство объяснений пропускают те части, которые действительно ломаются в процессе производства. Четырехстрочный пример работает нормально, пока у вас нет 23 языков, региональных вариантов, альтернативных форматов страниц и процесса оформления заказа, который находится в поддомене. Тогда небольшие несоответствия могут оставить части языкового кластера нераспознанными.

В этом руководстве рассматривается реализация, которая работает в реальном мире. Не версия учебника. Версия, в которой Cloudflare кэширует ваши заголовки, Next.js генерирует страницы по требованию, а ваша CMS добавляет конечные косые черты, которых нет в вашей карте сайта.

Что на самом деле делает (и не делает) hreflang

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

Это различие имеет значение. Добавление hreflang не повысит рейтинг вашей французской страницы во Франции. Он сообщает Google: “эта английская страница и эта французская страница являются эквивалентными переводами одного и того же контента. Когда кто-то ищет на французском языке из Франции, покажите ему французский вариант.” Без этого Google все равно мог бы ранжировать вашу французскую страницу, но он также мог бы предоставить вашу английскую страницу французским поисковикам — или, что еще хуже, рассматривать оба контента как дублирующий и выбирать один для понижения.

Три вещи, которые делает hreflang:

  • Направляет нужную языковую версию нужному пользователю.
  • Помогает Google понять, что похожие переведенные страницы предназначены для разных аудиторий.
  • Объединяет эквивалентные языковые или региональные варианты в кластер.

Три вещи, которые hreflang не делает:

  • Переведите свой контент (очевидно, но стоит отметить).
  • Улучшить рейтинги на едином рынке.
  • Исправьте плохое качество перевода или скудный контент.

Основной синтаксис (и почему большинство примеров неполны)

Вот версия, которую вам показывают большинство гидов. Это правильно, но в нем также отсутствует самая важная строка:

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

В этом фрагменте объявлены версии на трех языках. Частично это сработает. Проблема: каждая страница, использующая эти теги, должна ссылаться на себя в списке. В противном случае Google будет считать ссылки однонаправленными и может их отбросить.

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

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

Изменились две вещи:

  • Самореферентный хрефланг. Английская страница теперь объявляет себя английской версией. Без него набор является неполным и не может быть интерпретирован так, как предполагалось.
  • х-по умолчанию. Здесь объявляется резервная страница для пользователей, язык которых не соответствует какой-либо указанной версии. Если на ваш сайт заходит корейский пользователь, а у вас нет корейского языка, x-default сообщает Google, какую страницу обслуживать.

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

На французской странице:

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

Идентичен английской странице. В этом-то и суть. Объявления hreflang должны быть взаимными — каждая языковая версия должна ссылаться на каждую другую языковую версию. Если страница A указывает на страницу B, страница B должна указывать обратно на страницу A. Google называет их “тегами возврата”, и это единственное правило проверки, которое чаще всего терпит неудачу в международном SEO.

Языковые коды: шпаргалка

Коды hreflang соответствуют формату language или language-REGION. В языках используется стандарт ISO 639-1 (двухбуквенный, строчный). В регионах используется стандарт ISO 3166-1 Alpha 2 (две буквы, заглавные). Наиболее распространенные заблуждения:

КодЧто это на самом деле означаетРаспространенная ошибка
enАнглийский (любой регион)Использование “en”, когда вы имеете в виду конкретно en-US
en-USАнглийский для пользователей из СШАЗапись en-us (регион нижнего регистра) — недействительна
en-GBАнглийский для Соединенного КоролевстваНаписание en-UK — UK не является допустимым кодом страны
zh-HansУпрощенный китайский (на основе письменности)Использование zh-CN, когда вы имеете в виду скрипт, а не регион
zh-HantТрадиционный китайскийИспользование zh-TW для всех пользователей традиционного китайского языка
pt-BR / pt-PTБразильский / Европейский португальскийИспользуя just “pt” — Бразилия и Португалия значительно различаются
es-419Латиноамериканский испанский (код региона ООН)Использование es-MX в качестве замены для всего LATAM
x-defaultРезервный вариант для непревзойденных языковПропуск; указание страницы, специфичной для региона

Великобритания — это не код страны. Это самая частая ошибка, которую я видел за 10 лет проверок. Код ISO 3166-1 для Соединенного Королевства — GB. Использовать en-GB, нет en-UK. Google молча игнорирует недействительные коды — ваш тег существует, но он ничего не делает.

Три метода реализации

hreflang можно объявить в трех местах. У каждого есть свои компромиссы.

Метод 1: HTML <head> теги (наиболее распространенные)

Теги, размещенные в <head> раздел каждой страницы. Легко отлаживать, легко проверять, поддерживается каждой CMS. Недостаток: каждая страница должна включать теги всех остальных языков, а это значит, что для создания и синхронизации 500 объявлений hreflang на 50 страницах на 10 языках требуется 500 объявлений hreflang.

Используйте этот метод, если на вашем сайте менее ~10 000 страниц или ваша CMS автоматически обрабатывает генерацию hreflang.

Метод 2: HTTP-заголовки (для файлов, отличных от HTML)

hreflang можно отправить как заголовок HTTP-ссылки. Это единственный способ объявить hreflang для ресурсов, отличных от HTML, таких как PDF-файлы:

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

Используйте заголовки HTTP, если у вас есть загружаемые ресурсы на нескольких языках — руководства по продуктам, нормативные документы, официальные документы.

Метод 3: XML-карта сайта (для больших сайтов)

Для сайтов с сотнями тысяч страниц объявление hreflang в <head> теги становятся громоздкими. Hreflang на основе Sitemap более эффективен и позволяет экономить HTML:

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

Применяются те же правила взаимности. Каждая запись URL в карте сайта должна содержать список всех языковых версий, включая ее саму.

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

Пять распространенных ошибок внедрения

Image listing common hreflang mistakes

1. Отсутствует самореферентный хрефланг

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

2. Невзаимные возвратные теги

Английская страница указывает на французскую страницу. Французская страница не указывает назад. Google считает это нарушенным и может разорвать отношения. Исправление: каждая ссылка должна быть взаимной. На французской странице в качестве английской альтернативы должна быть указана английская страница.

3. Указание hreflang на перенаправленные URL-адреса

На вашей странице на английском языке указана французская версия по адресу https://example.com/fr/ но этот URL 301-перенаправляет на https://example.com/fr/home/. Google следует перенаправлению, но сигнал hreflang ослабевает — а в некоторых случаях полностью игнорируется.

Исправление: hreflang должен указывать на конечный канонический URL-адрес, а не на цепочку перенаправлений. Аудит с помощью сканера, который помечает цели, отличные от 200 hreflang.

4. хрефланг и канонические конфликты

На вашей французской странице есть канонический тег, указывающий на английскую страницу (потому что кто-то скопировал и вставил канонический тег). Google читает это как “французская страница - это всего лишь дубликат английской страницы”, и отношения hreflang игнорируются. Исправление: каждая переведенная страница должна самоканонизироваться. Канонический стиль французской страницы указывает на нее саму, а не на английский оригинал.

5. Непоследовательное смешивание языковых и региональных кодов

Некоторые страницы заявляют hreflang="en", другие заявляют hreflang="en-US". Google рассматривает их как отдельные языковые кластеры. Выберите одну стратегию для каждого языка и придерживайтесь ее на всем сайте.

Планирование производственных пограничных случаев

Крайний случай 1: Нацеливание только на регион (en-CA без en)

У вас есть англо-канадский вариант вашей страницы, но нет глобальной английской версии. Не используйте hreflang="en" в одиночку — Google может предоставить вашу канадскую страницу пользователям из Великобритании, что, вероятно, не то, что вам нужно. Вместо этого объявите hreflang="en-CA" конкретно и пусть x-default работать с англоговорящими людьми, не являющимися гражданами Канады.

Крайний случай 2: одинаковое содержимое, разные регионы

Версии одной и той же страницы продукта на английском языке в США, Великобритании и Австралии с идентичным текстом. Это нормально — явно объявите каждый регион:

<link rel="alternate" hreflang="en-US" href="https://example.com/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/" />
<link rel="alternate" hreflang="en-AU" href="https://example.com/au/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Даже если содержание идентично, региональные варианты hreflang ценны для продуктов с региональными ценами, валютой или доставкой.

Крайний случай 3: Мобильные и настольные варианты

Если у вас есть отдельные мобильные страницы поддомена m., каждой мобильной странице нужны свои собственные объявления hreflang, указывающие на другие варианты мобильного языка. Не направляйте мобильную французскую страницу на десктопную английскую страницу — Google считает это сломанным кластером.

Крайний случай 4: Поддомены против подкаталогов

Оба работают для hreflang. fr.example.com и example.com/fr/ одинаково действительны. Выбор операционный (DNS, хостинг, аналитика) — сам по себе не является фактором SEO. Важна последовательность: выберите одну структуру и примените ее ко всем языкам.

Крайний случай 5: нумерация страниц

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

Крайний случай 6: 404 и 410 страниц

Если переведенной версии страницы (пока) не существует, не объявляйте hreflang для этого языка. Указывать hreflang на 404 хуже, чем не объявлять его вообще — Google рассматривает это как разорванные отношения и может понизить рейтинг всего кластера.

Как проверить перед запуском в эксплуатацию

Используйте дополнительные проверки, поскольку ни один отчет не доказывает правильность каждой пары URL-адресов:

  • Консоль поиска Google. Отправьте языковые карты сайта, проверьте репрезентативные URL-адреса с помощью проверки URL-адресов и сравните данные индексации страниц и производительности по языковым каталогам. Прежний отчет International Targeting больше не доступен в текущем интерфейсе Search Console.
  • Кричащая лягушка. Сканирует весь ваш сайт и сообщает о невзаимном hreflang, отсутствующих тегах возврата, неработающих URL-адресах hreflang и несоответствиях. Лучший инструмент для контроля качества перед запуском.
  • Инструмент тестирования тегов hreflang от Merkle. Бесплатный, браузерный, подходит для выборочной проверки во время разработки.

Запустите проверку сканера и проверку репрезентативных URL-адресов перед крупным запуском, а затем отслеживайте Search Console после того, как Google повторно просканирует страницы.

Как автоматизированные инструменты обрабатывают hreflang

Если вы используете платформу перевода веб-сайтов, такую как ConveyThis, Weglot или подобную, генерация hreflang должна быть автоматической. Платформа сканирует ваш контент, обнаруживает новые страницы и вставляет правильные теги hreflang в каждую переведенную версию—, включая теги самоссылок, теги возврата и x-default.

Это самый веский аргумент в пользу использования платформы перевода вместо конвейера ручного перевода. Ручная поддержка hreflang на 200-страничном сайте на 12 языках означает отслеживание 31 200 связей тегов. Каждая новая страница добавляет 12 новых отношений, которые необходимо добавить в 12 местах. Ручное техническое обслуживание прерывается в больших масштабах.

Если вы используете платформу и все еще видите ошибки hreflang в Search Console, причиной обычно является одна из трех вещей: уровень кэширования CDN, который удаляет заголовки, плагин CMS, который перезаписывает теги, или правило перенаправления, которое мешает канонической структуре. Все три проблемы можно исправить, но они требуют координации между вашей платформой перевода, настройками хостинга и вашей CDN.

Итог

hreflang не сложен. Это многословно. Сложность обусловлена объемом деклараций и хрупкостью любого отдельного отсутствующего тега. Правильно определите основы — самоссылки, взаимность, каноническое выравнивание, наличие x-default —, а остальное — просто поддержка.

Правильный hreflang устраняет двусмысленность относительно того, какой эквивалентный URL-адрес предназначен для данного языка или региона. Сначала исправьте основы, затем отслеживайте показы, клики и выбранные канонические URL-адреса, пока Google повторно сканирует кластер.


Об авторе

Алекс Буран, Основатель ConveyThis

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

LinkedIn: https://www.linkedin.com/in/alexburan/


Устали отлаживать hreflang вручную? ConveyThis автоматически генерирует действительные, взаимные, самоссылающиеся теги hreflang на каждой переведенной странице — включая x-default и пограничные случаи. См. документацию API

Поделиться:
G2 High Performer Spring 2023
G2 Easiest Setup Fall 2024
G2 Best Support Spring 2025