Мультиязычный сайт и hreflang в 2026: как сделать правильно и не потерять SEO

Мы разбирали сайт петербургской компании, которая продавала оборудование в Казахстан и Беларусь. Тексты были на русском, домен один, но для Казахстана завели поддомен kz.company.ru с теми же ценами в тенге. Через полгода поддомен просел в выдаче, а на главном домене начали дублироваться сниппеты - в Google то казахстанская версия, то российская всплывали под один и тот же запрос. Hreflang на сайте не было вообще - ни одного тега. Поисковик сам решал, какую версию показать кому, и решал через раз.

Это типичная история для сайтов, которые растут в разные страны или языки без продуманной архитектуры. Ниже - когда мультиязычность вообще нужна бизнесу, как выбрать структуру и как настроить hreflang так, чтобы поисковик показывал нужную версию нужному человеку.

Когда бизнесу действительно нужен мультиязычный сайт

Не каждому экспортёру нужна отдельная языковая версия. Мультиязычность оправдана, когда у вас есть подтверждённый спрос из другой языковой аудитории: заявки на английском в почте, трафик из зарубежного IP с высоким отказом, менеджеры, которые переписываются с клиентами через переводчик.

По данным опроса CSA Research (2020 год, 8 709 респондентов в 29 странах), 76% людей предпочитают покупать товары с описанием на родном языке, а 40% никогда не купят на сайте, где нет их языка. Цифра пятилетней давности, но логика не изменилась - люди платят охотнее, когда читают на своём языке, а не гуглят перевод в уме.

Три сценария, где мультиязычность нужна почти всегда: интернет-магазин с доставкой за границу, B2B-компания с иностранными клиентами и SaaS-продукт с международной аудиторией. А вот локальному бизнесу - парикмахерской, стоматологии, кафе в одном городе - вторая языковая версия почти никогда не нужна, даже если часть клиентов иностранцы. Расходы на поддержку версии не окупятся трафиком.

Если сомневаетесь - посчитайте долю нерусскоязычного трафика в Яндекс.Метрике за последние три месяца и почту на предмет обращений на других языках. Меньше 3-5% от общего объёма - подождите с отдельной версией, займитесь SEO на основном языке.

Отдельно стоит сказать про полумеры. Виджет автоперевода в углу экрана - не мультиязычный сайт, а заплатка. Поисковик индексирует исходный язык страницы, виджет работает только на стороне браузера конкретного пользователя и никак не помогает с ранжированием в другой стране. Если задача - именно органический трафик из-за рубежа, а не разовая вежливость к случайному гостю, нужна полноценная версия с собственными URL, а не JS-надстройка поверх старого контента.

Подфолдер, поддомен или отдельный домен: что выбрать

Три рабочих схемы. У каждой свои плюсы, и универсального победителя нет - зависит от бюджета и стратегии бизнеса.

Подфолдер (example.com/en/, example.com/de/) - самый частый выбор для среднего и малого бизнеса. Все языковые версии живут на одном домене, значит весь накопленный вес домена и ссылочный профиль работают на все версии сразу. Технически проще всего: один SSL-сертификат, один хостинг, одна установка Метрики. Минус - слабее геосигнал для конкретной страны, чем у ccTLD.

Поддомен (en.example.com) для поисковика выглядит почти как отдельный сайт. Авторитет с основного домена передаётся ему не полностью и не мгновенно; новому поддомену придётся нарабатывать доверие почти с нуля. Выбирайте эту схему, только если разным версиям реально нужна разная техническая инфраструктура - например, разный сервер под геолокацию или отдельная команда разработки.

ccTLD (example.de, example.fr) даёт самый сильный сигнал локальной релевантности - алгоритмы и пользователи воспринимают такой домен как местный бизнес. Обратная сторона: каждый домен - это отдельная регистрация, отдельный Вебмастер и Search Console, отдельная ссылочная масса, которую нужно наращивать с нуля. Для десяти рынков это в буквальном смысле десять сайтов. Такой подход по силам обычно только крупным брендам с бюджетом на локальную команду под каждую страну.

Для большинства проектов, с которыми мы работаем, подфолдер закрывает задачу полностью. Не нужно тащить на баланс отдельные домены ради одной языковой версии, которая даёт 200 визитов в месяц.

Мультиязычность - не то же самое, что мультирегиональность

Здесь часто путают два разных механизма. Мультиязычность - разный язык контента (русский, английский, немецкий), и за неё отвечает hreflang. Мультирегиональность - один язык, но разные страны или города с разными ценами, доставкой и региональной спецификой; здесь у Яндекса работает своя логика.

Для сайта на русском, который продаёт в Россию, Казахстан и Беларусь без смены языка, Яндекс.Вебмастер предлагает привязку региона на уровне поддомена или отдельного раздела, а не hreflang - у каждого поддомена можно указать свою региональность, чего нельзя сделать в рамках одного домена. Google в этой же ситуации всё равно ждёт hreflang с региональным кодом вида ru-KZ или ru-BY - иначе видит дублирующийся контент на трёх версиях одного языка. Поэтому на практике часто приходится настраивать оба механизма параллельно: региональность в Яндекс.Вебмастере плюс hreflang для Google.

Как работает hreflang

Hreflang - атрибут, который указывает поисковику: "вот та же страница, но для другого языка или региона". Не переключатель на сайте и не элемент интерфейса - чисто техническая инструкция в коде, невидимая для посетителя.

Три способа разместить тег: в <head> каждой HTML-страницы, в HTTP-заголовке (для PDF и других не-HTML файлов) или единым блоком в XML-карте сайта. Для сайта до нескольких сотен страниц проще всего первый вариант.

<link rel="alternate" href="https://example.com/" hreflang="x-default" />
<link rel="alternate" href="https://example.com/" hreflang="ru" />
<link rel="alternate" href="https://example.com/en/" hreflang="en" />
<link rel="alternate" href="https://example.com/de/" hreflang="de" />

Три правила, без которых тег не работает вовсе.

Самоссылка. Каждая языковая версия обязательно указывает саму себя в списке - страница на английском должна содержать hreflang="en" саму на себя, а не только ссылки на русскую и немецкую версии.

Полная взаимность. Если русская версия ссылается на английскую, английская обязана ссылаться обратно на русскую - и так для каждой пары версий. По документации Google Search Central, набор ссылок должен быть идентичным на всех вариантах страницы, включая её саму; одна пропущенная обратная ссылка обесценивает разметку для всего кластера.

x-default. Версия для пользователей, чей язык не совпал ни с одним указанным вариантом - обычно страница выбора языка или международная версия на английском. Google и Яндекс совместно поддержали это расширение ещё в 2013 году, задолго до нынешнего бума мультиязычных сайтов.

Код языка - двухбуквенный ISO 639-1 (en, de, ru), код региона через дефис - ISO 3166-1 Alpha-2 (en-US, en-GB, pt-BR). Регион указывать не обязательно, если контент не отличается по странам внутри языка; добавляйте его только когда действительно есть разные версии для разных стран.

Частые ошибки hreflang

По данным Ahrefs, у более 67% доменов, использующих hreflang, есть та или иная ошибка в разметке. Цифра выглядит пугающе, но на практике почти все ошибки укладываются в несколько повторяющихся паттернов.

Отсутствие обратной ссылки - самая частая проблема. Страница А ссылается на страницу Б, а Б на А - нет. Поисковик в такой ситуации просто игнорирует всю связку тегов, как будто hreflang не было вообще.

Неверные коды языка и региона. "ua" вместо "uk" для украинского (ua - код страны Уганда), "en-UK" вместо правильного "en-GB", смешение регистра. Один опечатанный код - и версия выпадает из кластера незаметно, без явной ошибки в отчётах.

Hreflang указывает на URL с ошибкой 404, редиректом или canonical на другую страницу. Тег должен вести на финальный рабочий адрес страницы, а не на промежуточное звено цепочки редиректов.

Забытая самоссылка - когда страница перечисляет все остальные версии, но не саму себя. Мелочь, которая ломает весь смысл разметки.

Hreflang без соответствующего тега canonical или конфликтующий с ним. Если canonical страницы на английском указывает на русскую версию, а hreflang одновременно называет её самостоятельной языковой версией - поисковик получает противоречивые сигналы и обычно выбирает canonical, игнорируя языковую разметку.

Кстати, отдельная боль - JS-фреймворки, где hreflang генерируется на клиенте и не попадает в исходный HTML. Краулер может его просто не увидеть при первом проходе.

Перевод: человек или машина

Прямого запрета на машинный перевод у Google нет. Ещё в 2024 году компания убрала из документации рекомендацию блокировать автоматически переведённые страницы через robots.txt - формулировка сместилась с "как создан контент" на "полезен ли он пользователю". Показательный пример: Reddit в 2025 году массово развернул ИИ-переводы разделов на несколько языков без штрафных санкций со стороны Google.

Но это не индульгенция на сырой перевод без вычитки. Массовый низкокачественный автоперевод по-прежнему подпадает под политику Google о "масштабном спам-контенте" (scaled content abuse) - там про контент, который не приносит пользы, независимо от того, кто или что его сгенерировало.

По нашей практике, разумный компромисс - машинный перевод как черновик плюс редактура носителем языка или квалифицированным переводчиком. Особенно критично для коммерческих страниц: цены, условия доставки, юридические формулировки, гарантии. Ошибка в переводе договора оферты стоит дороже, чем экономия на переводчике. Для блога и статей планка ниже, но грамматические ошибки на первом экране всё равно подрывают доверие мгновенно - посетитель уходит, даже не дочитав.

Если решили использовать машинный перевод, честно укажите об этом - Google прямо рекомендует явно сообщать пользователям, что материал переведён и проверен. Это не только соответствие рекомендациям, но и элементарная прозрачность.

И ещё один момент, который упускают почти всегда: перевод - не локализация. Перевести текст дословно и адаптировать его под культурный контекст - разные задачи. Валюта, формат даты, единицы измерения, примеры и даже цветовые ассоциации в баннерах должны меняться под аудиторию, а не только слова. Сайт, где цена указана в рублях под немецким флагом в шапке, выглядит небрежно даже при идеальной грамматике - и это тоже сигнал доверия, который считывает не только пользователь, но и Google через поведенческие метрики.

Как проверить, что hreflang настроен верно

Начните с бесплатного отчёта в Google Search Console - раздел "Международный таргетинг" показывает найденные ошибки hreflang по всему сайту, включая отсутствующие обратные ссылки. У Яндекс.Вебмастера отдельного эквивалентного отчёта нет, поэтому для российского рынка проверка чаще идёт через сторонние инструменты.

Для точечной проверки одной страницы - бесплатные валидаторы hreflang.org и инструмент от Merkle: вставляете URL, получаете список найденных тегов и статус каждой обратной ссылки. Для сайтов от полусотни страниц удобнее краулер: Screaming Frog с активированной проверкой hreflang в настройках вытащит все ошибки разом в одну таблицу, с которой потом работает разработчик.

Мы делаем такую проверку частью технического SEO-аудита для любого клиента с несколькими языковыми версиями - в 2026 году это уже стандартный пункт чеклиста, а не экзотика.

Ещё один практический приём - открыть страницу в режиме инкогнито с VPN нужной страны и посмотреть, какая версия реально показывается в выдаче Google по целевому запросу. Разница между тем, что показывают инструменты, и тем, что видит живой пользователь, встречается чаще, чем хотелось бы: кеш поисковика обновляется не мгновенно, и после правок hreflang первые одну-две недели возможны нестыковки.

Если сайт небольшой и версий немного - хватит ручной проверки раз в квартал. Если структура растёт, добавляются страны и языки - настройте автоматический мониторинг hreflang, иначе ошибки накапливаются незаметно, а откатывать их на сотнях страниц болезненно.

Мультиязычность окупается только там, где за ней стоит реальный спрос и аккуратная техническая база. Постройте архитектуру, проверьте hreflang по чеклисту выше и не переводите сайт наспех ради галочки - половинчатая локализация раздражает пользователя больше, чем её отсутствие.