Короткий ответ
Hreflang — это разметка, которой вы сообщаете Google, что несколько страниц являются языковыми версиями друг друга. Она не повышает позиции: её задача — показать нужному пользователю нужную версию и не дать версиям конкурировать между собой в одной выдаче. Настройка сводится к трём правилам: ссылки взаимные, каждая страница ссылается сама на себя, все URL абсолютные и отвечают кодом 200.
Зачем hreflang нужен на самом деле
Формулировка «чтобы Google понимал языки» слишком расплывчата, чтобы по ней что-то настраивать. Практически hreflang решает две задачи.
Первая задача: выбор версии в выдаче. Пользователь ищет на эстонском, а в результатах ему показывается русская версия вашей страницы. Он не переключает язык, а возвращается в выдачу и уходит к конкуренту. Hreflang снижает вероятность такой подмены.
Вторая задача: объединение сигналов. Google рассматривает связанные hreflang страницы как одну сущность в разных языках, а не как несколько независимых документов. Ссылочные и поведенческие сигналы, накопленные одной версией, работают на кластер целиком.
Чего hreflang не делает:
- не заменяет качественный контент на языке: если страница переведена машинно и не попадает в формулировки запросов, разметка её не спасёт (почему так, я разбирал в статье о том, на каком языке продвигать сайт в Эстонии);
- не защищает от дублирования: языковые версии дублями и не считаются;
- не является командой. Google называет hreflang сигналом, который он учитывает, но не обязан исполнять.
Как выглядит корректная разметка
Возьмём страницу услуги на сайте с тремя языками. В <head> каждой из трёх версий должен быть один и тот же набор из 4 тегов:
<link rel="alternate" hreflang="et" href="https://example.ee/teenused/seo" />
<link rel="alternate" hreflang="ru" href="https://example.ee/ru/uslugi/seo" />
<link rel="alternate" hreflang="en" href="https://example.ee/en/services/seo" />
<link rel="alternate" hreflang="x-default" href="https://example.ee/teenused/seo" />
Ключевое: набор одинаковый на всех трёх страницах, включая ссылку страницы на саму себя. Это не избыточность: без самоссылки Google считает связь неполной.
Разместить разметку можно тремя способами, и на результат выбор не влияет:
| Способ | Когда удобен | Ограничение |
|---|---|---|
Теги в <head> | Обычные HTML-страницы, большинство сайтов | Раздувает <head> при большом числе языков |
| XML-sitemap | Много языков или нет доступа к шаблону | Труднее проверить глазами |
HTTP-заголовок Link | PDF и другие не-HTML файлы | Настраивается на уровне сервера |
Выбирайте по одному критерию: сможете ли вы генерировать это автоматически. Hreflang, который проставляется руками при публикации страницы, разваливается на второй сотне URL. Это вопрос времени, а не аккуратности.
На этом сайте разметка генерируется из одного реестра соответствий слагов, и языковые версии отдаются Google только для тех страниц, которые реально существуют. Это сознательное ограничение: лучше не отдать hreflang вовсе, чем отдать ссылку на страницу, которой нет.
Шесть ошибок, которые встречаются чаще всего
Ниже собраны 6 ошибок, которые я регулярно нахожу на многоязычных эстонских сайтах при техническом аудите. Порядок примерно соответствует частоте.
| Ошибка | Как проявляется | Что делать |
|---|---|---|
| Невзаимные ссылки | Google игнорирует hreflang для всего кластера | Генерировать разметку из общего источника, а не по странице |
| Нет самоссылки | Связь считается неполной, разметка не учитывается | Добавить hreflang на саму себя во всех версиях |
| Относительные URL | Разметка не парсится | Только абсолютные URL со схемой и доменом |
| Ссылка на редирект или 404 | Связь рвётся молча | Проверять статусы всех URL из разметки краулером |
| Конфликт с canonical | Canonical указывает на другую языковую версию, hreflang аннулируется | Canonical каждой страницы указывает на неё саму |
| Автоматический редирект по языку браузера | Googlebot видит только одну версию | Язык предлагать баннером, а не навязывать редиректом |
Опаснее всего конфликт с canonical: обе разметки по отдельности выглядят правильно. Если русская версия страницы указывает canonical на эстонскую (частая ошибка при копировании шаблона), вы одновременно говорите Google «это самостоятельная языковая версия» и «это копия другой страницы, не индексируй её». Google выбирает canonical, и русская версия просто выпадает из индекса. Похожие сценарии выпадения страниц я разбирал в статье о том, почему страницы не индексируются в Google.
Специфичная для Эстонии ошибка: код языка — не код страны. hreflang="ee" встречается часто, потому что домен .ee стоит перед глазами. Кода языка ee не существует: в ISO 639-1 эстонскому соответствует et. Такой тег просто игнорируется, и разметка становится неполной.
Как проверить, что Google принял разметку
Проверять нужно на трёх уровнях, и первые два не заменяют третий.
- Исходный код. Откройте страницу через «просмотр кода страницы», а не через инспектор элементов. Если теги появляются только в инспекторе, значит их подставляет JavaScript после загрузки, и такая разметка может не попасть в индекс. Проверьте так по одной странице каждого типа: главная, категория, статья, карточка.
- Краулер. Screaming Frog или аналог обходит сайт и показывает то, что руками не найти: невзаимные пары, ссылки на редиректы, отсутствие самоссылки, конфликт с canonical. Это единственный практичный способ проверить сайт больше чем на полсотни страниц.
- Search Console. Финальная инстанция: она показывает, что Google принял, а не что вы отдали. Смотреть нужно отчёт по покрытию и статистику сканирования. Если после внедрения hreflang часть страниц ушла в «Страница является копией», значит конфликтует canonical.
Ждать отражения изменений стоит недели, а не дни: Google должен переобойти все страницы кластера, чтобы увидеть взаимность ссылок. Это та же логика отложенной реакции, о которой я писал, разбирая, почему смена хостинга не ухудшает SEO: изменения видны только после переобхода.
Что я вижу на практике
Несколько наблюдений с эстонских проектов, где разметку я смотрел Screaming Frog и Search Console: без цифр там, где точных цифр у меня нет.
Hreflang почти никогда не является причиной падения трафика. Когда вторая языковая версия не приносит посетителей, в подавляющем большинстве случаев дело не в разметке, а в том, что страницы переведены дословно и не попадают в формулировки запросов своего языка. Hreflang проверяют первым, потому что это быстро и понятно, а реальная проблема лежит в семантике.
Зато сломанный hreflang почти всегда сломан целиком. Я редко встречаю сайт, где разметка корректна на 90% страниц: либо она генерируется из кода и работает везде, либо проставлена руками и рассыпалась почти повсеместно. Промежуточного состояния практически не бывает, и это хорошая новость: чинить нужно генерацию, а не отдельные страницы.
Граница применимости. Всё описанное проверено на сайтах до нескольких тысяч страниц с 2–3 языками. На крупных мультирегиональных проектах, где к языку добавляется десяток стран, появляются свои сложности с приоритетами регионов, и подход к проверке там другой.
Что сделать прямо сейчас
Короткая последовательность из 5 шагов, если у вас есть вторая языковая версия и вы не уверены в разметке.
- Откройте исходный код одной страницы каждой версии и сверьте наборы тегов: они должны совпадать полностью, включая самоссылку.
- Проверьте canonical на неосновных языковых версиях: он должен указывать на саму страницу, а не на основной язык.
- Прогоните сайт краулером и отфильтруйте невзаимные связи и URL с кодами ответа, отличными от 200.
- Уберите автоматический редирект по языку браузера, если он есть, заменив его ненавязчивым баннером с предложением сменить язык.
- Убедитесь, что разметка генерируется, а не проставляется вручную. Если вручную, это первое, что стоит переделать на этапе веб-разработки, пока страниц немного.
Если после этих пяти шагов картина не сложилась или Search Console показывает что-то невнятное — напишите мне. Разбор многоязычной разметки обычно занимает пару часов и входит в технический SEO-аудит; чаще всего проблема оказывается не в hreflang, но найти это стоит до того, как вы вложитесь в контент второй версии.
