Гайди для власників

Багатомовний сайт і що в ньому дорожчає

Друга мова на сайті рідко коштує стільки, скільки очікує замовник. У кошторисі вона виглядає як переклад текстів, а в роботі виявляється окремою структурою адрес, окремим набором полів у базі, окремим власником контенту й окремою пошуковою стратегією.

Почніть із мовної моделі

Складіть матрицю мов і ринків до того, як хтось намалює перший екран. Мова описує спосіб спілкування, а ринок може змінювати пропозицію, контакти, документи, валюти, правила форми й команду продажів. Одна мова не завжди означає однаковий уміст для всіх регіонів, а одна країна може потребувати кількох мовних версій.

Ця матриця визначає чотири речі одразу, і жодну з них не можна ухвалити після готових макетів.

  • Структуру адрес. Підпапки, піддомени чи окремі домени, і це рішення потім майже не переграється.
  • Поля в системі керування. Які блоки спільні для всіх мов, а які в кожної свої.
  • Ролі редакторів. Хто має право публікувати конкретну мовну версію і хто підтверджує зміст.
  • Набір шаблонів. Скільки сторінок існує в кожній версії і що показувати, якщо відповідника немає.

Мова, країна й ринок

Для кожної версії запишіть аудиторію, ціль, власника й відмінності. Якщо змінюється тільки текст, достатньо мовної версії. Якщо відрізняються послуги, юридичні матеріали, контакти й маршрут заявки, потрібен окремий регіональний шар. Він може жити на тій самій платформі, але має власні правила.

Не визначайте ринок лише за мовою браузера. Людина може працювати в іншій країні, користуватися спільним пристроєм або свідомо читати міжнародну версію. Автоматична підказка допустима, остаточний вибір залишається за відвідувачем і зберігається.

Повні та часткові версії

Повна версія має відповідники для всіх публічних сторінок. Часткова може містити лише ключові послуги, контакти й матеріали для одного ринку. Обидва підходи робочі, якщо межа видима. Небезпечно створювати ілюзію повноти, коли половина посилань непомітно повертає відвідувача на іншу мову.

Для часткової версії заздалегідь визначте поведінку відсутньої сторінки. Можна показати пояснення і посилання на доступний матеріал іншою мовою. Не перенаправляйте будь-який відсутній відповідник на головну: людина втрачає контекст, а пошукова система не бачить рівноцінної сторінки.

Структура адрес

Від цього вибору залежить простота адміністрування, витрати на сертифікати, зручність аналітики й те, з якою історією в пошуку стартує кожна версія. Варіантів три, і вони не рівноцінні.

Критерій Підпапки (/en/) Піддомени (en.) Окремі домени (.de)
Керування і розгортання одна кодова база окремі конфігурації окремі проєкти
Складність підтримки одна панель кілька конфігурацій окремі майданчики
Витрати на домени й сертифікати один і один один домен, ширший сертифікат оплата кожного окремо
Довіра місцевих користувачів висока висока максимальна в країні
Наскрізна аналітика один лічильник один лічильник, потрібна увага до домену cookie складне зведення звітів
  • Підпапки. Збалансований варіант для більшості компаній: нова версія не потребує окремого домену, сертифіката й конфігурації, а всі версії керуються з однієї панелі. Переваги в індексації сам формат не дає: пошуковик прямо каже, що не віддає переваги підпапкам перед піддоменами. На окремі національні домени це не переноситься, бо вони працюють ще й як сигнал країни.
  • Піддомени. Мають сенс, коли версії суттєво різняться структурою, живуть на різних серверах або ближче до свого регіону. Пошукові системи бачать їх як окремі ресурси.
  • Окремі національні домени. Максимальна довіра в конкретній країні й найточніше націлювання, але кожен домен доводиться просувати як новий проєкт із нульовою історією.

Розмітка hreflang і карти сайту

Пошуковий робот має однозначно розуміти, яку мовну версію показати відвідувачеві. Для цього сторінки посилаються одна на одну спеціальними тегами, і головне правило тут взаємність.

Якщо сторінка однією мовою посилається на відповідник іншою, зворотне посилання обов’язкове. Плюс кожна сторінка посилається сама на себе. Порушена взаємність хоча б на одній адресі означає, що робот проігнорує розмітку для всієї пари. На практиці ламається це в трьох місцях.

  • Сторінка забула про себе. Посилання на власну мовну версію пропускають найчастіше, а без нього набір неповний.
  • Одна сторона оновилася, друга ні. Адресу змінили в одній мові, і зв’язка розпалася мовчки, без жодної помилки у звітах.
  • У наборі є сторінка, якої вже немає. Тег указує на видалену адресу, і робот ігнорує саме цю зв’язку. Решта взаємних пар продовжує працювати, але мова, на яку вказував битий тег, залишається без пари.

Крім взаємності, перед запуском перевіряють ще чотири речі.

  • Резервна версія. Окремий тег указує, куди вести людину, чиї мовні налаштування не збіглися з жодною локалізацією. Зазвичай це міжнародна англійська.
  • Абсолютні адреси. Google приймає в тегах тільки повні адреси з протоколом, наприклад https://, відносний шлях не спрацює. Адресу з редиректом краще не ставити, тег має вести одразу на кінцеву сторінку з кодом 200.
  • Коди мов за стандартом. Довільні скорочення на кшталт «ua» замість «uk» ламають розпізнавання.
  • Окремі карти сайту на мову. Індексний файл із посиланнями на карту кожної версії зручніший за один великий файл: видно динаміку індексації кожної гілки окремо.

Що збільшує обсяг робіт

Замовники часто сприймають багатомовність як копіювання текстів у нові рядки бази. Насправді кожна додаткова мова ускладнює архітектуру, інтерфейс і процеси підтримки, і саме це формує підсумкову вартість розробки сайту.

Різна довжина тієї самої фрази

Одна й та сама думка різними мовами займає різну ширину. Німецькі та французькі терміни помітно довші за англійські відповідники, і це ламає верстку там, де її робили під одну мову.

  • Кнопки. Напис виходить за межі або переноситься на два рядки, зсуваючи все нижче.
  • Навігація. Пункти меню не вміщаються в один ряд і стрибають на другий на середніх екранах.
  • Картки й таблиці. Висота елементів у ряду перестає збігатися, сітка виглядає нерівною.
  • Формати даних. Дати, валюти, роздільники дробів і маски телефонів різняться від ринку до ринку.

Для мов із написанням справа наліво потрібна дзеркальна перебудова макета: розташування логотипа, напрямок іконок, порядок списків. Це окремий етап роботи зі стилями, а не налаштування.

Архітектура даних

Кожен динамічний елемент отримує зв’язок із мовним ідентифікатором: заголовки, текстові блоки, метадані, атрибути зображень, повідомлення форм, назви категорій, юридичні документи. Зі зростанням числа мов зростає і кількість запитів до бази, тому переклади зберігають модульно, а часті запити кешують.

Сайт, спроєктований модульно з самого початку, дозволяє додати третю і четверту мову без переписування коду. Сайт, до якого другу мову додали вже після запуску, зазвичай доводиться переробляти на рівні шаблонів.

Хто володіє контентом

Переклад без власника швидко застаріває. Для кожної мови потрібна людина або роль, яка підтверджує зміст, термінологію, контакти й локальні винятки. Перекладач відповідає за мовну якість, але не може вирішити, чи доступна послуга на ринку і який відділ отримує заявку.

Джерело оригіналу

Визначте, яка версія запускає зміну: одна базова мова або окремі ринкові редакції. Коли редактор змінює джерело, пов’язані сторінки отримують статус «потребує перевірки». Система не повинна мовчки копіювати текст у поля інших мов або вважати їх актуальними.

Не кожна зміна потребує нового перекладу. Виправлення пробілу не має блокувати публікацію, а нова умова послуги має. Короткий коментар до зміни й позначка, яких блоків вона стосується, позбавляють потреби перечитувати всю сторінку.

Статуси перекладу

Робочий цикл містить чернетку, готовність до перекладу, переклад, редактуру, перевірку в макеті та публікацію. Сторінка не переходить у публікацію тільки тому, що всі поля непорожні.

Потрібен звіт про пропуски: неперекладене меню, кнопка, повідомлення форми, альтернативний опис, метадані чи документ. Ручна перевірка доповнює автоматичну, бо поле може бути формально заповнене старою або неправильною версією тексту.

Локальні винятки

Локалізація змінює не лише слова. Відрізнятися можуть приклади, формат дат, контакти, юридичні повідомлення, порядок полів у формі й перелік доступних послуг. Такі поля відділяють від спільних, щоб загальне оновлення не перезаписало погоджений виняток.

Ведіть реєстр винятків із причиною та власником. Без нього команда не розуміє, чи відмінність навмисна, чи сторінку просто забули оновити. Під час редизайну цей реєстр рятує локальні рішення від випадкового зникнення.

Машинний переклад і редактура

Для первинного наповнення великих розділів машинний переклад економить час. Залишати його без вичитки не варто, особливо там, де читач ухвалює рішення про співпрацю.

  • Чернетка машиною. Модуль створює первинну копію сторінки цільовою мовою.
  • Вичитка носієм. Перекладач виправляє галузеву термінологію і стилістику, а не лише граматику.
  • Технічна перевірка. Редактор дивиться форматування, внутрішні посилання і наявність медіафайлів.
  • Публікація. Контент-менеджер відкриває сторінку й активує перемикач для відвідувачів.

Такий порядок швидший за переклад з нуля і не залишає в тексті машинних зворотів, які іноземний читач помічає з першого абзацу.

Пошукова оптимізація кожної версії

Автоматичний переклад сам собою органічного трафіку з інших країн не дає. Кожна мовна гілка оптимізується як самостійний проєкт.

Люди в різних регіонах шукають ті самі послуги різними словами. Буквальний переклад ключових фраз часто дає нульовий результат просто тому, що цільова аудиторія формулює запит інакше.

  • Власна семантика на кожну мову. Збирається окремо, за місцевими даними, а не перекладом наявного списку.
  • Унікальні заголовки й описи. Побудовані на місцевих запитах, а не на перекладі наявних.
  • Адреси словами мови аудиторії. Для кириличних версій це зазвичай транслітерація, Google прямо її допускає, а кирилиця в адресі під час копіювання перетворюється на довгий закодований рядок.
  • Перекладена розмітка. Назви організації, послуг і навігаційних ланцюжків мають бути мовою сторінки.

Про те, які взагалі розділи потрібні корпоративному сайту й у якому порядку, є окремий розбір структури корпоративного сайту.

Типові помилки

Примусове перенаправлення за геолокацією

Спроба автоматично кинути відвідувача на версію за його адресою в мережі шкодить одразу двом сторонам. Людина може бути у відрядженні або свідомо читати міжнародну версію. Більшість запитів робота Google надходить зі США, тому жорстке перенаправлення може сховати від нього інші мовні версії, і тоді вони не потраплять в індекс.

Робочий стандарт інший: ненав’язливе повідомлення з пропозицією змінити мову й вільний вибір у перемикачі.

Змішаний уміст

Відвідувач перейшов на англійську версію, а підписи полів у формі, тексти кнопок і повідомлення про помилку залишилися іншою мовою. Для іноземного замовника це виглядає як технічний брак і привід закрити вкладку.

Перед релізом мовної версії проходять увесь ланцюжок цілком.

  • Меню і кнопки. Включно з тими, що з’являються лише після дії: «показати ще», «згорнути», «надіслати».
  • Поля форми й підказки. Плейсхолдери й тексти під полями забувають частіше за самі підписи.
  • Повідомлення про помилку. Заповніть форму неправильно навмисно й подивіться, якою мовою вона відповість.
  • Лист після відправлення. Він приходить із шаблону, який до мовних версій часто не прив’язаний узагалі.

Перемикач, у який важко влучити

На телефоні перемикач іноді ховають у підменю або роблять настільки дрібним, що в нього не потрапити пальцем. Він має залишатися на видному місці в шапці, поруч із кнопкою меню. Позначати мови краще літерами, а не прапорами: однією мовою говорять у десятках країн, і прапор тут вводить в оману.

Чек-лист перед відкриттям мовної версії

  • Взаємність тегів. Перехресні посилання є на всіх сторінках пари, включно з посиланням на саму себе.
  • Абсолютні шляхи. Усі теги містять повну адресу без проміжних редиректів.
  • Форми працюють. Тестова заявка з кожної мовної версії дійшла, тексти помилок перекладені.
  • Обов’язкові сторінки перекладені. Контакти, реквізити, сторінка помилки й політика конфіденційності.
  • Індексація відкрита. Нові шляхи не закриті в robots.txt, карти сайту містять лише канонічні адреси.
  • Аналітика розділена. Відвідувачі й цілі сегментовані за мовними гілками, інакше оцінити віддачу неможливо.

Висновки

Багатомовний сайт дорожчає не через переклад, а через усе, що навколо нього: структуру адрес, поля в базі, ролі редакторів, окрему семантику й окремий процес оновлення.

Рішення, яке визначає бюджет, ухвалюється до прототипів. Це матриця мов і ринків: чи змінюється тільки текст, чи разом з ним послуги, контакти й маршрут заявки. Перше коштує як мовна версія, друге як другий сайт на спільній платформі.

Якщо ви плануєте вихід на новий ринок, надішліть нам перелік мов і опишіть, що в кожній версії буде відрізнятися крім тексту. Ми складемо матрицю, покажемо, де проходить межа між мовною версією і регіональним шаром, і назвемо вартість обох варіантів окремо. Буває, що на старті достатньо часткової версії з кількома ключовими сторінками, і тоді рахуємо тільки її. Повний багатомовний сайт беремо в межах розробки корпоративних сайтів. Тариф з унікальним дизайном і структурою під ваші послуги коштує від $2 000 до $3 000, і друга мовна версія входить у цю суму. Якщо ваша компанія працює за кордоном, порядок роботи, оплат і доступів описаний у розборі роботи української студії з іноземним замовником.

Залишилися запитання?

Залиште заявку, і ми зв’яжемося з вами найближчим часом

    Зручний спосіб зв’язку:
    *Обов’язкове поле для заповнення
    Натискаючи кнопку, ви підтверджуєте, що ознайомилися з Політикою конфіденційності