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

Сайт переведён на пять языков, тексты вычитаны носителями, домены куплены — а поиск упорно показывает немцу английскую версию, казахстанцу российскую, и половина языковых копий вообще выпала из индекса как дубли. Причина почти всегда одна: hreflang либо не настроен, либо настроен так, что поисковик его игнорирует. Этот атрибут не поднимает позиции сам по себе — он решает другую задачу: указывает, какую из нескольких почти одинаковых страниц показать конкретному пользователю. Разбираем механику полностью — синтаксис, x-default, связку с canonical и sitemap, разницу подходов Яндекса и Google, и то, как это встраивается в SEO-продвижение международного проекта.

Что такое hreflang и какую задачу он реально решает

hreflang — это атрибут, которым вы сообщаете поисковой системе: «вот эта страница и вот та — один и тот же материал, только на разных языках или для разных стран». Формально это связка вида rel="alternate" hreflang="de-AT", где указываются язык контента и, опционально, целевой регион.

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

Отсюда следует практический вывод, который экономит бюджеты. Если немецкая версия сайта не ранжируется вообще — hreflang её не спасёт. Проблема в другом: в контенте, в ссылочном профиле, в технической базе. Атрибут решает только одну проблему — неправильный выбор версии. Симптом выглядит так: вы видите в аналитике, что пользователи из Австрии приходят на страницу для Германии, отказы по этому сегменту заметно выше среднего по сайту, а конверсия близка к нулю. Или что в выдаче по немецкому запросу показывается английский URL с английским title.

Вторая функция hreflang — защита от каннибализации и от склейки как дублей. Испанская версия для Испании и для Мексики отличаются процентов на пять: валюта, пара идиом, телефон. Для поисковика это почти идентичные страницы. Без hreflang он выберет одну и отправит вторую в «Малополезный контент» или в Excluded. С корректной разметкой обе живут в индексе как легитимные региональные варианты одного материала. Эта логика близка к тому, как работает canonical при борьбе с дублями, но решает задачу с другой стороны: canonical схлопывает, hreflang — разводит.

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

Синтаксис: коды языка и региона без ошибок

Значение атрибута состоит из одной или двух частей. Первая — код языка по стандарту ISO 639-1 (двухбуквенный, обязателен). Вторая — код региона по стандарту ISO 3166-1 Alpha 2 (двухбуквенный, опционален), отделяется дефисом.

Ключевое правило, на котором горит большинство проектов: регион нельзя указывать без языка. Значение hreflang="ru" — валидно, оно означает «русский язык, любая страна». Значение hreflang="ru-KZ" — валидно, «русский язык для Казахстана». А вот hreflang="KZ" — ошибка, такая строка будет интерпретирована как несуществующий язык «kz» и связка отбросится.

Вторая мина — коды, которые кажутся очевидными, но не существуют. В ISO 639-1 нет кода «uk» для Украины (uk — это украинский язык, страна — UA), нет кода «cn» для китайского (китайский язык — zh, страна — CN), нет «gb» как языка (Великобритания — регион GB, язык — en). Классическая опечатка агентств — hreflang="en-UK": код Великобритании по ISO 3166-1 — GB, а не UK. Такая связка молча не работает.

Отдельная тонкость — китайский, где помимо страны различают письменность. Здесь используются коды письма по ISO 15924: zh-Hans (упрощённое письмо) и zh-Hant (традиционное), при необходимости с регионом — zh-Hant-TW. Это одно из немногих исключений, где допускается трёхчастная конструкция.

Три способа внедрения и как выбрать свой

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

1. HTML-теги в секции <head>

Самый распространённый вариант. На каждой странице кластера в <head> размещается набор ссылок на все версии, включая саму себя:

• <link rel="alternate" hreflang="ru" href="https://site.com/ru/tovar/">
• <link rel="alternate" hreflang="en" href="https://site.com/en/product/">
• <link rel="alternate" hreflang="de" href="https://site.com/de/produkt/">
• <link rel="alternate" hreflang="x-default" href="https://site.com/">

Плюс — прозрачно и легко проверяется через Ctrl+U. Минус — квадратичный рост. При 10 языках каждая страница несёт 11 тегов, а кластер из 10 страниц требует 110 корректных связок. На каталоге в 50 000 товаров это 500 000 тегов, которые раздувают HTML и съедают краулинговый бюджет. Теги должны стоять именно в <head> — вставленные в <body> они игнорируются, а такое случается, когда разметку добавляют скриптом после загрузки.

2. HTTP-заголовок Link

Единственный способ разметить нетекстовые файлы — PDF, документы, изображения. У них нет <head>, поэтому связки передаются в ответе сервера заголовком Link: <https://site.com/en/doc.pdf>; rel="alternate"; hreflang="en". Для обычных HTML-страниц этот метод избыточен и неудобен в отладке.

3. Блок в sitemap.xml

Оптимальный вариант для крупных проектов. Вся разметка выносится из HTML в карту сайта: в каждом <url> перечисляются все альтернативы через пространство имён xhtml. HTML остаётся чистым, а изменения языковой матрицы делаются в одном месте — не нужно перегенерировать все шаблоны. Требования к самой карте при этом обычные: только канонические адреса, актуальные lastmod, не более 50 000 URL и 50 МБ в распакованном виде на файл. Подробности — в материале про sitemap.xml и настройку карты сайта.

Взаимность: правило, которое ломает всё

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

Практически это значит следующее. Если русская страница ссылается на английскую с hreflang="en", то английская обязана ссылаться на русскую с hreflang="ru". Односторонняя связка не просто игнорируется — Google помечает её как «no return tags» и выбрасывает. Хуже того, при серьёзном рассогласовании система может отбросить весь кластер целиком, а не одну проблемную связку.

Второе обязательное условие — самоссылка. Каждая страница должна включать hreflang на саму себя. Русская версия содержит связку hreflang="ru" с собственным URL. Это не избыточность: так поисковик понимает, в какой узел кластера он попал, и от чего отсчитывать остальные.

Третье — абсолютные URL с протоколом. Только https://site.com/en/, никаких /en/ или //site.com/en/. Относительный адрес — гарантированно нерабочая связка.

Четвёртое — URL должен отдавать код 200. Ссылка на страницу, которая ведёт на 301 редирект, на 404 или закрыта в noindex, обесценивает связку. Это типичный отложенный дефект: сайт переехал с http на https или сменил структуру, редиректы поставили, а hreflang остался со старыми адресами — и вся матрица тихо умерла. Поэтому при любой миграции сайта языковая разметка проверяется в первую очередь.

x-default: кому его показывать

Значение x-default — это не язык, а инструкция: «показывай эту версию всем, кто не подошёл ни под одну из перечисленных комбинаций». Пользователь из Бразилии с португальским интерфейсом заходит на сайт, где есть только en-US, de-DE и fr-FR. Ни одна комбинация не совпала — и вместо случайного выбора поисковик подставит страницу, помеченную x-default.

Куда его ставить — зависит от архитектуры:

• Страница выбора языка — если у вас есть отдельный «портал», где посетитель выбирает страну. Классика крупных международных брендов.
• Основная международная версия — обычно английская без привязки к региону. Самый частый и практичный вариант.
• Главная страница — если она сама по себе служит хабом и определяет язык по контексту.

Что делать нельзя: назначать x-default странице с автоматическим редиректом по IP. Робот Google сканирует преимущественно с американских адресов; попав на такую страницу, он получит перенаправление на en-US и решит, что x-default — это en-US. Кластер поедет. Языковой выбор должен предлагаться баннером или селектором, но не принудительным переадресованием.

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

hreflang и canonical: как не убить кластер

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

Правило одно: каждая языковая версия каноникализируется сама на себя. Немецкая страница содержит <link rel="canonical" href="https://site.com/de/produkt/"> — то есть указывает на собственный адрес. И только после этого перечисляет hreflang-альтернативы.

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

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

Мультирегиональность: язык, регион и структура URL

Прежде чем размечать, нужно определиться с архитектурой. Разделяйте два разных понятия: мультиязычность (один и тот же материал на разных языках) и мультирегиональность (разные страны с разными ценами, доставкой, юрлицами — иногда на одном языке).

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

Практический ориентир: если проект нацелен на СНГ и Европу и бюджет ограничен — берите подпапки. Если бизнес в каждой стране самостоятельный, с локальным юрлицом, поддержкой и рекламным бюджетом — оправданы ccTLD. Отдельная задача — регионы внутри одной страны, там hreflang не нужен вовсе, работают другие механизмы; об этом подробно в статье про региональное SEO.

Пошаговое внедрение hreflang

Яндекс и Google: разные механики, разные действия

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

Региональность в Яндексе задаётся другими средствами. Первое — привязка региона в Яндекс.Вебмастере (раздел «Информация о сайте» → «Региональность»): для поддомена или отдельного домена регион назначается явно. Второе — Яндекс Бизнес: подтверждённая карточка с адресом даёт сильный геосигнал. Третье — содержание страницы: местные адреса, телефоны с кодом города, упоминание населённых пунктов. Четвёртое — доменная зона: .kz, .by, .ru воспринимаются как явное указание на страну.

Для языковых версий Яндекс ориентируется на язык контента напрямую и на атрибут lang у тега <html>. Кстати, этот атрибут стоит проставлять корректно в любом случае — он не заменяет hreflang для Google, но помогает браузерам, скринридерам и Яндексу.

Google, наоборот, опирается на hreflang как на основной механизм. Дополнительно он учитывает ccTLD и — исторически — геотаргетинг в Search Console, хотя для проектов на подпапках именно hreflang остаётся главным сигналом. Различия в подходах двух систем разобраны шире в статье про SEO под Google.

Практический вывод: для проекта, который работает и в рунете, и за рубежом, нужны две параллельные настройки. Для Google — корректная матрица hreflang. Для Яндекса — регионы в Вебмастере, карточки в Яндекс Бизнесе и локализованный контент с реальными адресами. Одно другому не мешает, но одно другое и не заменяет.

Типичные ошибки и их последствия

Ниже — дефекты, которые мы находим на SEO-аудитах международных проектов чаще всего. Порядок примерно соответствует частоте.

• Нет обратных связок (no return tags). Разметку поставили только на основной версии. Итог — кластер не собирается, атрибут не работает вообще.
• Нет самоссылки. Страница перечисляет альтернативы, но не указывает саму себя. Google отбрасывает такую разметку.
• Cross-language canonical. Все версии каноникализированы на английскую. Итог — языковые версии выпадают из индекса.
• Относительные URL. /de/ вместо https://site.com/de/. Связка не засчитывается.
• Ссылки на редиректы. В разметке http-версия или адрес без слеша, который редиректится. Формально ответ 301 — связка обесценивается.
• Несуществующие коды. en-UK, es-LATAM, zh-CHS, ru-RUS. Молчаливое игнорирование.
• Конфликт нескольких URL на один код. Две разные страницы объявлены как de-DE. Google не может выбрать и отбрасывает обе.
• Разметка в <body> или через JavaScript. Теги, вставленные скриптом после загрузки, робот часто не видит — та же проблема, что описана в материале про JavaScript-SEO.
• Автоматический редирект по IP. Робот сканирует из США, попадает на английскую версию всегда и не может увидеть остальные. Часть сайта просто не индексируется.
• Смешение способов. Часть связок в <head>, часть в sitemap, данные расходятся. Поисковик получает противоречивые сигналы.
• Разметка страниц, закрытых в robots.txt. Робот не может прочитать целевую страницу и подтвердить обратную связку.

Как проверять разметку

Проверка hreflang — это не «посмотреть, что теги стоят». Стоять они могут идеально, а работать не будут. Проверяется именно замкнутость кластера.

Ручная проверка одной страницы

Ctrl+U на любой языковой версии, поиск по слову «alternate». Убедитесь, что: теги в <head>, URL абсолютные, есть самоссылка, есть x-default, коды корректные. Затем откройте любую из перечисленных страниц и повторите — вы должны увидеть зеркальный набор с обратной ссылкой. Если нет — кластер разомкнут.

Массовая проверка краулером

Screaming Frog, Netpeak Spider или аналог. Запускаете обход всего сайта, включаете сбор hreflang и смотрите отчёт: «Missing Return Links», «Inconsistent Language & Region», «Non-200 Hreflang URLs», «Missing Self Reference». Это основной рабочий инструмент — на 20 000 страниц вручную не проверить ничего. Если разметка лежит в sitemap, скармливаете краулеру карту в режиме списка.

Панели вебмастеров и выдача

В Google Search Console отчёт по международному таргетингу упразднили, но «Проверка URL» показывает, какой канонический адрес выбрал Google и попала ли страница в индекс — этого достаточно для диагностики. Дополнительно контролируйте индексацию каждой версии отдельно: если de-версия не в индексе, hreflang на неё бессмысленен.

Финальная проверка — фактическая. Смотрите в аналитике распределение трафика по странам и языкам: если пользователи из Германии массово приземляются на английские URL, разметка не работает независимо от того, что показывают валидаторы. Пока разметка перестраивается и Google переиндексирует кластер (это недели), просадку по целевым странам разумно закрывать контекстной рекламой.

Сколько ждать результата

hreflang — не переключатель. После внедрения Google должен переобойти все страницы кластера, увидеть разметку с обеих сторон, подтвердить взаимность и пересобрать связи. На небольшом сайте это занимает 2–4 недели, на крупном каталоге — до нескольких месяцев, потому что переобход упирается в краулинговый бюджет. Ускорить можно: обновить lastmod в sitemap, отправить ключевые URL на переобход вручную, усилить внутреннюю перелинковку между языковыми версиями через видимый языковой селектор с обычными ссылками <a href>.

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

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