Просування в англомовних регіонах

Найчастіше розмова про вихід на англомовний ринок починається так: «У нас уже є англійська версія, але з неї немає ні трафіку, ні заявок». Відкриваємо сайт — і бачимо знайому картину. Тексти прогнані через перекладач і ніхто їх не вичитував, ціни в гривнях, телефон без міжнародного коду, половина сторінок англійською, а половина — досі українською. Адреси англійських сторінок змішані з основними, а пошукова система не розуміє, яку версію кому показувати. Іноді така «версія» ще й тягне вниз основний сайт: з’являються дублі, плутаються канонічні адреси, падає видимість у рідному регіоні.

Ми в WebTerra не раз запускали й перебудовували мовні версії для магазинів, виробників і сервісних компаній, які продають у США, Великій Британії, Канаді, Австралії та Ірландії. У цій статті — наш робочий підхід: як обрати між локальними доменами й підпапками, як правильно налаштувати hreflang, чому переклад і локалізація — це різні бюджети, як працювати з носіями мови та що зробити, щоб нова версія допомагала бізнесу, а не шкодила тому, що вже працює.

Англомовний ринок — це не один ринок

Перша помилка закладається ще на етапі ідеї: «зробимо англійську версію — і вона працюватиме на весь світ». Але американський, британський і австралійський покупці шукають по-різному. Різниться лексика (apartment і flat, sneakers і trainers), правопис (color і colour, optimize і optimise), валюта, одиниці виміру, формат дат, способи оплати й очікування щодо доставки. Різняться й конкуренти у видачі: за тим самим запитом у Google.com і Google.co.uk ви побачите різні сайти.

Тому перш ніж щось перекладати, ми відповідаємо з клієнтом на три запитання:

1. Де реально є продажі або попит? Дивимося на статистику замовлень, звіти Search Console за країнами, запити, які вже приходять від іноземних клієнтів.
2. Чи відрізняється пропозиція між країнами? Якщо ціни, доставка й асортимент однакові, часто вистачає однієї версії англійською. Якщо різні — потрібні окремі регіональні версії.
3. Скільки ресурсу є на підтримку? Кожна версія — це не разовий переклад, а постійна робота: нові товари, акції, блог, відповіді клієнтам. Три версії, які ніхто не оновлює, гірші за одну живу.

У більшості наших проєктів ми стартуємо з однієї версії англійською для всіх англомовних країн, а регіональні (наприклад, окремо для США й Великої Британії) додаємо тоді, коли аналітика показує стабільний попит і різницю в умовах продажу. Особливості ринку США ми детально розібрали в статті «Просування сайту в США».

Домен, піддомен чи підпапка

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

Схема	Приклад	Плюси	Мінуси
Локальний домен (ccTLD)	example.co.uk	Найсильніший сигнал країни, довіра місцевих користувачів	Окремий сайт з нуля: своя авторитетність, посилання, підтримка, вартість доменів
Піддомен	en.example.com	Можна розмістити на іншому сервері чи платформі	Авторитетність основного домену передається слабше, складніша аналітика
Підпапка	example.com/en/	Успадковує вагу основного домену, один сайт в адмініструванні	Слабший сигнал країни, потрібна чиста технічна реалізація
Параметр в URL	?lang=en	Простий у розробці	Не рекомендуємо: погано індексується й плутає пошукові системи

Наш вибір за замовчуванням — підпапки на основному домені: /en/ для загальної англійської версії, а за потреби /en-us/ і /en-gb/ для регіональних. Новий розділ одразу отримує частину довіри, яку домен накопичив роками, і йому не доводиться збирати посилання з нуля. Для малого й середнього бізнесу це найшвидший і найдешевший шлях до результату.

Локальний домен має сенс, коли у вас у країні є юридична особа, склад чи представництво, окрема команда маркетингу й бюджет на повноцінне просування окремого сайту. Тоді .co.uk чи .com.au справді працює на довіру. Але купувати десять локальних доменів «на виріст» і копіювати на них той самий контент ми не радимо — це десять слабких сайтів замість одного сильного.

Hreflang: як пояснити пошуковику, кому що показувати

Атрибут hreflang підказує Google, яку мовну чи регіональну версію сторінки показати конкретному користувачу. Без нього британець може потрапити на американську сторінку з цінами в доларах, а український користувач — на англійську версію замість рідної. Реалізація проста, але помилки в ній ми знаходимо майже на кожному аудиті багатомовного сайту.

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

• <link rel="alternate" hreflang="uk" href="https://example.com/poslugy/">
• <link rel="alternate" hreflang="en" href="https://example.com/en/services/">
• <link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/services/">
• <link rel="alternate" hreflang="x-default" href="https://example.com/en/services/">

Правила, які ми перевіряємо завжди:

1. Взаємність. Якщо сторінка A посилається на B, то B має посилатися на A. Односторонні зв’язки пошуковик ігнорує.
2. Посилання на саму себе. Кожна сторінка в наборі вказує й власну адресу.
3. Правильні коди. Мова — за ISO 639-1, регіон — за ISO 3166-1. Британія — це en-GB, а не en-UK. Вказати лише регіон без мови не можна.
4. Повні абсолютні URL з протоколом, які віддають код 200, а не редирект чи 404.
5. Canonical на себе. Англійська сторінка не повинна мати canonical на українську — інакше вона випаде з індексу, і hreflang не допоможе.
6. x-default — для користувачів, мова яких не збігається з жодною версією. Зазвичай це загальна англійська версія або сторінка вибору мови.

Розмістити hreflang можна в <head> сторінки, у XML-карті сайту або в HTTP-заголовках (для PDF та інших файлів). На великих сайтах, як-от магазинах із тисячами товарів, ми надаємо перевагу карті сайту: вона не обтяжує код сторінок, а помилки простіше знайти й виправити централізовано. Головне — обрати один спосіб і не змішувати їх.

Після впровадження ми обов’язково проганяємо сайт краулером на кшталт Screaming Frog або Sitebulb: вони показують сторінки без зворотних посилань, неправильні коди, hreflang на сторінки з редиректом чи з закритою індексацією. Таку перевірку варто повторювати після кожного великого оновлення каталогу чи зміни шаблонів — hreflang ламається тихо, і помічають це зазвичай уже за падінням трафіку.

Окремо про Bing: він спирається на hreflang слабше, ніж Google, тому ми додатково правильно вказуємо мову через атрибут lang у тегу <html>. Для англомовних ринків це має значення: частка Bing там помітно більша, ніж у нас.

Переклад і локалізація — різні речі

Переклад відповідає на питання «як сказати те саме іншою мовою». Локалізація — «як продати те саме людині з іншою культурою, звичками й очікуваннями». Для SEO різниця принципова: пошуковик ранжує сторінки, які відповідають на запити місцевих користувачів їхніми словами, а не дослівний переклад вашого українського тексту.

Що змінюється	Переклад	Локалізація
Ключові слова	Перекладені з української	Зібрані заново за реальним попитом у країні
Ціни й одиниці	Гривні, кілограми, сантиметри	Місцева валюта, фунти й дюйми там, де так звично
Приклади й аргументи	Ті самі, що для України	Зрозумілі місцевому покупцю: стандарти, сертифікати, порівняння
Тон	Як в оригіналі	Відповідає ринку: коротше, конкретніше, з чітким закликом
Юридичні сторінки	Перекладені	Адаптовані під місцеві вимоги до приватності, cookies і повернень

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

А тепер про машинний переклад. Сам по собі він не є порушенням: Google оцінює не те, як створено текст, а чи корисний він людям. Проблема в іншому. Масово згенерований і не вичитаний контент без цінності для читача правила Google прямо відносять до спаму. А на практиці такий текст видно одразу: неприродні звороти, хибні друзі перекладача, плутанина в термінах, різні назви одного товару на різних сторінках. Відвідувач закриває сторінку, поведінкові сигнали погіршуються, довіра до бренду — теж.

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

Як ми працюємо з носіями мови

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

1. Семантика й структура від нас. До початку написання ми збираємо запити для країни, групуємо їх і готуємо структуру сторінок. Носій мови не має вгадувати, що шукають люди.
2. Глосарій термінів. Назви продуктів, послуг, характеристик і бренду — одна таблиця, якої дотримуються всі автори. Так «той самий товар» не має трьох різних назв на сайті.
3. Бриф для кожної сторінки: цільові запити, мета сторінки, аудиторія, обов’язкові факти, що не можна обіцяти, заклик до дії.
4. Носій мови пише або редагує — залежно від бюджету. Для ключових сторінок краще писати з нуля за брифом. Для великих каталогів підходить машинний переклад плюс ретельне редагування.
5. Перевірка фахівцем ніші. Технічні деталі звіряємо з клієнтом: носій мови може гладко сформулювати те, що по суті неправильно.
6. Фінальна SEO-перевірка: title, description, заголовки, внутрішні посилання, alt зображень, тексти в шаблонах і повідомленнях форм.

Окрема зона ризику — «дрібний» текст інтерфейсу: кнопки, фільтри, повідомлення про помилки, листи підтвердження замовлення, сторінка 404. Їх часто забувають, і людина посеред оформлення замовлення бачить фразу українською або незграбний машинний переклад. Ми збираємо всі рядки інтерфейсу в один файл і віддаємо його на вичитку разом із контентом. Про підготовку самих текстів — у статті «Як готувати контент для сайту».

Локальні сигнали: чому сайт має виглядати «своїм»

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

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

З посиланнями окрема історія. Посилання з українських сайтів допомагають домену загалом, але для англомовної версії найцінніші згадки з цільових країн: галузеві каталоги, огляди, партнерські сторінки, гостьові матеріали в профільних медіа. Купувати пакети «тисяча посилань з англомовних сайтів» ми не радимо — це швидкий шлях до проблем, а не до довіри.

Не забувайте і про швидкість. Якщо сервер стоїть в Україні, а покупець — у Каліфорнії чи Сіднеї, кожен запит долає півсвіту. CDN і нормальне кешування тут не розкіш, а необхідність, бо Core Web Vitals оцінюються за реальними користувачами з їхніх країн. Цю частину ми робимо в межах послуги оптимізації сайту.

Як не зіпсувати основний сайт

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

• Жодних автоматичних редиректів за IP чи мовою браузера. Робот Google сканує переважно з американських IP — примусовий редирект може сховати від нього інші версії. Замість цього — помітний перемикач мов і ненав’язлива підказка «Схоже, вам зручніше англійська версія».
• Перемикач веде на відповідну сторінку, а не на головну іншої мови. Якщо перекладу сторінки немає — на найближчий розділ.
• Неперекладені сторінки не потрапляють в індекс. Сторінка з англійським меню й українським текстом — це дубль і поганий досвід. Або перекладаємо, або закриваємо її в англійській версії.
• Одна мова — один URL. Не підміняємо контент на тій самій адресі залежно від cookies чи геолокації.
• Тестуємо на копії сайту, закритій від індексації, а не на робочому сайті. І не забуваємо зняти заборону під час запуску — помилку з noindex, що «переїхав» у продакшн, ми бачили не раз.
• Окремі карти сайту й звіти для кожної версії, щоб у Search Console й аналітиці бачити її окремо від основного сайту.
• Запуск поетапно: спершу головна, ключові послуги чи категорії й топові товари, потім решта. Сто якісних сторінок кращі за десять тисяч сирих.

Технічну частину — шаблони, метатеги, перелінковку між версіями — ми розбирали в матеріалі «Внутрішня SEO-оптимізація сайту». Для багатомовного сайту ті самі правила просто треба перевіряти в кожній мові окремо.

Типова ситуація з практики

Виробник обладнання, сайт українською добре ранжується вдома. Англійську версію колись зробили через плагін автоматичного перекладу на піддомені. Результат: тисячі сторінок у індексі, канонічні адреси вказують на українські сторінки, hreflang відсутній, ціни в гривнях, а в Search Console англійські сторінки майже не мають показів.

Ми переносимо англійську версію в підпапку /en/ з 301-редиректами зі старого піддомену, виправляємо canonical і налаштовуємо hreflang через карту сайту. Збираємо семантику для англомовних ринків і бачимо, що попит зосереджений приблизно в сорока посадкових сторінках, — їх носій мови пише з нуля за нашими брифами. Решту каталогу перекладаємо машинно з редагуванням, а сторінки без попиту й без перекладу закриваємо від індексації. Ціни в доларах, контакти з міжнародним кодом, сторінка доставки під іноземних клієнтів.

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

Чек-лист запуску англомовної версії

• Визначено цільові країни й схему: одна загальна версія чи регіональні.
• Обрано структуру URL (ми радимо підпапки) і зафіксовано її надовго.
• Зібрано окрему семантику для кожної країни, а не перекладено українську.
• Є глосарій термінів і брифи для ключових сторінок.
• Тексти написав або відредагував носій мови, інтерфейс теж вичитано.
• Налаштовано hreflang із взаємними посиланнями, самопосиланням і x-default.
• Canonical кожної сторінки вказує на саму себе.
• Немає автоматичних редиректів, є перемикач мов на відповідні сторінки.
• Ціни, контакти, доставка, юридичні сторінки адаптовано під країну.
• Неперекладені сторінки не індексуються, є окремі карти сайту й звіти.

Часті запитання

Чи можна обійтися однією англійською версією для всіх країн?

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

Чи покарає Google за машинний переклад?

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

Чи можна залишити англійські сторінки однаковими для США й Великої Британії?

Якщо ви робите окремі версії en-US і en-GB, вони мають відрізнятися хоча б валютою, контактами, доставкою, правописом. Майже ідентичні сторінки пошуковик може склеїти. Якщо відмінностей немає — простіше мати одну версію en.

Скільки часу потрібно, щоб нова версія почала давати трафік?

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

Підсумок

Успішна англомовна версія — це не переклад сайту, а окремий продукт для іншого ринку на спільному технічному фундаменті. Правильна структура URL, чистий hreflang, семантика, зібрана для конкретної країни, тексти від носіїв мови й локальні сигнали працюють лише разом. А дисципліна під час запуску захищає основний сайт від дублів і плутанини.

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