Мультиязычный сайт и SEO: hreflang, структура URL, ошибки

Зачем разделять языковые версии сайта

Поисковые системы индексируют не «сайты» и не «языки», а конкретные URL. Если русский, английский и украинский текст живут по одному адресу и подменяются скриптом, для Google это одна страница с одним содержимым — тем, которое отдал сервер. Ранжироваться по запросам на трёх языках один URL не может: у него один title, один сниппет, один язык контента.

Раздельные языковые версии решают сразу несколько задач:

Отдельная индексация. Каждая версия — самостоятельный документ со своим title, description и текстом, который накапливает релевантность по запросам на своём языке.
Правильные сниппеты. Пользователь из англоязычной выдачи видит английский заголовок и описание, а не русское.
Новая семантика. Каждый язык — отдельный пласт запросов, по которым сайт раньше не показывался вовсе.

Поэтому первый шаг мультиязычного SEO — не перевод текстов, а архитектура: каждой языковой версии свой URL.

Структура URL: поддиректории, поддомены, ccTLD или ?lang=

Есть четыре распространённых способа развести языки по адресам, и они не равнозначны.

Поддиректории (site.com/en/, site.com/uk/). Все версии живут на одном домене и наследуют его авторитет: ссылки, возраст, историю. Для большинства проектов это оптимальный вариант.
Поддомены (en.site.com). Поисковики склонны рассматривать поддомены как частично самостоятельные сайты, поэтому ссылочный вес делится. Оправданы, когда версии — технически разные продукты: другая CMS, другая команда.
ccTLD (site.de, site.fr). Самый сильный гео-сигнал и максимум доверия локальной аудитории, но каждый домен раскачивается с нуля: свой ссылочный профиль, свой бюджет, свои риски.
GET-параметр (?lang=en). Худший вариант: параметры часто склеиваются canonical-ом, легко наплодить дублей, а адрес не сообщает о языке ни пользователю, ни краулеру.

Наша рекомендация по умолчанию — поддиректории: лучший баланс SEO-эффекта и стоимости поддержки. Примеры реализации есть в портфолио студии.

Клиентский JS-перевод против запечённого HTML

Частая ошибка — «сделать мультиязычность» словарём на JavaScript: страница загружается на основном языке, а скрипт подменяет строки после выбора языка. С точки зрения SEO такой сайт остаётся одноязычным.

Причин несколько. Во-первых, если все языки живут на одном URL, отдельной индексации не будет в принципе. Во-вторых, контент, который появляется только после исполнения JS, индексируется медленнее и менее надёжно: рендеринг у Google — отложенный и ресурсоёмкий этап, а многие другие краулеры (боты соцсетей, LLM-краулеры) JavaScript не исполняют вовсе.

Правильное решение — пре-рендер, или «запечённый» перевод: переводы подставляются в шаблоны на этапе сборки или на сервере, и по каждому языковому URL отдаётся готовый HTML на нужном языке — с переведёнными title, description и атрибутом lang.

По этой схеме мы собрали и сайт нашей студии, и мультиязычный фриланс-маркетплейс 24freelance: три языка, раздельные /en/ и /uk/, и в каждом ответе сервера — полностью переведённая разметка.

hreflang: как правильно связать языковые версии

Атрибут hreflang сообщает поисковику, что группа URL — одна и та же страница на разных языках, и помогает показывать в выдаче нужную версию. Разместить аннотации можно тремя способами: тегами <link rel="alternate" hreflang="…"> в <head>, HTTP-заголовком или в sitemap.

Ключевые правила:

Взаимность. Если русская страница ссылается на английскую, английская обязана ссылаться на русскую. Односторонние аннотации игнорируются.
Самоссылка. Каждая страница включает hreflang и на саму себя — без этого кластер считается неполным.
x-default. Отдельная аннотация для версии «по умолчанию», которую стоит показывать аудитории, не подходящей ни под один из языков. Обычно это главная версия сайта или страница выбора языка.
Корректные коды. Язык — по ISO 639-1, регион (опционально) — по ISO 3166-1 Alpha-2: ru, en, uk или en-GB, pt-BR. Код украинского языка — именно uk, а не ua: UA — код страны, в языковой части он невалиден.
Абсолютные URL — с протоколом и доменом.

И помните: аннотации нужны на каждой переведённой странице, а не только на главной.

Типовые ошибки hreflang

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

Нет обратных ссылок. Страница A ссылается на B, но B не ссылается на A — пара аннотаций не работает.
Неверные коды. en-UK вместо en-GB, ua вместо uk, выдуманные регионы. Невалидный код — проигнорированная аннотация.
hreflang на редиректы и 404. Все URL кластера должны отвечать 200; ссылка на редирект или ошибку разрывает кластер.
Конфликт с noindex и canonical. Страница, закрытая от индексации или канонизированная на другой URL, участвовать в кластере не может.
Все версии ссылаются на главную. Альтернатива англоязычной статьи — та же статья на других языках, а не корень сайта.
«Альтернативы» с разным содержимым. hreflang связывает переводы одной страницы; связывать разные по смыслу страницы нельзя.

Проверяйте аннотации инструментами: Search Console и любой SEO-краулер находят битые пары за минуты.

Canonical на языковых версиях

Canonical и hreflang решают разные задачи: canonical склеивает дубли одной и той же страницы, hreflang связывает разные страницы-переводы. Переводы — не дубли, поэтому правило простое: каждая языковая версия указывает canonical на саму себя.

Самая разрушительная ошибка мультиязычных сайтов — canonical со всех языков на «основную» версию: например, с /en/services.html и /uk/services.html на русскую /services.html. Такой тег прямо говорит поисковику «не индексируй переводы», и они выпадают из выдачи, сколько бы hreflang вы ни прописали. В конфликте сигналов Google обычно верит canonical.

Практические правила: canonical — абсолютный и самоссылающийся на каждой языковой версии; hreflang ссылается только на канонические URL (без параметров и лишних вариантов).

Sitemap с xhtml:link: все alternates в одном месте

Прописывать hreflang можно не в <head>, а прямо в карте сайта — через расширение xhtml:link. Для каждого <url> перечисляются все его языковые альтернативы, включая сам URL:

<url><loc>https://site.com/en/page.html</loc> <xhtml:link rel="alternate" hreflang="en" href="https://site.com/en/page.html"/> <xhtml:link rel="alternate" hreflang="ru" href="https://site.com/page.html"/> <xhtml:link rel="alternate" hreflang="x-default" href="https://site.com/page.html"/></url>

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

Требования те же, что и для тегов в head: взаимность, самоссылка, абсолютные URL, статус 200. И не забудьте объявить пространство имён xhtml в корневом теге <urlset>, иначе файл не пройдёт валидацию.

Перевод мета-тегов, Open Graph и разметки

Перевести «видимый» контент — половина работы. Языковую версию выдают мелочи, и именно они чаще всего остаются непереведёнными:

Title и description. Формируют сниппет и CTR. Их не переводят «в лоб», а переписывают под запросы конкретного языка.
Атрибут lang на <html>. Помогает поисковикам, скринридерам и браузерным переводчикам корректно определить язык документа.
Open Graph и Twitter Cards. og:title, og:description и og:locale должны соответствовать языку страницы, иначе шеринг в соцсетях покажет заголовок на чужом языке. Для остальных версий есть og:locale:alternate.
Структурированные данные. Тексты в JSON-LD — название организации, описания, вопросы FAQ — тоже переводятся: расширенные сниппеты собираются из них.
Alt-тексты, кнопки, страницы ошибок, письма форм. Прямо на ранжирование не влияют, но «полупереведённый» сайт теряет доверие пользователей.

Язык по умолчанию и автредиректы по geo и Accept-Language

Какой язык отдавать на корне сайта? Обычно — язык основной аудитории, а остальные версии выносятся в /en/ и /uk/. Корневую версию логично объявить и как x-default.

Опасный соблазн — автоматически редиректить посетителя на «его» версию по IP-геолокации или заголовку Accept-Language. Почему мы не рекомендуем так делать:

Googlebot сканирует преимущественно с американских IP. Сайт с гео-редиректом будет упорно отправлять его на английскую версию, и остальные языки рискуют остаться недосканированными.
Редирект ломает прямые ссылки: человек делится украинской страницей, а получатель из другой страны попадает на английскую.

Дружелюбная альтернатива — ненавязчивый баннер «Похоже, вам удобнее версия на…» с запоминанием выбора. И обязательно: переключатель языков — это обычные краулябельные ссылки <a href> на ту же страницу в другой версии, а не JS-меню без ссылок и не ссылка на чужую главную.

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

Технически безупречная мультиязычность не спасёт слабый перевод. Поисковики прямо предупреждают: автоматически переведённый контент без редактуры и добавленной ценности может расцениваться как масштабируемый спам.

Рабочая схема для большинства проектов — гибрид: машинный или LLM-перевод как черновик, затем вычитка человеком, который владеет языком и понимает предметную область. Отдельного внимания требуют:

Терминология. Единый глоссарий на все страницы: если «заказ» в интерфейсе, статьях и письмах переведён тремя разными словами, доверие падает.
Русско-украинская пара. Близость языков обманчива: сырой машинный перевод выглядит правдоподобно, но полон калек и смешанных форм. Классика ложных друзей: украинское «неділя» — это воскресенье, а не неделя («тиждень»).
Семантика, а не перевод ключей. Запросы не переводятся — они собираются заново под каждый язык: одну и ту же потребность в разных языках формулируют по-разному.

Чек-лист внедрения мультиязычности

Сводный список для запуска или аудита мультиязычного сайта:

Выбрана структура URL; у каждой языковой версии — собственный адрес.
Контент отдаётся сервером в готовом HTML: пре-рендер или SSR, без клиентской подмены строк.
На <html> каждой версии — корректный атрибут lang.
hreflang: полный кластер на каждой странице — самоссылка, взаимность, x-default, валидные коды (uk, а не ua).
Canonical на каждой версии — самоссылающийся; никаких canonical на «основной» язык.
Sitemap перечисляет все версии; при необходимости — с xhtml:link alternates.
Title, description, OG-теги, JSON-LD и alt-тексты переведены и адаптированы.
Переключатель языков — обычные ссылки на эквивалентную страницу, а не на главную.
Автредиректов по geo/Accept-Language нет; вместо них — баннер-подсказка.
Перевод вычитан носителем; семантика собрана отдельно для каждого языка.

Если нужен мультиязычный сайт «под ключ» — от архитектуры URL до запечённого перевода, как в кейсе 24freelance, — посмотрите услуги студии и напишите нам: обсудим проект и предложим схему под ваши языки и рынки.

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

С какого количества языков стоит начинать?

С тех, где у вас реально есть аудитория и спрос: обычно это два-три языка. Каждая версия требует перевода, вычитки и поддержки, поэтому лучше запустить два языка безупречно, чем шесть — наполовину.

Можно ли обойтись виджетом автоперевода вроде Google Translate?

Для удобства случайного посетителя — да, для SEO — нет. Виджет переводит страницу в браузере пользователя: у переводов нет собственных URL, они не индексируются и не приводят трафик из поиска. Поисковый эффект дают только отдельные языковые версии, отдаваемые сервером в готовом HTML.

Где размещать hreflang — в head или в sitemap?

Оба способа для Google равнозначны, выбирайте один и придерживайтесь его. Для больших сайтов удобнее sitemap — аннотации генерируются и валидируются централизованно; для небольших — теги в head, их проще проверить на конкретной странице.

Что такое x-default и обязателен ли он?

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

Просядут ли позиции основной версии после запуска переводов?

При корректной реализации — нет. Переводы не конкурируют с оригиналом: они ранжируются по запросам на своих языках, а hreflang прямо сообщает поисковику, что это связанные версии одной страницы. Риск возникает только при ошибках — например, canonical с переводов на оригинал.

Нужно ли переводить сами URL (слаги)?

Желательно, но не критично. Переведённый слаг читабельнее в выдаче и может немного улучшить CTR, однако латинизированные или английские слаги во всех версиях — тоже рабочая практика, которая упрощает поддержку.