Мультиязычный сайт живёт с хронической болезнью: немецкая версия выскакивает в выдаче для американцев, британская карточка товара конкурирует с американской, а языковой селектор вообще никак не находится. Google способен сам найти переводы, но без подсказок путает их годами. Hreflang - прямая карта для поисковой системы: какие страницы являются вариантами друг друга и для каких языков и регионов написаны. Разберём настройку аннотаций через XML sitemap, разберёмся с x-default и соберём ошибки, которые ломают разметку молча.
Что hreflang сообщает поисковику и чего от него ждать нельзя
Аннотация hreflang не определяет язык страницы - Google вычисляет язык алгоритмически, и атрибут lang вместе с hreflang на это не влияет. Задача меток другая: связать версии одной страницы в группу, чтобы система показывала посетителю вариант под его языковыми настройками, а не первую попавшуюся копию. Это не разовый буст позиций, а корректная развязка: каждая версия получает своих посетителей, и дубли не глушат друг друга в выдаче.
Google рекомендует размечать три типовых сценария: сайт с единым языком контента и переведённым шаблоном, как бывает на форумах с пользовательскими записями; контент с небольшими региональными вариациями одного языка, например английские версии для США, Британии и Ирландии; и полноценные переводы всего сайта. Локальные версии считаются дублями, только если основной контент остался непереведённым - в остальных случаях это самостоятельные страницы со своими шансами в выдаче. Hreflang читает и Бинг, для которого метки работают как подсказка, так что разметка окупается не только в Google.
В выдаче это работает так: посетитель с немецкими настройками браузера получает немецкую версию, с британскими - британскую, а если нужной версии нет, система выбирает ближайшую или страницу по умолчанию. Без меток Google тоже находит переводы - по ссылкам, sitemap и совпадениям структуры, - но на сайтах с близкими адресами и одинаковым шаблоном регулярно путает их между собой.
Формат кодов языка региона и письменности без ошибок
Значение атрибута состоит из одного кода или двух через дефис: сначала язык в формате ISO 639-1, затем опционально регион в формате ISO 3166-1 Alpha 2. Примеры корректных значений: en-US, de-CH, pt-BR. Только регион указывать нельзя: значение без языка система не поймёт, а коды вроде UK, EU и UN вообще не входят в стандарт и не производят никакого эффекта. Кто-то обязательно напишет en-UK - и эта метка сработает в пустоту.
Классическая ловушка - Бельгия. Код be - это белорусский язык, а не страна, поэтому для бельгийских аудиторий нужны значения de-BE, nl-BE или fr-BE. Похожая история с Латинской Америкой: популярный в маркетинге код es-419 системой не поддерживается, работают только значения из стандартов. Для письменностей используется ISO 15924: zh-Hans для упрощённого китайского, zh-Hant для традиционного, при желании с регионом вроде zh-Hans-US. Для значений вида zh-TW письменность выводится автоматически. Регистр система не различает, но по конвенции регион пишут в верхнем регистре - так метки легче читать людям.
Для русскоязычных проектов картина похожая: код ru без региона покрывает весь русский язык, а значения ru-KZ, ru-BY и ru-UA уточняют страну, когда контент для неё реально отличается - своя валюта, своя доставка, свои остатки.
Языки и регионы в разметке международного магазина
Схема адресов может быть любой: языковые подпапки, поддомены или отдельные домены в национальных зонах - hreflang работает со всеми вариантами, и метки могут вести на другие домены. Структура не влияет на корректность разметки, она влияет на сопровождение: единый домен с подпапками обслуживается одним sitemap, а разрозненные домены требуют файлов и отчётов на каждый хост.
Что ставить в метки, подсказывает сам контент. Если магазин одинаковый для всех немецкоязычных, достаточно кода de без региона: он покрывает и Германию, и Австрию, и Швейцарию. Если различаются цены, валюта и условия доставки, добавляйте регионы: de-DE, de-AT, de-CH. Правило одно: метка без страницы за ней - ошибка, а страница без меты - потерянная связь, и разметка всегда следует за реальными различиями, а не за списком стран из презентации отдела продаж.
Три способа разметки и почему sitemap удобнее при сотнях страниц
Google принимает hreflang тремя равнозначными способами: тегами link в разделе head, HTTP-заголовком и XML sitemap. Вести все три сразу не нужно - выгоды нет, а расхождений между ними больше. HTML-вариант годится для небольших сайтов: в head каждой страницы добавляется одинаковый набор ссылок на все версии, включая саму страницу:
<link rel="alternate" hreflang="en-GB" href="https://en-gb.example.com/page.html" />
<link rel="alternate" hreflang="en-US" href="https://en-us.example.com/page.html" />
<link rel="alternate" hreflang="en" href="https://en.example.com/page.html" />
<link rel="alternate" hreflang="de" href="https://de.example.com/page.html" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/" />
Для head-варианта есть мелкие, но настоящие требования: теги link обязаны лежать внутри валидного раздела head, и нельзя сваливать hreflang вместе с другими атрибутами вроде media в один тег - проверка валидатором HTML снимает вопрос за минуту.
HTTP-заголовок выручает не-HTML файлы вроде PDF:
Link: <https://www.example.com/en/page.pdf>; rel="alternate"; hreflang="en", <https://www.example.de/page.pdf>; rel="alternate"; hreflang="de"
Когда страниц сотни и тысячи, смена одной версии в head всех страниц превращается в проект - и тут выигрывает sitemap. Файл объявляет пространство имён xhtml, для каждого адреса создаётся элемент url, а внутри него перечисляются все варианты через xhtml:link, включая ссылку на саму страницу:
<?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://www.example.com/english/page.html</loc>
<xhtml:link rel="alternate" hreflang="de"
href="https://www.example.de/deutsch/page.html"/>
<xhtml:link rel="alternate" hreflang="en"
href="https://www.example.com/english/page.html"/>
</url>
</urlset>
Дочерние xhtml:link не съедают лимит файла: счётчик ведётся по элементам url. Общие лимиты sitemap прежние - не больше 50 000 URL и 50 МБ без сжатия на файл, дальше собирается sitemap index. И старое правило продолжает работать: sitemap описывает только адреса, вложенные в каталог, где он лежит, поэтому для поддоменов готовят отдельные файлы.
Практическое различие между способами - в сопровождении. Правка в head требует выката каждой страницы группы, а правка в sitemap - одного файла и переотправки в Search Console. На сайте с десятью языками и тысячей страниц это разница между вечеринкой с релизами и рутинной задачей на полчаса. Поэтому на крупных проектах sitemap-метод становится стандартом по умолчанию: робот читает его так же, а человеку разбираться в разы проще.
Правило взаимности и самоссылка как фильтр корректности
Ключевое правило hreflang - взаимность. Каждая версия обязана ссылаться на себя и на все остальные версии, и набор меток одинаков на каждой странице группы. Если страница X объявляет своей версией страницу Y, а Y в ответ не упоминает X, система игнорирует обе метки. Это защита: без обратной ссылки любой чужой сайт мог бы объявить себя английской версией вашего каталога и тянуть ваш трафик.
На сайтах с десятками языков полный набор на каждой странице поддерживать тяжело, и Google допускает упрощение: часть языков с части страниц можно убрать, сохранив взаимность для оставшихся пар. Но у правила есть приоритет: новые языковые разделы обязаны двусторонне ссылаться на доминирующий язык проекта. Если основной каталог давно живёт на немецком, а испанский и мексиканский разделы только запустились, важнее связать их с немецкой версией, чем друг с другом.
Новый язык на живом проекте - всегда обновление всего набора: у каждой существующей страницы появляется ещё одна метка. В sitemap это одна генерация файла, в head - релиз шаблона для всех страниц группы. Отсюда практический совет для крупных проектов: выбирайте один способ и держите его в одной системе, чтобы правки не расползались по разным местам.
Отдельная рекомендация для одногруппных локалей: если у сайта есть en-IE, en-CA и en-AU, стоит держать и общий en для остальных англоязычных стран. Все адреса в метках - абсолютные, с явным указанием протокола, а не относительные пути и не ссылки без транспорта.
Резервная версия по умолчанию без мифов и частые ошибки
Значение x-default придумано для случая, когда язык посетителя не совпал ни с одной меткой. Классические места применения - языковой селектор и главная страница с автопересылкой под настройки браузера. Языковой код x-default не присваивается: страница предназначена тем, чьи настройки не покрыты, и её язык системе не важен. Добавляется метка как ещё одна ссылка в общий набор:
<link rel="alternate" href="https://example.com/en-gb" hreflang="en-GB" />
<link rel="alternate" href="https://example.com/en-us" hreflang="en-US" />
<link rel="alternate" href="https://example.com/country-selector" hreflang="x-default" />
Типовые ошибки с x-default предсказуемы. Первая - ставить x-default вместо настоящих языковых меток на всех страницах: селектор не заменяет переводы, он только ловит неподходящих посетителей. Вторая - вести метку на адрес с редиректом: робот должен получить код 200 и увидеть саму страницу, иначе связка теряется. Третья - автопересылка по геолокации без селектора: пользователь из Франции получает немецкую версию без права выбора, а метки обещали свободу. Четвёртая - конфликт с каноником: если alternate-адрес канонизирован на другую страницу, группа разваливается, и система выбирает одну версию, игнорируя остальные.
Сам селектор при этом должен быть честной страницей: индексируемой, без запрета в robots.txt, с обычными ссылками на все версии. Робот проходит по ним как обычный посетитель, а x-default маркирует эту дверь для тех, чей язык не совпал ни с одной меткой группы.
Проверка аннотаций и контроль после запуска
Автоматизировать проверку помогают Screaming Frog с отчётом по hreflang и онлайн-валидаторы вроде инструмента Merkle: они находят односторонние метки, битые коды и расхождения наборов. Проверять стоит все версии подряд: ответ каждой alternate должен быть кодом 200, robots.txt не должен блокировать языковые каталоги, каноники должны указывать на сами страницы, а не на соседние версии.
Чеклист перед выкаткой выглядит так:
- все коды проверены по ISO 639-1 и ISO 3166-1 и псевдокоды удалены из меток;
- каждая страница ссылается на себя и на все свои переводы одинаковым набором;
- все адреса абсолютные и совпадают по протоколу с канониками;
- x-default ведёт на селектор или нейтральную главную без пересылки по геолокации;
- все alternate отвечают кодом 200 и открыты для обхода в robots.txt.
Прежний отчёт международного таргетинга в Search Console закрыли ещё в 2022 году, поэтому контроль остался ручным: отчёты по каждому хосту, проверка выдачи в целевых странах и периодические прогоны валидатором. Правки удобнее вносить пакетно - одной генерацией sitemap, - после чего переслать файлы и выждать пару недель: система переваривает hreflang не мгновенно, и паника на третий день обычно преждевременна. Симптомы беды узнаваемы: версия языка не появляется в индексе, между переводами всплывают канонические конфликты, а в выдаче не той страны постоянно мелькает чужая локаль. Стратегия разметки на вырост проста: фиксируйте варианты в таблице страница-язык-регион, храните единственный источник правды и не допускайте ручных правок на отдельных страницах. Hreflang ломается не от сложности, а от бессистемности.
Hreflang не панацея от плохого контента и слабых ссылок, но он снимает с проекта самую глупую проблему - конкуренцию сайта с самим собой в чужих странах.