Многоязычный сайт: структура, hreflang и частые ошибки

Многоязычный сайт - это не перевод текстов, а отдельная структура. Каждая языковая версия должна жить по своему постоянному адресу (чаще всего в подпапке вида example.ru/en/), все версии связываются между собой атрибутом hreflang, и у каждой свои метатеги, микроразметка, формы и письма. Если версии не связаны или связаны с ошибками, поиск выбирает между ними сам: русская страница вылезает по англоязычному запросу, английская - по русскому, часть страниц уходит в дубли, и трафик проседает сразу по двум языкам. Ключевая деталь, про которую забывают чаще всего: hreflang понимает Google, а Яндекс этот атрибут не использует - в Яндексе язык определяется автоматически, а региональная привязка задаётся в Яндекс Вебмастере для каждого хоста отдельно. Актуально на октябрь 2026 года.

Ниже - практический разбор от Honey Hunters Digital: когда вторая языковая версия действительно нужна, какую структуру выбрать под Яндекс и Google, как собрать hreflang без ошибок, что переводить кроме видимых текстов, сколько часов на это уходит и что делать с заброшенной английской версией, которая до сих пор висит на сайте. В конце - чек-лист проверки и ответы на частые вопросы.

Когда сайту действительно нужна вторая языковая версия

Вторая языковая версия оправдана в одном случае: у вас есть или ожидается поток людей, которые не могут купить на текущем языке. Это экспорт, работа с иностранными партнёрами, туризм, медицина и образование для приезжих, IT-продукты с зарубежными клиентами, B2B с англоязычными закупщиками. Если такого потока нет, языковая версия превращается в мёртвый раздел, который размывает структуру и съедает время на поддержку.

Проверить это можно до разработки, по данным, которые у вас уже есть:

1. Яндекс Метрика и Google Analytics - отчёт по языку браузера и по странам. Если доля небраузерного русского языка меньше 1-2 процентов и это не ваши целевые страны, спроса пока нет.
2. Поисковые запросы - в Яндекс Вебмастере и Google Search Console посмотрите, приходят ли показы по латинице и по названиям товаров на английском.
3. Входящие обращения - письма и заявки на английском, звонки из других стран, вопросы в мессенджерах.
4. Конкуренты - есть ли англоязычные версии у тех, кто работает в вашей нише на экспорт, и ранжируются ли они.

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

Структура: подпапка, поддомен или отдельный домен

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

1. Подпапка: example.ru/en/
Все версии на одном хосте, вся накопленная история домена работает на обе версии, SSL и настройки сервера одни. Самый простой вариант для внедрения и поддержки, подходит большинству проектов. Минус - в Яндексе вы не сможете присвоить подпапке отдельный регион, региональная привязка в Вебмастере задаётся для хоста целиком.

2. Поддомен: en.example.ru
Для Яндекса это отдельный хост: его можно добавить в Вебмастер самостоятельно и задать свой регион. Для Google поддомен тоже отдельный сайт, авторитет передаётся частично. Нужны отдельный SSL (или wildcard-сертификат), отдельные счётчики и отдельная работа по ссылкам.

3. Отдельный домен: example.com, example.de
Максимальный геосигнал и полная независимость версий: своя CMS, свой хостинг рядом с аудиторией, своя юридическая страница. Дороже всего: продвижение, поддержка и безопасность умножаются на число доменов. Оправдано, когда зарубежное направление - самостоятельный бизнес с отдельным бюджетом, а не «ещё один язык».

Чего делать не стоит: отдавать язык параметром вида example.ru/page?lang=en или определять его только по cookie и сессии. У версии должен быть отдельный постоянный URL, иначе поиску просто нечего индексировать - он увидит один адрес с меняющимся содержимым. По той же причине не делайте автоматический редирект по IP: робот Google обходит сайт из США и будет видеть только английскую версию, а живой пользователь из России на английском домене не сможет вернуться на русский. Правильное решение - показывать ненавязчивый баннер «Open in English» со ссылкой и запоминать выбор, не трогая URL.

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

Как работает hreflang и куда его ставить

hreflang - это атрибут, которым вы сообщаете Google: «вот та же страница на другом языке». Он не влияет на позиции напрямую и не является командой, это подсказка, которая помогает поиску показать нужную версию нужному человеку и не считать версии дублями. Google поддерживает три способа передать hreflang, и они равнозначны: теги в head, HTTP-заголовки Link и элементы в XML-карте сайта.

Самый распространённый способ - теги в <head> каждой страницы. Для сайта с русской и английской версиями блок выглядит так:

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

Этот блок одинаковый на обеих страницах и включает ссылку на саму себя - это обязательное требование. Значение x-default указывает версию для всех, кто не попал ни в одну языковую группу; обычно это главная языковая версия или страница с выбором языка.

Для PDF и других файлов, у которых нет head, используется HTTP-заголовок. Для больших каталогов удобнее карта сайта: в ней hreflang описывается один раз для каждой группы страниц, не нужно трогать шаблоны, и правки не зависят от вёрстки. На сайте в несколько тысяч URL это обычно единственный реалистичный вариант.

Пять правил корректного hreflang

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

1. Двусторонность. Если страница A ссылается на B как на английскую версию, страница B обязана ссылаться на A. Односторонние связи не учитываются.
2. Самоссылка. В наборе hreflang каждой страницы должна быть ссылка на саму себя с её собственным языком.
3. Согласие с canonical. hreflang должен указывать на канонические URL, а rel=canonical каждой страницы - на саму себя. Если canonical английской страницы ведёт на русскую, вы одновременно говорите «это отдельная версия» и «это копия, не индексируй» - разметка перестаёт работать.
4. Правильные коды. Язык - по ISO 639-1 (ru, en, de), регион - по ISO 3166-1 alpha-2 и только вместе с языком: en-GB корректно, en-UK нет (код Великобритании - GB), просто GB тоже нет. Указать регион без языка невозможно.
5. Абсолютные URL с протоколом. Только https://example.ru/en/, без относительных путей и без смеси http и https.

Проверять это руками на большом сайте бессмысленно. В Google Search Console есть отчёт по международному таргетингу, а целостность связей удобно проверять краулером (Screaming Frog, Netpeak Spider и аналоги): они показывают односторонние hreflang, конфликты с canonical и неверные коды списком.

Яндекс и языковые версии: hreflang не поможет

Яндекс hreflang не поддерживает и язык страницы определяет сам, по её содержимому. Поэтому для Яндекса работают другие инструменты: корректная региональная привязка хоста в Яндекс Вебмастере, язык и регион в разделе «Региональность», понятная структура URL и отсутствие смешанного контента, когда на одной странице половина текста на русском, а половина на английском.

Практические следствия для российского бизнеса, у которого основной трафик идёт из Яндекса:

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

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

Что переводить, кроме текстов

Перевод страницы - это примерно половина работы. Вторая половина - всё, что человек видит не в тексте, и всё, что видит робот. По опыту Honey Hunters Digital именно здесь обнаруживается большая часть недоделок, когда клиент приходит с уже сделанной «английской версией».

Список того, что нужно перевести и проверить:

1. Метатеги - title и description на каждой странице, а не копия русских.
2. Разметка schema.org - названия, описания, валюта и язык в inLanguage.
3. Хлебные крошки, меню, подвал, кнопки - включая надписи внутри картинок и иконок.
4. Формы - подписи полей, подсказки, тексты ошибок валидации, сообщение об успешной отправке, чекбокс согласия на обработку данных.
5. Автоматические письма - подтверждение заявки и заказа, восстановление пароля, уведомления.
6. Юридические страницы - политика обработки персональных данных и пользовательское соглашение. Для иностранных пользователей может потребоваться отдельный блок про GDPR, если вы работаете с ЕС.
7. Валюта, единицы измерения, форматы даты и телефона - 10.09.2026 и 09/10/2026 читаются по-разному, это прямая причина ошибок в заявках.
8. Страница 404, страницы фильтров и пагинации, тексты в онлайн-чате.
9. URL - английские адреса латиницей по смыслу (/en/services/), а не транслитом с русского (/en/uslugi/).

Про машинный перевод отдельно. Черновик нейросетью - нормальный рабочий инструмент, им пользуются все. Публиковать его без редактуры носителем или хотя бы профильным редактором - нет: Google прямо относит к спаму масштабное создание страниц переводом без добавления ценности, а живой клиент уходит с страницы, где название услуги переведено дословно и звучит нелепо. Минимальный разумный порог - человеческая редактура коммерческих страниц (услуги, цены, формы, контакты) и выборочная проверка остального.

9 ошибок, которые ломают многоязычный сайт

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

1. Односторонний hreflang. Разметку поставили только на русских страницах, английские о них не знают. Google игнорирует весь набор.
2. canonical против hreflang. У всех английских страниц canonical ведёт на русские - версия не индексируется в принципе.
3. Неверные коды. en-UK, ru-RU на английской версии, ua вместо uk для украинского, регион без языка.
4. hreflang на неканонические или редиректящие URL. Ссылки ведут на адреса со слешем, которых уже нет, или на http.
5. Автоматический редирект по IP или по языку браузера. Робот видит одну версию, пользователь не может переключиться вручную.
6. Непереведённые метатеги и разметка. Технически версии разные, для поиска - близкие дубли.
7. Разный набор страниц. На русском 300 страниц, на английском 12, и hreflang расставлен «куда попало»: несуществующие соответствия ведут на главную. Лучше связывать только реальные пары, а для остального не ставить hreflang вовсе.
8. Один счётчик без разделения. Метрика и Analytics считают обе версии в одну воронку, понять, работает ли английская, невозможно. Нужны отдельные цели или хотя бы сегмент по языку.
9. Версия без владельца. За русскую часть отвечает маркетолог, за английскую - никто. Через полгода там устаревшие цены и битые формы.

Сколько это стоит по трудоёмкости

Деньги в такой задаче считаются от часов, и разброс зависит не от числа языков, а от того, поддерживает ли CMS мультиязычность из коробки. Ориентиры по нашей практике (без перевода контента, только техническая часть):

• Подключить hreflang на готовый двуязычный сайт - 4-10 часов: шаблоны или карта сайта, проверка краулером, настройка отчётов.
• Добавить вторую языковую версию в CMS, где мультиязычность встроена (современные Bitrix, Drupal, WordPress с плагином, большинство фреймворков) - от 20 до 50 часов: словари интерфейса, дубли шаблонов, переключатель, формы, письма.
• То же в CMS без поддержки мультиязычности - от 60-80 часов и выше, иногда дешевле переехать на другую платформу, чем надстраивать.
• Перенос языковой версии из параметра или поддомена в подпапку - 15-30 часов плюс карта редиректов и месяц наблюдения за индексацией.
• Перевод - считается отдельно, по знакам, у переводчика или бюро. На рынке вилка очень широкая, от копеечного постмашинного редактирования до носителя с отраслевой специализацией, и для коммерческих страниц экономия здесь обходится дороже всего.

Дальше появляется постоянная работа: обновлять две версии вместо одной, следить за тем, чтобы правка на русском доезжала до английского, проверять формы и письма. Это ровно та задача, под которую у нас есть техническая поддержка сайта: базовый тариф - от 15 000 ₽ в месяц, в него входят 4 часа работ и «Красная кнопка» на срочные случаи. Для двуязычного сайта среднего размера этого обычно хватает на регулярные правки и мониторинг; если доработок больше, берут тариф с переносом неиспользованных часов.

Чек-лист проверки перед запуском

Пройдите этот список до того, как открывать вторую версию для поиска. Проверка занимает 1-2 часа и снимает почти все типовые проблемы.

1. У каждой языковой версии постоянный URL, язык не зависит от cookie и IP.
2. hreflang двусторонний, с самоссылкой и x-default, коды языков и регионов корректны.
3. canonical каждой страницы ведёт на саму себя.
4. Все URL в hreflang отвечают кодом 200, без редиректов и без http.
5. title и description переведены и уникальны, разметка schema.org переведена, в ней указан язык.
6. Переключатель языков есть на всех страницах и ведёт на аналог страницы, а не на главную.
7. Формы, тексты ошибок, согласие на обработку данных и автоматические письма - на нужном языке.
8. Языковая версия есть в карте сайта, не закрыта в robots.txt и не помечена noindex.
9. Хост добавлен в Яндекс Вебмастер и Google Search Console, регион задан, если он нужен.
10. В Метрике и Analytics настроены отдельные цели или сегменты по языку, чтобы через месяц можно было оценить результат.

Если английская версия заброшена: что с ней делать

Заброшенную языковую версию нужно либо дооформить, либо убрать с редиректами - оставлять её «как есть» хуже обоих вариантов. Решение принимается по данным: смотрим в Метрике и Search Console, есть ли на ней визиты и показы за последние полгода, и приходят ли оттуда обращения.

Если трафика нет и возвращаться к направлению не планируется, версия аккуратно закрывается: постранично настраиваются 301-редиректы на русские аналоги, адреса убираются из карты сайта, внутренние ссылки и переключатель языков вычищаются, hreflang удаляется. Так мы поступили и со своим сайтом: заброшенная английская версия honey-hunters.ru была полностью склеена редиректами с русскими страницами, а карта сайта переведена на одноязычную схему - вместо 361 адреса с мёртвыми /en/ в ней осталось 308 живых. Выкидывать такие URL в 404 не нужно: редирект сохраняет накопленные сигналы и внешние ссылки.

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

Чем мы можем помочь

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

А ещё мы разбираем похожие технические истории короткими заметками в Telegram - без лишней теории, с примерами из реальных проектов. Если вам ближе читать по чуть-чуть, а не большими статьями, заглядывайте в «Тусовку владельцев сайтов»: t.me/sitetusovka.

Частые вопросы

Поддерживает ли Яндекс hreflang?
Нет. Яндекс не использует атрибут hreflang и определяет язык страницы по её содержимому. Для Яндекса важны региональная привязка хоста в Яндекс Вебмастере и отсутствие смешанного контента на странице. Ставить hreflang всё равно нужно - он работает для Google и не мешает Яндексу.

Что лучше: подпапка example.ru/en/ или поддомен en.example.ru?
В большинстве случаев подпапка: она проще в поддержке, использует историю основного домена и не требует отдельного сертификата. Поддомен выбирают, когда языковой версии нужна отдельная региональная привязка в Яндексе, потому что регион в Вебмастере задаётся для хоста, а не для папки.

Нужен ли x-default, если языков всего два?
Он не обязателен, но полезен. x-default указывает версию для всех, кто не подходит ни под один язык из вашего набора, - обычно это главная версия сайта или страница выбора языка. Без него Google выберет версию сам.

Можно ли перевести сайт нейросетью и опубликовать как есть?
Черновик - можно, публикацию без редактуры - нет. Масштабное создание страниц машинным переводом без добавления ценности Google относит к спамным практикам, а на коммерческих страницах дословный перевод названий услуг и кнопок напрямую снижает конверсию. Минимум - человеческая редактура услуг, цен, форм и контактов.

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

Сколько ждать результата после запуска языковой версии?
Индексация новых страниц занимает от нескольких дней до нескольких недель, первые стабильные позиции по неконкурентным запросам - обычно 2-4 месяца, по конкурентным - дольше. Если версия вышла, а показов в Search Console нет через месяц, проблема почти всегда техническая: noindex, robots.txt, конфликт canonical или односторонний hreflang.