Багатомовний сайт: структура URL, hreflang і типові помилки
Підпапки чи піддомени, як налаштувати hreflang без конфліктів, що робити з мовою за замовчуванням і чому автопереклад шкодить позиціям.
Компанія додає англійську версію сайту, а через місяць бачить у Search Console дивну картину: україномовні сторінки показуються британцям, англомовні — киянам, а половина нових адрес узагалі не потрапила в індекс. Переклад тут ні до чого. Ламається майже завжди одне й те саме — структура URL, взаємні hreflang-посилання й «розумний» редирект за мовою браузера. Нижче: як обрати структуру адрес, як налаштувати hreflang, щоб він не конфліктував сам із собою, скільки реально коштує друга мова і які помилки з’їдають місяці індексації.
+20%
до бюджету розробки на кожну нову мову
2–8
тижнів до повної індексації другої версії
100%
сторінок мають взаємні hreflang-посилання
0
автоматичних редиректів за мовою браузера
Підпапки, піддомени чи окремі домени
Це рішення ухвалюють один раз і живуть із ним роками: зміна структури адрес пізніше — це повноцінна міграція з тимчасовим просіданням позицій. Тому обирати структуру треба до дизайну, а не після запуску.
| Варіант | Приклад | Сильна сторона | Ціна рішення |
|---|---|---|---|
| Підпапки | site.com/uk/, site.com/en/ | Уся авторитетність накопичується на одному домені | Практично немає — це базовий вибір |
| Піддомени | uk.site.com, en.site.com | Версії легко рознести по різних серверах і командах | Пошукові сигнали накопичуються окремо для кожного |
| Окремі домени | site.ua, site.de | Найсильніший локальний сигнал і окремий бренд | Три сайти замість одного: SSL, хостинг, посилання, підтримка |
| Параметр у посиланні | site.com/page?lang=en | Швидко прикрутити до старого сайту | Погано індексується, ламає кеш і звіти — не використовуйте |
За замовчуванням беріть підпапки. Окремі домени виправдані рівно у двох випадках: у вас є юридична особа в кожній країні або ринки настільки різні, що це фактично різні бізнеси з різними цінами й асортиментом. Піддомени — компроміс для великих компаній, де кожним ринком опікується власна команда. Якщо ви плануєте не просто мови, а й регіони (британська та американська англійська, наприклад), закладайте формат /en-gb/ одразу: додати регіон до наявного /en/ пізніше означає редиректи на кожній сторінці, і це вже сценарій із чекліста SEO-міграції.
hreflang: що це насправді і як його не зламати
hreflang не впливає на позиції. Він вирішує лише одну задачу: коли Google уже має кілька версій однієї сторінки, підказати, яку з них показати конкретному користувачеві. Виглядає розмітка так — у <head> кожної мовної версії однієї й тієї самої сторінки:
<link rel="alternate" hreflang="uk" href="https://site.com/uk/services" />
<link rel="alternate" hreflang="en" href="https://site.com/en/services" />
<link rel="alternate" hreflang="de-at" href="https://site.com/de-at/services" />
<link rel="alternate" hreflang="x-default" href="https://site.com/en/services" />
<link rel="canonical" href="https://site.com/uk/services" />- 1Взаємність обов’язкова. Якщо сторінка A вказує на B, то B має вказувати на A. Односторонні зв’язки Google просто ігнорує — цілком, а не частково.
- 2Самопосилання теж обов’язкове. Кожна сторінка перелічує всі версії, включно з собою. Без цього набір вважається неповним.
- 3Тільки абсолютні URL з протоколом і доменом. Відносні шляхи не працюють.
- 4Коди пишуться суворо: мова за ISO 639-1, регіон за ISO 3166-1 через дефіс.
en-gb, а неen-uk(такого коду не існує) і неen_GB. - 5hreflang веде на canonical. Якщо сторінка
/en/servicesканонізована на/en/service, а hreflang вказує на/en/services, увесь набір анулюється. - 6Один спосіб на сайт.
<head>, XML-мапа сайту або HTTP-заголовки — щось одне. Дві реалізації одночасно рано чи пізно розійдуться між собою.
Мова за замовчуванням і пастка автоматичного редиректу
Найдорожча помилка в багатомовних проєктах — редирект за IP або заголовком Accept-Language. Логіка виглядає турботливою: визначили німця, показали німецьку. На практиці Googlebot сканує переважно з американських адрес, тобто бачить лише англійську версію, а решту вважає недоступною. Ви отримуєте сайт, у якому проіндексована одна мова з чотирьох, і місяці на з’ясування, чому.
- Пропонуйте, а не примушуйте. Визначили мову — покажіть неблокуючий банер «Ця сторінка доступна українською», а не 302-й редирект.
- Запам’ятовуйте вибір у cookie і поважайте його: людина, яка один раз перемкнулась на англійську, не має бачити банер щовізиту.
- Мовний перемикач веде на ту саму сторінку іншою мовою. Перемикач, який завжди кидає на головну, — найпоширеніша UX-помилка в цій темі й пряма причина відмов.
- Кореневий `/` має вести кудись конкретно. Або 301 на основну мову, або окрема сторінка вибору. Порожній корінь із JavaScript-редиректом ботам не читається.
- `x-default` ставте на версію для «всіх інших»: зазвичай англійську або сторінку вибору мови. Якщо у вас лише дві локальні мови й міжнародного трафіку не очікується,
x-defaultможна не додавати — це не помилка.
Переклад, локалізація і чому машинний текст «як є» не працює
Google не карає за машинний переклад сам по собі — карає за сторінки без цінності. Проблема автоперекладу інша й тонша: він точно передає ваші слова і повністю промахується повз слова, якими шукає ринок. Дослівний переклад української сторінки «створення сайтів» англійською дасть заголовок, який просто ніхто не набирає в пошуку.
Переклад сторінки — це ще не локалізація. Локалізація починається там, де ви заново збираєте семантику мовою ринку, у який заходите.
Тому послідовність така: спочатку окреме дослідження ключових слів для нової мови, потім карта сторінок під ці запити — і лише потім тексти. Іноді виявляється, що структура англійської версії має відрізнятися від української: якісь сторінки зайві, а якісь треба додати. Це нормально й набагато дешевше, ніж перекладати те, чого ніхто не шукає. Машинний переклад як чернетку використовувати можна — за умови, що людина після нього переписує заголовки, підзаголовки й усе, що бачить пошук.
Локалізується, а не перекладається дослівно
- Title і description — під запити цільової мови, з урахуванням обмеження на довжину
- Слаги в URL — латиницею й осмислено:
/en/services/, а не транслітерація кирилиці - Валюта, формат дати, розділювач тисяч, маска телефону
- Юридичні сторінки: політика конфіденційності, умови оплати й доставки
- Alt-тексти зображень і будь-який текст, вбудований у самі картинки
- Структуровані дані: назви, ціни, код валюти, регіон обслуговування
- Тексти інтерфейсу: помилки валідації, підтвердження форми, автовідповіді на пошту
- Кейси й відгуки — клієнту з іншого ринку потрібні релевантні йому приклади
Скільки коштує друга мова і як не подвоїти підтримку
Головний ризик мультимовності не в грошах на старті, а в тому, що ви назавжди подвоюєте роботу редактора. Уникнути цього можна тільки архітектурою: один сайт із мовним шаром, а не два сайти під спільним доменом.
- 1
Одна контент-модель на всі мови
У CMS сутність «сторінка» має мовні поля, а не окреме дерево на кожну мову. Інакше через рік структури розійдуться, і ви матимете сторінки, які існують лише однією мовою без пари в hreflang.
- 2
Тексти інтерфейсу — у словниках
Кнопки, підписи, помилки виносяться у файли перекладів і ніколи не пишуться в компонентах. Додати третю мову тоді — це новий файл, а не переписування шаблонів.
- 3
Мапа сайту генерується автоматично
hreflang у sitemap.xml має збиратися з даних під час білду. Рукописний XML на 200 сторінок × 3 мови розсинхронізується з першою ж публікацією.
- 4
Спочатку одна мова до релізного стану
Запускати обидві версії одночасно й напівготовими — гірше, ніж запустити одну повністю. Друга мова з порожніми сторінками тягне вниз оцінку якості всього домену.
- 5
Технічна перевірка перед відкриттям індексації
Взаємність hreflang, canonical, відсутність гео-редиректів,
langв атрибуті<html>. Це стандартні пункти технічного SEO-аудиту, і зробити їх до релізу дешевше, ніж після.
| Стаття витрат | Разово | Регулярно |
|---|---|---|
| Мовний шар, маршрутизація, hreflang, sitemap | +15–25% до вартості розробки | — |
| Переклад і адаптація текстів | $8–20 за 1000 знаків | Залежить від обсягу новин і кейсів |
| Локалізація метатегів, слагів, розмітки | $5–15 за сторінку | — |
| Ведення двох версій контенту | — | +30–50% до часу редактора |
Часті питання про багатомовні сайти
Підпапки чи піддомени для мовних версій сайту?
Для переважної більшості бізнесів правильна відповідь — підпапки виду site.com/en/. Уся авторитетність домену, зовнішні посилання й технічні налаштування залишаються спільними, а адміністрування ведеться в одному місці. Піддомени й окремі національні домени виправдані тоді, коли на кожному ринку працює окрема юридична особа або окрема команда з власним асортиментом і цінами.
Чи вважається багатомовний сайт дублікатом контенту?
Ні. Той самий текст різними мовами дублікатом не є, і жодних санкцій за це немає. Проблема виникає тільки тоді, коли одна й та сама мова дублюється на кількох адресах — наприклад, англійська для Великої Британії та США з ідентичним текстом. У цьому випадку допомагають коректні hreflang із регіональними кодами та canonical на основну версію.
Скільки часу потрібно, щоб нова мовна версія почала давати трафік?
Індексація зазвичай займає від двох до восьми тижнів залежно від того, наскільки авторитетний домен і чи є на новий розділ внутрішні посилання. Перші позиції за низькочастотними запитами з’являються за два-три місяці, помітний трафік — ближче до пів року. Прискорити це можна мапою сайту, посиланнями з наявних сторінок і зовнішніми згадками на новому ринку.
Чи можна публікувати автоматичний переклад без редактури?
Технічно можна, і прямої заборони немає, але результат зазвичай не приносить трафіку. Автоматика перекладає ваші формулювання, а не формулювання, якими шукає ринок, тому заголовки й метаописи промахуються повз реальний попит. Робочий компроміс — машинний переклад як чернетка тіла тексту плюс ручна робота над заголовками, метатегами, слагами й закликами до дії.
Що робити з мовою за замовчуванням на головній сторінці?
Корінь сайту має або віддавати конкретну мовну версію постійним 301-редиректом, або бути окремою сторінкою вибору мови. Чого точно робити не варто — переадресовувати за IP-адресою чи мовою браузера: пошукові роботи сканують переважно з одного регіону й через це просто не побачать решту версій. Визначення мови допустиме лише як ненав’язлива пропозиція перемкнутись, яку користувач може закрити.
Коротко
- Підпапки — базовий вибір структури. Піддомени й окремі домени виправдані лише окремими юрособами чи командами на кожному ринку.
- hreflang має бути взаємним, із самопосиланням, абсолютними URL і одним-єдиним способом реалізації.
- Автоматичний редирект за IP чи мовою браузера ховає більшість версій від пошукових роботів. Пропонуйте мову банером і запам’ятовуйте вибір.
- Друга мова — це не переклад, а окрема семантика, свої метатеги, слаги й структура сторінок.
- Закладайте +15–25% до розробки разово і +30–50% до роботи редактора постійно.
Схожі матеріали
Технічний SEO-аудит: що перевіряти і в якому порядку
Технічні помилки коштують позицій тихо. Порядок аудиту, який ловить найдорожчі з них першими.
Переїзд сайту без втрати позицій: чекліст міграції
Найбільші провали трафіку трапляються не від алгоритмів Google, а від запуску нової версії сайту.
Етапи розробки сайту: що відбувається і скільки триває
Проєкти зриваються не в коді, а на узгодженнях. Показуємо весь шлях і де саме він гальмує.