Hreflang — HTML-атрибут, который сообщает поисковым системам, для какого языка и региона предназначена конкретная страница сайта.
По данным исследования Ahrefs по 374 756 доменам, 67% сайтов с hreflang имеют хотя бы одну критическую ошибку в реализации.
Разбираем синтаксис, три метода внедрения, актуальные правила Яндекса и девять типов ошибок — с готовыми примерами кода.
Hreflang — что Google на самом деле с ним делает
Hreflang — HTML-атрибут, который сообщает Google, для какого языка и региона предназначена страница, но не гарантирует, что именно эта версия появится в выдаче для конкретного пользователя.
Если реализация безупречна, то Google с высокой вероятностью последует аннотации. Если есть противоречия, например, rel=canonical указывает на другой URL — поисковик может проигнорировать hreflang целиком и выбрать версию по своему усмотрению.
Зачем тогда возиться с настройкой? Без hreflang алгоритм угадывает.
Американец видит немецкую версию магазина, робот видит дубли вместо локализованных страниц, трафик из целевых регионов не приходит вообще.
Hreflang не поднимает позиции — он обеспечивает попадание нужной языковой версии к нужному пользователю.
Как Google выбирает, какую версию показать пользователю
Google обрабатывает hreflang-кластер по принципу best-match: сначала ищет совпадение по языку и региону (en-GB), затем только по языку (en), затем — x-default.
Допустим, у вас есть три версии страницы:
en-US,en-GBиde. Пользователь из Австралии с английским браузером отправляет запрос. Google ищетen-AU— не находит. Ищетen— находит и подставляет. Если быenтоже не было, пользователь попал бы наx-default.
Gary Illyes из Google описал более тонкий механизм: страницы в hreflang-кластере могут разделять сигналы ранжирования.
Если английская версия страницы — самая сильная по ссылочному весу, именно она определяет позицию в результатах поиска. Но в выдаче для японского пользователя подставится японская версия — этот процесс называется swap. Hreflang влияет не на то, какая страница стоит на первом месте, а на то, какая версия показывается конкретному пользователю на этом месте.
Почему консолидация доменов Google на google.com не меняет правила
С 2025 года Google перевел все страновые домены (google.fr, google.ca, google.co.jp) на редиректы на google.com.
Джон Мюллер прямо заявил: «nothing has changed with regards to international SEO» — изменения касаются только собственной инфраструктуры Google.
Алгоритм определения локали пользователя и обработка hreflang-аннотаций остаются прежними. Трафик из поиска будет приходить с google.com вместо google.de или google.fr.
Gary Illyes в июле 2025 года обозначил стратегический вектор: «Ultimately, I would want less and less annotations, site annotations, and more automatically learned things» — намёк на то, что Google планирует снижать зависимость от ручных hreflang-тегов в пользу автоматического определения языка.
Синтаксис hreflang: из чего состоит тег и как его собрать
Тег hreflang размещается в секции <head> страницы и содержит три обязательных компонента: rel="alternate", href с абсолютным URL и hreflang с кодом языка по ISO 639-1.
<link rel="alternate" hreflang="ru" href="https://example.com/ru/" />
rel="alternate"сообщает: этот URL — альтернативная версия текущей страницы.hreflang="ru"уточняет: альтернативная, потому что на русском языке.href="https://example.com/ru/"— абсолютный адрес этой версии.
Относительные URL (/ru/ без домена) недопустимы — Google требует полный адрес с протоколом.
Google уточнил в документации: нельзя комбинировать hreflang с другими атрибутами (например, media) в одном теге <link>. Каждая аннотация — отдельный тег.
Неправильно:
<link rel="alternate" hreflang="de-CH" media="handheld" href="https://m.example.com/ch/de/" />
Правильно:
<link rel="alternate" hreflang="de-CH" href="https://example.com/ch/de/" />
<link rel="alternate" media="handheld" href="https://example.com/ch/de/" />
Коды языков и регионов: где брать и как не ошибиться
Язык кодируется по ISO 639-1 (двухбуквенный: ru, en, de, fr), регион — по ISO 3166-1 Alpha-2 (двухбуквенный: RU, US, GB, DE); указывать только код страны без языка — ошибка, которую Google просто игнорирует.
Типичные ошибки:
en-UKвместоen-GB. Великобритания — этоGB, неUK. Google в этом конкретном случае исправляет ошибку сам, потому чтоUKзарезервированный код. Но полагаться на это не стоит — другие неверные коды не исправляются.- Только код региона без языка.
hreflang="RU"— невалидно. Google не умеет вычислить язык из кода страны. Правильно:hreflang="ru-RU"или простоhreflang="ru". - Китайский язык. Для китайского используют коды письменности из ISO 15924:
zh-Hans(упрощённый, материковый Китай) иzh-Hant(традиционный, Тайвань, Гонконг). Простоzhработает, ноzh-CNиzh-TWпредпочтительнее при региональном таргетинге.
x-default: для кого эта страница и когда её не нужно ставить
x-default — резервный URL для пользователей, чей язык не совпадает ни с одной из указанных локалей. Пьер Фарр из Google представил этот атрибут в 2013 году для двух сценариев: страница выбора страны и главные страницы с автоопределением геолокации.
<link rel="alternate" hreflang="x-default" href="https://example.com/" />
На практике x-default ставят на любую страницу, которая должна показываться при отсутствии языкового совпадения. Это не обязательное требование Google — но исследование Search Engine Land показало: 47,95% мультиязычных сайтов не используют x-default, и это создаёт непредсказуемое поведение для пользователей из регионов, не охваченных кластером.
Если у вас есть страница с языковым кодом
en, она уже служит «общим» английским фолбэком. Добавлятьx-default, указывающий на тот же URL — формально избыточно, но не вредно.
Три метода реализации: HTML, HTTP Headers, XML Sitemap — и когда каждый сломается
Google считает все три метода равнозначными, но: HTML-теги не видны Googlebot при CSR-рендеринге, Sitemap устарел для Яндекса, HTTP Headers теряются в CDN-прослойках.
| Метод | Когда подходит | Критические ограничения |
|---|---|---|
HTML <head> | Небольшие и средние сайты; SSR/SSG-фреймворки | Невидим Googlebot при чистом CSR (React SPA без SSR); нагружает <head> на крупных сайтах с десятками локалей |
| XML Sitemap | Крупные сайты; централизованное управление | Не поддерживается Яндексом с 2024 года; требует полного покрытия всех URL |
| HTTP Headers | Не-HTML файлы (PDF, DOCX, feeds) | Теряется в CDN и кэширующих прослойках; сложно отлаживать; требует доступа к конфигурации сервера |
HTML <head> — самый лучший метод. Теги видны в исходном коде страницы, легко проверить вручную. Подходит для сайтов, где шаблоны рендерятся на сервере.
<head>
<link rel="alternate" hreflang="ru" href="https://example.com/ru/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />
</head>
XML Sitemap — оптимален для крупных сайтов с сотнями и тысячами страниц. Всё управление из одного файла, <head> страниц не разбухает. Для Google работает полноценно.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://example.com/ru/</loc>
<xhtml:link rel="alternate" hreflang="ru" href="https://example.com/ru/"/>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/"/>
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/"/>
</url>
</urlset>
HTTP Headers — единственный вариант для не-HTML файлов: PDF-каталогов, документов, фидов.
Link: <https://example.com/file.pdf>; rel="alternate"; hreflang="en",
<https://example.com/de/file.pdf>; rel="alternate"; hreflang="de"
Hreflang в Next.js, React и других JS-фреймворках: почему CSR убивает международное SEO
Если hreflang-теги генерирует клиентский JavaScript — через react-helmet или аналогичные библиотеки в чистых SPA — Googlebot видит пустой <head> при первом краулинге, а теги обрабатываются только в отложенном втором визите, задержка которого может составлять от нескольких дней до нескольких недель.
Проблема выглядит так: Googlebot приходит на страницу, получает <div id="root"></div>, никаких hreflang-аннотаций нет. Google отмечает страницу для рендеринга. Через некоторое время — второй краулинг с выполнением JS. Только тогда теги становятся видны. В промежутке Google строит предположения о языке и регионе страницы самостоятельно.
Решение — SSR или SSG. Next.js App Router (актуален в 2026) позволяет генерировать hreflang server-side через generateMetadata:
export const metadata = {
metadataBase: new URL('https://acme.com'),
alternates: {
canonical: '/',
languages: {
'en-US': '/en-US',
'de-DE': '/de-DE',
},
},
openGraph: {
images: '/og-image.png',
},
}
HTML с тегами отдаётся клиенту уже готовым — Googlebot видит их с первого запроса.
По данным Stack Overflow Developer Survey 2025 (49 000+ разработчиков), React используют 44,7% разработчиков; большинство новых проектов уже работают через Next.js с SSR или SSG. Но legacy-проекты на Create React App (официально устарел) и SPA без серверного рендеринга по-прежнему имеют эту уязвимость.
Откройте Chrome DevTools → View Page Source (не Inspect, а именно исходный код). Если hreflang-тегов нет в статическом HTML — они генерируются на клиенте, и Googlebot их может не увидеть при первом краулинге.
Hreflang для Яндекса: Sitemap больше не работает
Яндекс прекратил поддержку hreflang в XML Sitemap — единственный рабочий метод для Яндекса в 2026 году — теги <link rel="alternate" hreflang="..."> непосредственно в <head> каждой страницы.
Официальная документация Яндекс Вебмастера прямо указывает: «Яндекс больше не поддерживает файл Sitemap для языковых версий. Рекомендуем использовать разметку локализованных страниц».
Для сайтов, которые продвигаются и в Google, и в Яндексе: реализуйте hreflang через
<head>HTML. Это работает в обоих поисковиках. XML Sitemap можно оставить как дополнение для Google — хуже не будет.
Три обязательных правила hreflang-кластера: двунаправленность, самоссылка и полнота
Hreflang работает как реляционная карта — Google проверяет, что страница A указывает на страницу B и страница B указывает обратно на A; без этой взаимности теги игнорируются. Если нарушение есть, Google не штрафует сайт — он просто не учитывает сигнал и выбирает версию для показа самостоятельно.
Правило 1. Двунаправленность. Каждая страница кластера должна содержать ссылки на все остальные версии, включая саму себя. Это не опция — без взаимных ссылок Google не может подтвердить, что вы контролируете обе страницы. Если русская версия указывает на английскую, английская обязана указывать на русскую.
Русская версия (/ru/):
<link rel="alternate" hreflang="ru" href="https://example.com/ru/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />
Английская версия (/en/) — тот же набор тегов:
<link rel="alternate" hreflang="ru" href="https://example.com/ru/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />
Немецкая версия (/de/) — тот же набор тегов.
Правило 2. Самоссылка. Каждая страница должна включать тег, который ссылается на саму себя. Джон Мюллер подтвердил, что самоссылка — хорошая практика, но формально не обязательная. Её наличие упрощает диагностику и снижает риск неправильной интерпретации кластера.
Правило 3. Полнота. Если при добавлении нового языка вы обновили только часть страниц — кластер сломан. Google обнаружит несоответствие при краулинге и может проигнорировать новые аннотации. Добавление нового рынка — это обновление всех страниц всех существующих языковых версий.
9 ошибок hreflang, из-за которых Google игнорирует ваш международный сайт
Согласно исследованию Ahrefs по 374 756 доменам, 67% сайтов с hreflang имеют хотя бы одну критическую ошибку — чаще всего это отсутствие обратных ссылок или неверный код языка.
1. Отсутствие обратной ссылки (no return-tag)
Самая распространённая и самая разрушительная ошибка — 31% сайтов с hreflang содержат конфликтующие или неполные кластеры, по данным исследования Search Engine Land (18 786 сайтов). Если страница A ссылается на страницу B, но B не ссылается на A — Google вправе проигнорировать всю пару.
Проверка: экспортируйте все hreflang-аннотации в Screaming Frog → вкладка Hreflang → фильтр «Missing Return Link».
2. Ссылка на URL с не-200 ответом
Hreflang-тег, указывающий на страницу с 404, 301 или 500 — сигнал обрывается для этой пары. Google расходует краулинговый бюджет на валидацию недоступной страницы и в итоге игнорирует аннотацию. URL в hreflang всегда должен возвращать 200.
Типичный сценарий: URL страницы изменился при редизайне, а hreflang не обновили. Итог — месяцами битые ссылки в кластере.
3. Ссылка на неканоническую страницу
Если rel="canonical" страницы указывает на один URL, а hreflang — на другой, Google получает противоречивые инструкции. Canonical говорит: «Индексируй вот эту страницу, эту игнорируй». Hreflang говорит: «Эту страницу тоже нужно показывать». Поисковик, как правило, доверяет canonical и игнорирует hreflang для конфликтующей пары.
Правило: hreflang должен указывать только на канонические URL. Для каждой языковой версии rel="canonical" должен указывать на саму эту страницу.
4. Несколько URL с одинаковым кодом языка
Если два разных URL в одном кластере имеют hreflang="en" — Google не знает, какой из них показывать. Оба сигнала конкурируют и могут быть проигнорированы. Каждый языковой код в кластере — уникальный, один URL.
5. Несколько кодов языка для одного URL
Если один URL помечен и hreflang="en" и hreflang="de" — страница не может быть одновременно на двух языках. Противоречие ведёт к игнорированию обоих тегов.
6. Неверный код языка или региона
8,91% сайтов содержат невалидные коды языков, ещё 1,6% — невалидные коды регионов. Хрестоматийный пример: en-EU вместо кодов отдельных стран — Евросоюз не является валидным кодом по ISO 3166-1 Alpha-2. Аналогично es-LA или es-419 для Латинской Америки — стандарт их не поддерживает, нужно таргетировать конкретные страны.
7. Отсутствие самоссылки
По исследованию Search Engine Land — 16,04% сайтов с hreflang не имеют самоссылающихся тегов. Джон Мюллер сказал, что это не блокирующее требование, но Screaming Frog и Ahrefs Site Audit отображают это как предупреждение, и при масштабном аудите удобнее, когда кластер полный.
8. Несовпадение hreflang и атрибута lang в HTML
Google не использует атрибут <html lang="en"> для определения языка — только контент и алгоритмы. Но Bing и браузеры его читают. Если hreflang="de" указывает на страницу с <html lang="en"> — для Bing и программ чтения с экрана возникает противоречие. Держите эти атрибуты согласованными.
9. Комбинирование hreflang и media в одном теге (добавлено в документацию Google, декабрь 2025)
Google уточнил: нельзя объединять hreflang-аннотацию с атрибутом media (или другими атрибутами для альтернативных представлений документа) в одном теге <link>. Разные задачи — разные теги. Эта ошибка появляется при попытке одновременно указать языковую и мобильную версию страницы в одной строке кода.
Как проверить hreflang на сайте: инструменты и приоритет исправлений
Аудит hreflang начинается с полного краулинга сайта — инструменты типа Screaming Frog экспортируют все hreflang-кластеры и выявляют пары без обратных ссылок, битые URL и неверные коды. Ручная проверка реальна только для сайтов до 50–100 страниц.
- Screaming Frog SEO Spider — краулер по умолчанию для hreflang-аудита. Вкладка Hreflang в отчёте показывает все аннотации, выявляет missing return links, non-200 responses и невалидные коды. Умеет сканировать URL из Sitemap и следовать hreflang-ссылкам на другие домены.
- Ahrefs Site Audit — облачный краулер с визуализацией hreflang-кластеров. Удобен для регулярного мониторинга: можно настроить расписание краулинга и получать оповещения о новых ошибках.
- Semrush Site Audit — аналог Ahrefs; выдаёт классифицированный список ошибок с пояснениями по каждой.
- Hreflang Tag Testing Tool — быстрая проверка одной конкретной страницы без краулинга всего сайта. Подходит для точечной диагностики.
Google Search Console — с 2022 года отчёт International Targeting удалён. Для диагностики hreflang используют URL Inspection (проверяет отдельную страницу) и Coverage Report (показывает страницы с ошибками индексации, которые могут быть связаны с конфликтом hreflang и canonical).
После того как аудит выявил ошибки, важно чинить их в правильном порядке:
- Первыми — битые URL (404, 301) в hreflang-тегах. Они разрывают весь кластер для пострадавших страниц. Пока URL не возвращает 200, остальные правки бессмысленны для этой пары.
- Вторыми — отсутствующие return-links. Без взаимности Google не учитывает сигнал вообще.
- Третьими — неверные коды языка и региона. Теги с невалидными кодами игнорируются, но не ломают остальные пары в кластере.
- Четвёртыми — конфликты с rel=canonical. Canonical vs. hreflang — canonical побеждает; нужно убедиться, что каждая страница канонизирует себя, а не другую версию.
- Пятыми — отсутствие x-default и самоссылок. Best practice, не критические, но снижают предсказуемость поведения.
Когда hreflang не нужен: три ситуации, где он создаёт лишний шум
Сайт на одном языке для одной страны в hreflang не нуждается — тег создаёт лишние связи для краулера и увеличивает нагрузку без SEO-отдачи. Нелогичные hreflang-комбинации к тому же создают дополнительный crawl demand: Google расходует краулинговый бюджет на валидацию пар, которые ничего не дают.
Один язык, один регион.
Если весь сайт на русском и ориентирован только на Россию — hreflang не нужен. Добавлять
hreflang="ru-RU"без альтернатив бессмысленно: тег без кластера не несёт информации.Несколько «английских» версий с минимальными отличиями.
Британская и американская версия сайта с разными ценами, но идентичным текстом — рискованный сценарий. Google может всё равно счесть их дублями и выбрать одну как каноническую, проигнорировав hreflang. Если единственное отличие — цены или валюта, часто проще сделать одну страницу с динамическим контентом по геолокации (с баннером для смены региона), чем поддерживать два синхронизированных кластера.
Ситуация 3. «Технический» перевод только шаблона.
Если основной контент не переведён, а локализованы только навигация, шапка и футер — hreflang нужен, но страницы всё равно будут считаться дублями по основному контенту. Google прямо указывает: локализованные версии считаются дублями, если основной контент страницы остался непереведённым.