Как настроить hreflang для мультиязычного сайта

Что такое hreflang и зачем он нужен мультиязычному сайту

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

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

Согласно различным SEO-отчетам, у более чем 75% мультиязычных проектов разметка hreflang содержит недочеты. У одних теги расставлены не на всех страницах, у других перепутаны региональные коды, у третьих нет двусторонних связей между локалями. Каждый такой промах подрывает международное продвижение: трафик уплывает или попадает в неподходящую локаль.

Тут стоит сделать оговорку: hreflang распознает Google, отчасти — Яндекс и Bing. Российским проектам, нацеленным на зарубежные рынки, настройка строго необходима, поскольку Google формирует львиную долю трафика из-за рубежа. В пределах рунета атрибут практически не работает — у Яндекса для разных локалей собственные алгоритмы обработки.

Когда нужно использовать языковую разметку hreflang

Языковая разметка нужна вовсе не каждому проекту. Если у вас единственный язык и одна целевая страна, hreflang ни к чему. Атрибут раскрывается только в нескольких типовых сценариях.

Страницы на разных языках

Самый частый случай — проект с переводом материалов на несколько языков. К примеру, корпоративный портал на русском, английском и немецком. У каждой страницы есть три варианта с одним смыслом, но разной языковой подачей.

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

Где это применяется на практике:

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

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

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

Тексты могут совпадать почти полностью, но различаться по следующим параметрам:

• цены в местной валюте;
• условия доставки и оплаты;
• юридические сведения;
• контакты региональных подразделений;
• сезонные акции;
• описания с учетом местных реалий.

Без hreflang поисковик не понимает, какой странице отдать предпочтение. С верной разметкой житель Австралии увидит страницу с австралийскими ценами, а посетитель из Канады — канадскую версию.

Та же схема работает для испанского (Испания, Мексика, Аргентина), португальского (Португалия и Бразилия), французского (Франция, Канада, Швейцария). Проекты из России, расширяющиеся на СНГ, могут разделять русский для России, Беларуси и Казахстана по странам.

Случаи, когда hreflang не решает проблему локализации

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

В каких случаях hreflang бесполезен:

• содержимое страниц радикально разное — перед нами не один и тот же материал, а разные продукты;
• автоматический перевод выполняется через скрипты без отдельных URL под каждый язык;
• задача сводится к замене валюты или единиц измерения без полноценной локализации;
• требуется скрыть страницы от отдельных регионов — это уже зона ответственности robots.txt и геотаргетинга;
• настроено IP-перенаправление посетителей на разные локали;
• у проекта одна языковая версия, ориентированная на разные регионы внутри одной страны.

В подобных ситуациях нужны другие инструменты: настройка таргетинга в Search Console, отдельные домены, региональные поддомены. Hreflang лишь усложнит конфигурацию без какого-либо результата.

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

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

Формат тега rel="alternate" hreflang

Стандартный hreflang-тег имеет такой вид:

Каждая строка указывает на одну из языковых версий. Разбор атрибутов:

• rel="alternate" — обозначает альтернативный вариант;
• hreflang — содержит код языка и опционально региона;
• href — абсолютный URL версии страницы.

Hreflang-теги ставятся в секции HTML-документа. На каждой странице обязательно должны быть теги, ведущие на все ее локализованные копии, в том числе на саму эту страницу (self-referencing).

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

Языковые и региональные коды

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

Языковые коды формируются по ISO 639-1 (двухбуквенные):

• ru — русский;
• en — английский;
• de — немецкий;
• fr — французский;
• es — испанский;
• zh — китайский;
• ja — японский.

Региональные коды — ISO 3166-1 alpha-2:

• RU — Россия;
• US — США;
• GB — Великобритания (не UK!);
• DE — Германия;
• FR — Франция;
• BR — Бразилия;
• KZ — Казахстан.

Полный формат с указанием региона выглядит как язык-РЕГИОН. Скажем, en-US, en-GB, es-MX, pt-BR, ru-KZ. Регион записывается заглавными буквами, язык — строчными. Поисковые системы в целом терпимы к разному регистру, но придерживаться стандарта стоит ради единообразия.

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

Self-referencing и reciprocal hreflang

Две принципиальные концепции, без знания которых разметка перестает работать корректно.

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

Корректный вариант:

Reciprocal hreflang — взаимные ссылки. Если страница А указывает на Б через hreflang, страница Б обязана обратным образом указывать на А. Иначе связь рассматривается как некорректная.

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

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

Где размещать hreflang: HTML, XML Sitemap или HTTP headers

Атрибут hreflang допустимо размещать в трех разных местах. Выбор зависит от типа проекта, объема страниц и технических возможностей команды.

Hreflang в HTML-коде страницы

Размещение в каждой страницы — самый распространенный подход. Подходит большинству сайтов с прозрачной структурой и небольшим или средним количеством URL.

Сильные стороны:

• наглядное и понятное решение;
• удобно проверять и отлаживать прямо в коде страницы;
• поддержка во всех популярных CMS через плагины и модули;
• работает на статичных сайтах без серверной обработки.

Слабые стороны:

• увеличивает объем HTML-документа;
• на сайтах с десятками локалей теги занимают значительный объем;
• при добавлении новой версии приходится править каждую страницу;
• сложно поддерживать на проектах с тысячами URL.

Для WordPress, Bitrix, Tilda и других популярных CMS существуют готовые модули, формирующие нужные теги автоматически. На крупных проектах часто применяют гибрид: базовая разметка через sitemap, плюс HTML для приоритетных страниц.

Hreflang в XML Sitemap

Для масштабных мультиязычных сайтов более удобный путь — описывать hreflang в XML Sitemap. Это позволяет работать с тысячами URL без раздувания HTML-кода.

Структура записи в sitemap:

Что дает такой подход:

• централизованное управление всеми локализациями из одного файла;
• удобство правок при подключении новых языков;
• HTML-код страниц остается незагруженным;
• хорошо подходит онлайн-магазинам с десятками тысяч карточек.

Sitemap передается в Search Console для регистрации. Google использует эти данные при построении карты языковых версий сайта.

Hreflang через HTTP headers для не-HTML файлов

Третий способ используется нечасто — через HTTP-заголовки. Подходит для файлов без HTML-кода: PDF-документов, картинок, видеороликов.

Формат заголовка ответа сервера:

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

Как hreflang работает с canonical и индексацией

Языковая разметка связана с другими SEO-атрибутами, и понимание этой связи принципиально для корректной работы всего механизма.

Canonical URL для языковых версий

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

Верный подход: на каждой языковой версии canonical обязан указывать на саму себя.

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

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

Индексируемость страниц с hreflang

Hreflang работает только на индексируемых страницах. Если URL закрыт от индексации через noindex или robots.txt, Google проигнорирует все его hreflang-теги.

Что обязательно проверить:

• все языковые версии доступны для индексации;
• в robots.txt не блокируются языковые разделы;
• мета-тег либо его отсутствие на всех версиях;
• HTTP-статус 200 для всех URL из hreflang-разметки;
• отсутствие редиректов на странице, прописанной в hreflang.

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

Конфликты canonical, noindex и языковой разметки

Типовые противоречия, которые ломают работу hreflang:

• Canonical на чужую языковую версию. Скажем, русская страница указывает canonical на английскую. Результат — русская выпадает из индекса.
• Noindex на одной из локалей. Если немецкая страница закрыта, hreflang-теги, ведущие на нее с других версий, теряют силу.
• Редиректы в hreflang URL. Если страница, на которую ведет hreflang, отправляет на редирект — разметка не сработает.
• Hreflang на параметризованные URL. Версия с UTM-метками не должна попадать в hreflang — только чистый адрес.
• Hreflang между HTTP и HTTPS. Все URL обязаны использовать один протокол, желательно HTTPS.

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

Частые ошибки hreflang и как их проверить

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

Отсутствующие обратные ссылки между версиями

Самая распространенная оплошность — нарушение принципа reciprocity. Страница А указывает в hreflang на страницу Б, а Б на А не ссылается. Google помечает такую разметку как невалидную.

Причины возникновения:

• добавили новую языковую версию и забыли скорректировать теги на остальных;
• опечатка в URL — ошибка в одном из тегов;
• неправильно указан язык — на одной странице en, на другой en-US;
• одна из страниц редиректит, а Google ждет прямой URL;
• разные протоколы — HTTP на одной странице, HTTPS на другой.

Проверка через Search Console: открываем отчет «Международный таргетинг» → вкладка «Язык». Там Google показывает все найденные на сайте ошибки hreflang с указанием конкретных URL.

Неверные языковые и региональные коды

Вторая частая беда — некорректные коды. Google игнорирует hreflang с невалидными значениями.

Характерные просчеты:

• использование uk вместо gb для Великобритании;
• путаница между en-uk и en-gb — корректен второй вариант;
• указание en-eu — такого региона не существует, EU — не страна;
• применение внутренних кодов локализации вместо ISO;
• путаница между трехбуквенными и двухбуквенными кодами;
• неправильный регистр атрибутов — EN-US вместо en-US.

Полный список валидных кодов ISO 639-1 (языки) и ISO 3166-1 alpha-2 (регионы) есть в Википедии и в документации Google. Перед запуском мультиязычной разметки имеет смысл свериться со справочником по всем кодам.

Инструменты для аудита hreflang

Ручная проверка hreflang на проекте с десятками страниц — занятие неблагодарное. Существуют специализированные инструменты для автоматизации.

Что использовать:

• Google Search Console — отчет «Международный таргетинг» выводит все найденные ошибки;
• Screaming Frog SEO Spider — массово проверяет все теги на сайте, находит проблемы с reciprocity, неправильные коды, отсутствие self-referencing;
• Ahrefs Site Audit — разбирает hreflang в рамках общего технического аудита сайта;
• Sitebulb — формирует визуальные карты языковых версий и подсвечивает разрывы;
• TechnicalSEO.com Hreflang Tags Generator — генератор для создания и проверки корректных тегов;
• hreflang.org — простой онлайн-проверщик для отдельных URL.

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

Как выбрать URL-структуру для мультиязычного сайта

Структура URL — один из первых архитектурных вопросов при старте мультиязычного проекта. От правильного выбора зависят удобство управления, SEO-показатели и техническая сложность обслуживания.

Подпапки, поддомены и ccTLD

Три ключевых подхода к организации языковых версий:

Подпапки на одном домене:
example.com/ru/
example.com/en/
example.com/de/
Преимущества: единый домен накапливает SEO-вес, управление проще, поддержка дешевле. Минусы: меньше географической релевантности в поиске.

Поддомены:
ru.example.com
en.example.com
de.example.com
Преимущества: можно распределить хостинг по регионам ради скорости, гибкость управления. Минусы: каждый поддомен Google рассматривает почти как отдельный сайт, SEO-вес дробится.

Country Code Top Level Domains (ccTLD):
example.ru
example.com
example.de
Преимущества: максимальный сигнал геолокации, доверие местной аудитории, лучший локальный SEO. Минусы: дорогая поддержка, отдельное SEO для каждого домена, сложности при переезде.

Большинству проектов подходят именно подпапки. Они дают баланс между удобством администрирования и SEO-эффективностью. ccTLD имеет смысл для крупных международных брендов с серьезными бюджетами на каждый регион.

Абсолютные URL и единая карта языковых версий

В hreflang-разметке всегда используются абсолютные URL, начинающиеся с протокола и домена. Относительные пути не работают.

Неправильно:

Правильно:

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

Локализация контента, мета-тегов и ключевых слов

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

• основной текст страницы;
• мета-теги title и description;
• alt-атрибуты картинок;
• структурированные данные Schema.org;
• адреса и контакты для региональных версий;
• валюту, единицы измерения, форматы дат;
• юридические тексты с учетом местного законодательства.

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

Семантическое ядро для каждой языковой версии собирается отдельно. То, что популярно в России, может вообще не искаться в Германии. Перенос русских ключей в английскую версию через прямой перевод — прямой путь к нулевому трафику.

Заключение

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

Главные принципы успешной работы: одинаковая структура hreflang на всех страницах, корректные коды языков и регионов, self-referencing на каждой версии, обязательные взаимные ссылки между всеми локалями, согласованность с canonical и индексацией. Регулярный аудит через Search Console и Screaming Frog помогает отлавливать проблемы на ранней стадии.

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

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

Константин Крючков

Senior SEO-специалист

Подписаться на ТГ