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

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

Честно: международное SEO — это не «галочка» и не «перевели пару лендингов». Это отдельный канал роста, который либо приносит стабильный поток лидов из новых стран, либо тихо сливает бюджет на локализацию и поддержку.

Когда многоязычный сайт обычно окупается:

• Компания уже уверенно стоит на ногах на домашнем рынке и упирается в потолок по трафику и выручке.
• Есть понятная воронка (лиды, продажи, LTV), а не «ну давайте выведем сайт ещё и туда — вдруг что‑то перепадёт».
• Воронка продаж и саппорт готовы к языковым версиям: есть хотя бы английский, а не «перевели сайт, а заявки обрабатываем через Google Translate».

По опыту, на B2B‑рынках нормальный горизонт выхода новой языковой версии в плюс — от 6 до 18 месяцев, в B2C и e‑commerce при агрессивном маркетинге — быстрее, но только если SEO не делается «по остаточному принципу».

Как поисковики видят многоязычный сайт и зачем им hreflang

Для Google и других поисковиков международный сайт — это не «один большой сайт», а набор версий: по языкам и/или странам. Задача технического SEO — чётко подсказать:

• какая страница для кого (язык и регион);
• какие страницы являются дублями по смыслу, но для разных рынков;
• как не перепутать пользователей и не отдавать французам английскую, а испанцам русскую версию.

Здесь и появляется связка:

• структура URL (поддомены, подпапки, отдельные домены);
• hreflang‑теги (кто с кем связан);
• каноникал (какая версия основная с точки зрения контента).

Hreflang сам по себе не продвигает сайт, он решает две практические задачи:

• показывает правильную языковую/региональную версию пользователю;
• снижает риск, что разные языковые копии будут конкурировать друг с другом как дубликаты.

Если hreflang настроен криво или его нет, вы получаете:

• «поехавшую» выдачу (людям в Германии показывается английская или русская версия);
• каннибализацию: несколько страниц с похожим контентом борются за один и тот же запрос;
• размытие поведенческих сигналов и хуже CTR, потому что язык не совпадает с ожиданиями.

Архитектура многоязычного сайта: на чём не экономить

Перед тем как вообще трогать hreflang, нужно решить архитектуру. Обычно вариантов три:

• Подпапки: site.com/en/, site.com/de/.
• Поддомены: en.site.com, de.site.com.
• Отдельные домены: site.de, site.fr.

Для большинства российских проектов, которые выходят на 2–5 рынков, подпапки — самый управляемый вариант: их проще разворачивать, поддерживать и отслеживать в одном домене. Отдельные домены логичны, когда у вас сильный локальный бренд и реальные юридические/регуляторные различия между странами.

Важно, чтобы:

• в каждой языковой версии была своя полноценная структура (а не «одна главная плюс пара лендингов»);
• URL были предсказуемыми и человекочитаемыми (английский, локализованные слаги или хотя бы без хаоса);
• логика совпадала с бизнесом: если у вас отдельные продуктовые линейки по регионам — это отражаем в структуре, а не прячем под один «международный» раздел.

Hreflang на практике: минимальный набор правил

Если сильно упростить, одна страница в многоязычном SEO должна:

• иметь «сестёр» — версии на других языках/для других регионов;
• знать о них через hreflang и честно их перечислять;
• указывать на себя как на self‑hreflang.

Что важно соблюсти:

• Использовать корректные ISO‑коды языка и страны: ru-RU, en-US, en-GB, de-DE и т.п.
• На каждой версии страницы в <head> указать все остальные версии и саму себя (двусторонние ссылки).
• Для одной комбинации язык + регион должен быть один URL — без дублей.
• Не путать hreflang и атрибут lang в HTML: язык документа и hreflang‑таргетинг должны совпадать по смыслу.
• Все URL из hreflang должны отвечать 200 OK и не редиректить «куда‑то ещё» — иначе поисковик имеет полное право всё это проигнорировать.

Типовой пример разметки для /product/ на трёх языках с единообразным форматом:

• https://example.com/ru/product/ — hreflang=»ru-RU»
• https://example.com/en/product/ — hreflang=»en-US» (или en-GB, если целитесь в Британию)
• https://example.com/de/product/ — hreflang=»de-DE»

Каждая из этих страниц в <head> перечисляет все три версии плюс self‑ссылку. Если вы работаете с глобальной английской версией без привязки к стране, можно использовать просто en, но на практике более точный региональный код даёт лучшее управление таргетингом.

Пару нюансов, о которых часто забывают:

• Для общей страницы «по умолчанию» (например, глобальный лендинг) имеет смысл использовать hreflang=»x-default» — поисковики будут отдавать её тем пользователям, для которых нет отдельной локальной версии.
• Hreflang можно задавать не только в HTML, но и через HTTP‑заголовки (актуально для не‑HTML‑документов вроде PDF) или через XML‑sitemap — это удобно, когда не хочется трогать шаблоны.
• Проверять реализацию стоит не вручную, а инструментами: отчёты Google Search Console по международному таргетингу и специализированные чекеры (Hreflang Tags Checker, краулеры с поддержкой hreflang) довольно быстро ловят разрывы связей и неверные комбинации языка/региона.

Где многоязычное SEO ломается в реальных проектах

1. «Дубли языковых версий» вместо локализации

Классика: ради «международного SEO» делают несколько версий сайта, но переводят только часть страниц, а остальное оставляют на английском. Формально есть /en/, /de/, /fr/, а фактически везде один и тот же английский текст, иногда только с другой валютой.

Чем это заканчивается:

• Google видит несколько URL с почти идентичным контентом и начинает гадать, что показывать;
• разные версии конкурируют за один и тот же запрос;
• hreflang уже не спасает: он объясняет, какая страница для какого рынка, но не превращает дубли в уникальный контент.

Что делать вместо:

• Чётко разделить: где нужен полный перевод, а где достаточно адаптированного лендинга.
• Для ключевых страниц (деньгоносные категории, лид‑магниты, pricing) делать полноценную локализацию: язык, примеры, кейсы, цены, единицы измерения, способы оплаты.
• Не запускать «20 языков сразу», если по факту нормально тянете только 2–3. Лучше меньше, но по‑честному.

2. Hreflang без системы и возвратных ссылок

Частая история — разработчики «как‑то добавили hreflang», но:

• часть страниц не знает о других языковых версиях;
• есть ссылки только в одну сторону;
• для одной комбинации язык+регион прописано несколько URL.

В этом случае поисковик спокойно игнорирует весь ваш hreflang‑набор и живёт по своим правилам.

Мини‑чек‑лист:

• Для каждой URL‑группы (страница + её языковые версии) есть полный набор rel=»alternate» hreflang=»…» на каждой версии.
• Везде есть self‑hreflang (страница ссылается сама на себя).
• Во всех версиях указан один URL для каждой комбинации языка/региона.

3. Конфликт hreflang и canonical

Иногда на многоязычных сайтах canonical ставят на одну основную версию (например, /en/) со всех языков. По сути вы говорите поисковику: «вот эта страница главная, остальные можно не индексировать».

Если при этом вы размечаете hreflang, поисковик получает два противоречивых сигнала:

• hreflang: у нас много языковых версий;
• canonical: индексируй только одну.

В идеале:

• canonical указывает на ту же версию, где стоит (сам на себя);
• hreflang связывает между собой языковые варианты, но не пытается «назначить короля».

4. Перевод только сайта, без экосистемы

Многоязычное SEO не работает в вакууме. Даже идеальный hreflang и структура не спасут, если:

• нет локальных ссылок (PR, каталоги, партнёры) в целевой стране;
• нет локального контента, отвечающего на реальные запросы рынка;
• нет понятной инфраструктуры (поддержка, платежи, логистика) — пользователи уходят, сигналы плохие.

В реальных проектах нормальная картина такая: запуск языковой версии + локализованная контент‑матрица + 2–3 локальных партнёрства/упоминания в первые месяцы.

Практический чек‑лист: как зайти на другой рынок без сюрпризов

Шаг 1. Определяем приоритетные рынки и роли языков

• Пропишите, какие страны для вас деньги, а какие — «побочный трафик».
• Честно ответьте, какие языки команда реально потянет по поддержке.
• Решите, где будет полноценная локализация, а где — только английский.

Шаг 2. Структура и доменная стратегия

• Выберите формат: подпапки / поддомены / отдельные домены.
• Проверьте, что CMS / движок вообще позволяет нормально работать с языками и hreflang.
• Заложите в структуру будущие расширения (чтобы не переделывать всё через год).

Шаг 3. Семантика и контент под каждый язык

• Соберите семантику не через машинный перевод, а через отдельное исследование для каждого языка.
• Не пытайтесь дословно переносить российскую структуру запросов — в других странах по‑другому ищут те же продукты.
• Для ключевых языков заложите редакционный план, а не только «перевод главной и двух лендингов».

Шаг 4. Техническая реализация hreflang

• Определите группы страниц: «одна сущность — несколько языков/регионов».
• Для каждой группы пропишите полный набор hreflang: все версии + self‑ссылки.
• Настройте регулярную проверку: через краулер или собственные скрипты, чтобы ловить дубли и ошибки.

Шаг 5. Мониторинг и корректировка

• Отдельно следите за: индексацией по языковым разделам, CTR в каждой стране, долей отказов и глубиной просмотра.
• Если видите, что пользователям показывается «не тот язык» — проверяйте связку hreflang + геотаргетинг в Search Console/Вебмастере.
• Раз в квартал делайте ревизию: какие языки дают выручку, какие только забирают ресурс на поддержку.

Мини‑кейс: когда hreflang реально спасает

Пример из практики: B2B‑сервис с русской и английской версиями, затем добавили немецкую и испанскую. Сайт построен на подпапках (/ru/, /en/, /de/, /es/), контент частично локализован, но hreflang настроили только между /ru/ и /en/.

Что получили:

• Немецкие пользователи в поиске Google и Bing часто попадали на английские страницы — поведенческие сигналы хуже, чем могли бы быть.
• Для части брендовых запросов выдача «прыгала» между /en/ и /de/, снижается CTR.

После нормальной разметки hreflang между всеми четырьмя языками и лёгкой доработки мета‑тегов:

• доля немецкого трафика на немецкой версии выросла до ~90% показываемых запросов;
• CTR по бренду на DE‑версии вырос примерно на 4–6 п.п. в течение пары месяцев;
• команда перестала ловить жалобы от немцев на англоязычные страницы в выдаче.

Не магия, а базовая гигиена, которая просто была доделана до конца.

Грабли многоязычного SEO и как их обойти

• Ошибка: запускать 5–7 языков сразу «на вырост», без ресурсов на поддержку.
  Вместо этого: начать с 1–2 языков, где уже есть спрос и понятная воронка, и сделать их качественно.
• Ошибка: верить, что hreflang «разрулит» дубли, если вы гоняете один и тот же английский текст по всем странам.
  Вместо этого: использовать hreflang как дополнение к локализации, а не её замену.
• Ошибка: техзадание на многоязычный сайт без отдельного блока про SEO и hreflang — «разработчики сами знают».
  Вместо этого: прописывать требования к структуре, hreflang, canonical, sitemap в ТЗ и проверять на стенде до релиза.
• Ошибка: оценивать успех только по общему трафику.
  Вместо этого: смотреть по странам/языкам, по кластерам, по конверсиям — многоязычное SEO очень легко «красиво смотрится» по сумме, но проваливается по отдельным рынкам.

Что важно вынести из всего этого маркетологу

Многоязычный сайт — это не про «перевести контент» и даже не только про hreflang. Это совокупность решений: где вы реально хотите зарабатывать, какие языки тянет команда, как вы под это настроили структуру, техническую часть и аналитику.

Если резюмировать в три действия:

• сначала думать о рынках и воронке, а уже потом о языках и флагах в шапке;
• не лениться делать нормальную локализацию хотя бы для ключевых страниц, а не крутить один английский текст по всему миру;
• относиться к hreflang как к обязательной «проводке» в многоязычном SEO: без неё всё вроде работает, но до первого короткого замыкания.