Багатомовний сайт і 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, однак латинізовані або англійські слаги в усіх версіях — теж робоча практика, яка спрощує підтримку.