Я много раз настраивал hreflang для сайтов с русской, английской, немецкой и даже арабской версией. И честно говоря, ошибка здесь обычно не в самом теге, а в логике структуры сайта: где живут URL, как устроены редиректы, есть ли зеркала, как CMS генерирует каноникалы и не ломает ли всё это кеш.
Что такое hreflang и зачем он нужен
Если говорить по-простому, hreflang — это подсказка для поисковиков о том, какая языковая или региональная версия страницы кому должна показываться. Например, у вас есть одна и та же страница на русском для России, на английском для США и на английском для Великобритании. Без hreflang Google и Яндекс могут путаться, какую версию отдать пользователю, особенно если контент почти одинаковый.
На моей практике hreflang особенно полезен в трёх случаях: когда сайт реально многоязычный, когда есть отдельные домены под страны, и когда контент частично дублируется. Это, грубо говоря, не “SEO-магия”, а способ убрать путаницу. Если у вас интернет-магазин на Битрикс или WordPress с разными регионами, hreflang однозначно стоит внедрять. И делать это нужно аккуратно, иначе пользы не будет вообще.
У меня был клиент на WordPress 6.5 с WooCommerce, у которого английская версия и русская версия существовали на одном домене в папках /en/ и /ru/. Сайт отлично индексировался, но в выдаче часто всплывала не та версия. После нормальной настройки hreflang и проверки каноникалов ситуация выровнялась. В Google Search Console стало меньше “альтернативных страниц с правильным каноническим тегом”, а клики по нужным языкам выросли примерно на 18% за 2 месяца.
Если вы только планируете многоязычный проект, я советую сначала прочитать Как настроить многоязычный сайт: полное руководство 2026. Там хорошо раскрыта архитектура: домены, поддомены, папки, маршрутизация и локализация. Без этой базы hreflang нередко ставят “на глазок”, а потом месяцами разгребают последствия.
Как работает hreflang в 2026 году
В 2026 году логика осталась прежней, но требования к аккуратности выросли. Поисковики стали лучше понимать контекст, но это не значит, что они всё сделают за вас. На деле hreflang должен быть взаимным: если русская страница указывает на английскую, то английская обязана указывать обратно на русскую. Иначе разметка считается неполной.
Есть три распространённых формата внедрения hreflang:
- в
<head>через<link rel="alternate" hreflang="...">; - в XML sitemap;
- через HTTP-заголовки — в основном для PDF и нестандартных файлов.
Я почти всегда использую вариант через <head> для страниц и дополнительно проверяю XML sitemap. Если сайт большой, например 20 000+ URL на Laravel или Bitrix, sitemap с hreflang часто удобнее, потому что не раздувает шаблон и проще автоматизируется. Но если у вас небольшой корпоративный сайт, head-реализация обычно понятнее и надёжнее.
Тут есть нюанс: hreflang не заменяет canonical. И вот это место многие путают. Если у страницы есть канонический URL, он должен быть логически согласован с языковой версией. Например, у русской версии canonical должен вести на себя, а не на английскую страницу. Иначе вы сами запутаете поисковик. Это плохая идея.
Если вы уже читали мою статью Как настроить 301 редиректы при смене URL и структуры сайта в 2026, то логика похожая: сначала выстраиваем архитектуру, потом маршрутизацию, и только после этого накручиваем SEO-слой. Иначе получите хаос в индексировании.
Какую структуру сайта выбрать перед настройкой
Прежде чем писать теги, нужно понять структуру. Hreflang нормально работает в трёх базовых схемах:
- разные домены:
site.com,site.de,site.fr; - поддомены:
en.site.com,de.site.com; - папки:
site.com/en/,site.com/de/.
На моей практике для WordPress чаще выбирают папки, если сайт один и регионов немного. Для Bitrix и Laravel можно сделать и папки, и поддомены — зависит от команды и того, как строится кеширование. Если у вас CDN, разные регионы, отдельные валюты и отдельные условия доставки, иногда удобнее выносить языки в поддомены или домены. Это проще обслуживать и легче масштабировать.
Но есть и обратная сторона. Чем больше разъезжается структура, тем выше риск ошибок в hreflang, редиректах и SSL. Если у сайта уже стоят HTTPS, HSTS, CDN и reverse proxy на Nginx, любые кривые перенаправления могут сломать цепочку альтернативных URL. Поэтому я обычно начинаю не с тега, а с аудита всех версий страниц. Для этого полезно свериться с материалом SEO-аудит сайта: что проверить в первую очередь.
Если у вас мультидоменный проект, обязательно посмотрите ещё Настройка мультидоменного сайта: полное руководство 2026. Там хорошо видно, как связаны домены, сертификаты, DNS и серверная конфигурация. На деле hreflang часто ломается не в HTML, а именно на уровне инфраструктуры.
Основные правила разметки hreflang
Тут есть несколько правил, которые нельзя игнорировать. Первое — каждая языковая версия должна ссылаться на все остальные версии этого набора. Второе — ссылки должны быть абсолютными. Третье — использовать нужно правильный код языка или языка+региона. И четвёртое — у каждой страницы должен быть self-reference, то есть ссылка на саму себя.
Например, если у вас есть страница:
https://example.com/ru/uslugi/https://example.com/en/services/https://example.com/de/leistungen/
То каждая из них должна содержать полный набор alternate-ссылок на все три версии, плюс иногда x-default.
Коды надо писать аккуратно. Не выдумывайте свои обозначения. Для языка — en, ru, de. Для языка и региона — en-us, en-gb, pt-br. Если вам нужна общая английская версия без привязки к стране, обычно достаточно en. Если это разные рынки с разными ценами и юридическими условиями, я советую использовать именно региональные коды. Так поисковик понимает, что страницы не просто переведены, а ещё и локализованы.
Есть ещё частая ошибка: ставят hreflang на страницы, которых нет в 200 OK. Например, страница ведёт на 301, потом на 404, потом ещё куда-то. Это мусор. Сначала делаем правильные URL, потом hreflang. И отдельно проверяем, не закрыты ли эти URL в robots.txt: полное руководство.
Пример разметки hreflang в HTML
Ниже показываю рабочий базовый вариант. Я обычно делаю его в шаблоне CMS или через SEO-модуль, если проект на Битрикс. На WordPress чаще подключаю через тему или SEO-плагин, но руками тоже можно. Для Laravel — через Blade-компонент или helper, чтобы не дублировать логику.
<link rel="alternate" hreflang="ru" href="https://example.com/ru/uslugi/">
<link rel="alternate" hreflang="en" href="https://example.com/en/services/">
<link rel="alternate" hreflang="de" href="https://example.com/de/leistungen/">
<link rel="alternate" hreflang="x-default" href="https://example.com/">
<link rel="canonical" href="https://example.com/ru/uslugi/">Но этого мало. На странице /en/services/ canonical должен быть на неё же, а hreflang должен содержать тот же полный набор. И так для каждой версии. Если canonical указывает на себя, а hreflang симметричен, обычно всё работает стабильно.
У одного клиента на Bitrix 24.0, PHP 8.2 и MySQL 8.0 была проблема именно в шаблоне. Hreflang выводился только на русской версии, а английская его не получала, потому что разработчик зашил условие в компонент “для локали RU”. В результате Google воспринимал английскую страницу как отдельную сущность и путал её с дублем. Мы вынесли генерацию в общий файл, сделали массив соответствий URL и за полдня закрыли вопрос. Иногда решение очень простое, но искать его приходится долго.
Если хотите навести порядок в разметке и не ломать другие SEO-элементы, полезно прочитать ещё Как настроить Schema.org на сайте: микроразметка 2026 и Настройка XML sitemap для SEO: полное руководство 2026. Hreflang лучше живёт там, где уже есть дисциплина в разметке.
Hreflang через XML sitemap
Если сайт большой, sitemap — это почти всегда более удобный путь. Особенно если у вас интернет-магазин с тысячами карточек на WordPress/WooCommerce или Bitrix. На деле генерировать десятки тысяч <link> в шаблоне не всегда разумно. Sitemap можно обновлять по крону, кешировать и проверять отдельно.
Пример фрагмента sitemap с hreflang:
<url>
<loc>https://example.com/ru/uslugi/</loc>
<xhtml:link rel="alternate" hreflang="ru" href="https://example.com/ru/uslugi/"/>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/services/"/>
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/leistungen/"/>
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/"/>
</url>Этот вариант особенно удобен, если у вас генерация контента идёт автоматически. Например, на Laravel можно собирать sitemap через консольную команду по cron. На Bitrix часто делают через агенты или отдельный скрипт по расписанию. Я видел и очень неаккуратные реализации, когда sitemap генерировался руками раз в месяц. Это уже почти гарантированный путь к мусору в индексе.
Если вы уже внедряли автоматизацию контента, загляните в статью Автоматическое обновление контента: настройка и инструменты. Там хорошо видно, почему автоматическая генерация должна быть проверяемой, а не просто “пусть скрипт что-то пишет”. Для sitemap это особенно критично.
Hreflang для Bitrix, WordPress и Laravel
На Bitrix я обычно делаю hreflang либо через шаблон сайта, либо через компонент SEO-данных, если проект уже оброс кастомизацией. Там важно не сломать кеш. Если у вас включён композитный режим и кеширование в Битрикс, нужно следить, чтобы языковая разметка не отдавалась всем пользователям одинаково “не туда”. Для этого иногда приходится настраивать отдельные правила кеша или пробрасывать язык через контекст.
Для WordPress всё проще, но и там хватает сюрпризов. Многие SEO-плагины умеют hreflang, но не всегда корректно. Я встречал ситуации, когда плагин создавал дублирующий x-default на каждую страницу, а потом ещё дублировал canonical. Если у вас Yoast SEO или Rank Math, проверяйте исходный HTML, а не верьте галочкам в админке. На PHP 8.3 и актуальных версиях WordPress это обычно работает нормально, но только если тема не переопределяет хук вывода head.
В Laravel я чаще делаю универсальный помощник, который строит набор альтернативных ссылок из массива. Это удобно, потому что логика живёт в одном месте. Например:
<?php
function hreflangLinks(array $variants): string
{
$html = '';
foreach ($variants as $locale => $url) {
$html .= '<link rel="alternate" hreflang="' . htmlspecialchars($locale, ENT_QUOTES, 'UTF-8') . '" href="' . htmlspecialchars($url, ENT_QUOTES, 'UTF-8') . '">' . PHP_EOL;
}
return $html;
}
echo hreflangLinks([
'ru' => 'https://example.com/ru/uslugi/',
'en' => 'https://example.com/en/services/',
'de' => 'https://example.com/de/leistungen/',
'x-default' => 'https://example.com/',
]);Это не “красивый код ради красивого кода”. Это способ не плодить ручные ошибки. Если на сайте 3000 страниц и 4 языка, вручную такое поддерживать — плохая идея. Я бы даже сказал, забудьте про это сразу.
Если вам нужно сначала выбрать платформу, посмотрите Битрикс или WordPress: подробное сравнение и Laravel для бизнес-проекта: когда и зачем. Вопрос hreflang часто упирается не в SEO, а в то, насколько гибко CMS позволяет управлять шаблоном и маршрутами.
Ошибки при настройке hreflang
Самые частые ошибки я вижу каждый месяц. Первая — неполный набор ссылок. Вторая — языковые версии не ссылаются друг на друга. Третья — неверные коды регионов. Четвёртая — страницы ведут на редиректы. Пятая — URL закрыты в robots.txt или отдают noindex. И всё это происходит одновременно, что особенно весело для SEO-специалиста и совсем не весело для бизнеса.
Есть ещё одна неприятная история: смешивание языков в одном URL. Например, /ru/services/ и /en/uslugi/. Грубо говоря, если у вас URL не соответствуют языку, это нормально только при очень чёткой логике сайта. Но для поисковика это лишняя нагрузка и лишний риск ошибки. Я обычно советую делать URL максимально предсказуемыми.
На проекте одного интернет-магазина на WordPress мы нашли 400+ страниц с hreflang, который указывал на 404. Причина была банальная: контент-менеджер удалил старые языковые страницы, а генератор alternate-ссылок продолжал их печатать из кэша. Решили через пересборку кэша, обновление карты соответствий и добавление проверки HTTP-статусов. После этого число ошибок в Search Console заметно упало. И да, мониторинг тут очень помогает — если настроить его нормально. Я про это отдельно писал в Как настроить мониторинг сайта: полное руководство.
Ещё одна проблема — забывают про страницу “по умолчанию”. Если у вас международный сайт, часто нужен x-default. Это не обязательное правило для каждого проекта, но на практике оно помогает, когда пользователь из непредусмотренной страны попадает на сайт. Обычно это главная страница выбора языка или нейтральная посадочная.
Как проверить правильность hreflang
Проверять нужно не “на глаз”, а инструментами. Я обычно делаю три шага. Первый — смотрю исходный HTML и проверяю симметрию ссылок. Второй — прогоняю набор URL через Screaming Frog или аналогичный краулер. Третий — смотрю отчёты Google Search Console и логи сервера. Если сайт на Nginx, полезно ещё посмотреть, не режет ли что-то прокси или кеш.
На больших проектах я люблю запускать простую выборочную проверку через PHP-скрипт. Например, можно пройтись по массиву URL и убедиться, что все альтернативы отвечают 200:
<?php
$urls = [
'https://example.com/ru/uslugi/',
'https://example.com/en/services/',
'https://example.com/de/leistungen/',
];
foreach ($urls as $url) {
$headers = @get_headers($url);
$status = $headers[0] ?? '';
echo $url . ' => ' . $status . PHP_EOL;
}Если нужно проверить не только код ответа, но и наличие строк hreflang в HTML, я обычно смотрю это через curl или отдельный парсер. В проде такой контроль сильно экономит время. Особенно если проект обновляется автоматически, а контент уходит в публикацию через очереди задач и cron. Кстати, если у вас в проекте уже есть cron jobs, вот полезная статья: Настройка cron jobs: автоматические задачи на сайте в 2026.
Если в индексе уже есть мусорные URL, сначала приводим в порядок редиректы, потом sitemap, потом hreflang. И только потом смотрим на результаты. В противном случае вы будете лечить симптомы, а не причину. Для таких задач часто помогает ещё и Редиректы 301 без потери SEO-позиций.
Практический чек-лист на 2026 год
Ниже мой рабочий порядок. Я использую его почти на каждом проекте, где есть несколько языков или регионов. Сначала собираю список всех страниц и их соответствий. Потом проверяю структуру URL. Затем убеждаюсь, что на всех версиях стоят self-referencing canonical и корректные alternate-ссылки. После этого прогоняю краулер и только потом отдаю сайт в индекс.
- Собрать матрицу URL по всем языкам и регионам.
- Проверить, что каждая версия отдаёт 200 OK.
- Убедиться, что canonical не указывает на другой язык.
- Добавить взаимные hreflang-ссылки.
- Добавить
x-default, если он нужен. - Проверить XML sitemap и/или шаблон
<head>. - Протестировать на staging с теми же правилами кеша, что и на production.
- Проверить отчёты Search Console и логи через 1–2 недели.
И вот тут я скажу категорично: если у вас сайт на PHP 8.1–8.3 и MySQL 5.7 или 8.0, это вообще не повод откладывать hreflang “на потом”. Наоборот, чем современнее стек, тем проще автоматизировать генерацию и проверку. Технически это несложная задача. Сложность почти всегда в дисциплине и аккуратности.
Если вам нужно не только настроить hreflang, но и в целом навести порядок в структуре, редиректах, скорости и индексации, я обычно советую идти комплексно. Посмотрите услуги поддержка WordPress, поддержка Битрикс и доработка сайта. На многоязычных проектах это часто экономит больше денег, чем точечные правки по одному тегу.
Если говорить совсем по-деловому, hreflang в 2026 году — это не “дополнительный SEO-модуль”, а часть технической архитектуры сайта. Он должен жить рядом с canonical, sitemap, robots.txt, редиректами, CDN и кешированием. И тогда всё работает нормально. А если внедрить его поверх хаоса, результат будет соответствующий: хаос, но уже с метками языка.
Нужна помощь с hreflang для вашего сайта?
Мы поможем корректно настроить hreflang для всех языков и регионов, чтобы поисковики показывали нужную версию страницы.