Hreflang — это разметка, которая связывает эквивалентные языковые или региональные версии страницы и помогает поисковой системе выбрать подходящий URL для пользователя. Она не переводит контент, не заменяет локализацию и не гарантирует показ конкретной версии. Её задача — описать уже существующую архитектуру сайта без противоречий между языком, регионом, canonical и внутренними ссылками.
Когда международному сайту нужен hreflang
Разметка нужна, когда у одной страницы есть несколько полноценных версий для разных языков или регионов: например, английская страница для Великобритании, отдельная английская версия для США и французская версия для Франции. Если у компании только один сайт на одном языке, добавлять hreflang «на будущее» не требуется.
Сначала необходимо определить, действительно ли версии эквивалентны. Главная страница на французском должна быть связана с главными страницами на других языках, страница услуги — с соответствующей услугой, а статья — с её локализованным аналогом. Нельзя направлять все языковые варианты на одну главную страницу только потому, что для части материалов перевод ещё не готов.
Язык и регион — разные решения
Мультиязычный сайт предлагает контент на нескольких языках. Мультирегиональный сайт ориентирует версии на разные страны или территории. Эти модели могут пересекаться, но не должны смешиваться автоматически. Значение en описывает английский язык без указания страны; en-GB — английскую версию для Великобритании; en-US — английскую версию для США.
Регион следует добавлять только тогда, когда он отражает реальное отличие: ассортимент, цена, валюта, правовые условия, адреса, способы доставки, примеры, контакты или коммерческое предложение. Если английский текст одинаков для всех рынков, создание десятков региональных копий усложняет индексацию и управление без дополнительной ценности для пользователя.
До технической настройки полезно составить языковую карту рынка: язык поиска может отличаться от языка договора, поддержки или решения о покупке. Именно эта карта определяет, какие версии нужны бизнесу, а не перечень стран в презентации компании.
Архитектура URL должна быть стабильной
Google рекомендует использовать разные URL для разных языковых версий. Это может быть отдельный национальный домен, поддомен или директория на общем домене. У каждого варианта есть операционные последствия.
Национальные домены
Домены уровня .fr или .de дают сильный сигнал страны и заметны пользователю, но требуют отдельной инфраструктуры, поддержки и развития авторитета каждого домена. Такая модель оправдана, когда рынки действительно самостоятельны.
Поддомены
Структура вида fr.example.com позволяет разделить продукты и команды, но пользователю не всегда очевидно, обозначает ли префикс язык или страну. Управление аналитикой, релизами и ссылочной структурой тоже требует дисциплины.
Директории
Структура example.com/fr/ обычно проще в поддержке и сохраняет рынки в одном домене. При этом сам URL не объясняет, относится ли fr к французскому языку или Франции, поэтому архитектуру должны подтверждать контент, навигация и hreflang.
URL-параметры для выбора локали Google не рекомендует как основную модель. Независимо от выбранной структуры адреса не должны меняться из-за cookie или заголовка браузера: поисковому роботу и пользователю нужен доступ к каждой версии по постоянной ссылке.
Как устроен корректный набор hreflang
Каждая версия страницы должна перечислять весь набор эквивалентных URL, включая саму себя. Связи должны быть взаимными: если французская страница указывает английскую, английская должна указывать французскую. Для разметки используются полные абсолютные URL.
В базовой группе английская версия получает значение en, французская версия для Франции — fr-FR, а нейтральная страница выбора рынка при необходимости — x-default. Каждый элемент содержит rel="alternate", соответствующее значение hreflang и абсолютный адрес страницы.
x-default обозначает нейтральную страницу для пользователей, для которых не выбрана отдельная языковая или региональная версия. Это может быть глобальная страница или экран выбора рынка. Он не заменяет конкретные языковые значения.
Разметку можно разместить в HTML, HTTP-заголовках или XML sitemap. Для обычных HTML-страниц удобнее выбрать один устойчивый метод, чем одновременно поддерживать несколько источников и создавать расхождения. Для PDF и других не-HTML файлов применим HTTP-заголовок; для крупных систем может быть удобен sitemap.
Hreflang и canonical не заменяют друг друга
Canonical указывает предпочтительный URL среди одинаковых или очень похожих страниц. Hreflang описывает отношения между допустимыми языковыми и региональными версиями. У каждой полноценной локализованной страницы обычно должен быть self-canonical на неё саму, а набор hreflang должен связывать её с эквивалентами.
Ошибка возникает, когда французская страница указывает canonical на английскую. В таком случае команда одновременно сообщает, что французская версия самостоятельна для определённой аудитории, и что предпочтительным документом является другой язык. Google рекомендует при использовании hreflang выбирать canonical на странице того же языка или наиболее близкую языковую замену, если точного варианта нет.
Если две региональные страницы на одном языке почти полностью совпадают, сначала нужно решить, оправдано ли их существование. Иногда корректно выбрать одну основную версию, настроить canonical и оставить региональный сигнал через hreflang. Но это решение следует принимать на уровне контента и коммерческой модели, а не использовать canonical для маскировки массовых копий.
Локализация должна быть видна в самом контенте
Google определяет язык по видимому содержанию страницы, а не только по атрибуту lang или адресу. Перевести меню, оставив основную часть текста на исходном языке, недостаточно. Смешанная страница ухудшает пользовательский опыт и создаёт слабый сигнал для поиска.
Полноценная версия включает локализованные заголовки, навигацию, основной текст, CTA, форму, юридические формулировки и связанные материалы. Для коммерческой страницы также важны валюта, единицы измерения, условия оказания услуги и доказательства, понятные конкретной аудитории. Подход к смысловой адаптации описан в материале о локализации международных коммуникаций.
Почему автоматическое перенаправление мешает
Не следует принудительно отправлять пользователя на другую версию только по IP или языку браузера. Геолокация не всегда точна, люди работают за пределами своей страны, а поисковый робот может не увидеть все варианты. Google прямо рекомендует сохранять доступ к каждой версии и давать пользователю явный переключатель языка или региона.
Допустима мягкая рекомендация: показать ненавязчивое сообщение о доступной локальной версии, не закрывая текущую страницу. Выбор пользователя можно запомнить, но постоянный URL и навигация между версиями должны оставаться доступными.
Операционная модель для международной команды
Проблемы hreflang редко начинаются с синтаксиса. Обычно они появляются, когда локальные команды создают страницы независимо, меняют slug, снимают услугу с публикации или выпускают перевод не одновременно. Поэтому техническая карта должна быть частью управления контентом.
Матрица соответствий
Для каждого типа страницы фиксируются глобальный идентификатор материала, URL каждой версии, язык, регион, статус публикации, canonical, hreflang-группа и владелец обновления. Если версии нет, поле остаётся пустым: нельзя подставлять несоответствующую страницу ради заполнения таблицы.
Правило релиза
Изменение адреса, удаление или публикация новой локали должно обновлять весь набор взаимных ссылок. При миграции URL добавляется постоянный редирект, меняются внутренние ссылки, canonical, hreflang и sitemap. Иначе международная архитектура распадается постепенно, даже если каждая отдельная страница выглядит корректно.
Контроль содержания
Технический статус «разметка валидна» не означает, что версия отвечает локальному спросу. Сопоставьте структуру страницы с реальной выдачей и поисковым спросом на зарубежном рынке. Если интент отличается, рынкам могут понадобиться не эквивалентные переводы, а отдельные страницы; их не следует насильно объединять одной hreflang-группой.
Типичные ошибки международных сайтов
- страница указывает на другие языки, но не содержит self-reference;
- связь существует только в одну сторону;
- использован код страны без кода языка;
- hreflang ведёт на редирект, ошибку 404 или закрытый от индексации URL;
- в группе объединены разные услуги или материалы с разным поисковым интентом;
- canonical направляет локализованную страницу на другой язык;
- sitemap и HTML содержат разные наборы URL;
- пользователя принудительно перенаправляют и не дают вернуться;
- после миграции старые адреса остаются в разметке;
- локализация ограничена навигацией, а основной контент не переведён.
Что проверить перед запуском
Сначала подтвердите бизнес-архитектуру: какие языки и регионы действительно требуют отдельных страниц. Затем проверьте постоянные URL, полноценность локализации, self-canonical и взаимные hreflang-ссылки. После публикации убедитесь, что все URL возвращают 200, доступны для обхода, включены в правильную навигацию и не противоречат sitemap.
Для международного сайта это не разовая техническая задача. Разметку нужно проверять после каждого массового обновления, миграции домена, изменения CMS или запуска новой страны. Её качество зависит от того, насколько стратегия международного сайта связана с процессом локализации и владельцами контента.
Как ICON IMAGE подходит к задаче
Мы начинаем не с генерации тегов, а с карты рынков, языков, поисковых интентов и коммерческих различий. Затем формируем архитектуру URL, матрицу эквивалентных страниц, правила canonical и hreflang, требования к локализации и контроль релизов. Такой подход помогает избежать ситуации, когда технически правильная разметка соединяет стратегически разные страницы.
Если компания готовит новый международный сайт или исправляет существующую структуру, направьте список доменов, языков, рынков и приоритетных услуг. ICON IMAGE определит объём аудита и последовательность внедрения без потери уже накопленной поисковой видимости.
Редакционные источники
Официальная документация Google Search Central проверена 7 октября 2026 года.