Інтернет-магазин середнього розміру вирішує розпочати продаж другою мовою. Таке рішення часто приймається на основі першого ж відповіді на запитання: «Чи підтримує це наша платформа?» Це питання щодо інструментів – і той, хто починає інтернаціоналізацію саме так, використовує плагін, додаток або функцію платформи, які вже встановлені. Питання архітектури, якщо воно взагалі постане, з’являється лише через рік: тоді, коли каталог дублюється на трьох вітринах магазину, і вже ніхто точно не знає, чому.
21 серпня 2026 року BigCommerce надав приклад цього: вбудована багатомовна підтримка, загальнодоступна, яка керує мовними варіантами всередині платформи, замість того, щоб розділяти магазин за мовами. Це справжня функція. Але це не рішення. Рішення полягає в тому, де саме відбувається переклад – на платформі, на рівні, що передує їй, чи у вихідному коді. І воно має наслідки ще довго після запуску.
Blackbit є партнером з комерційної інженерії для середніх підприємств електронної комерції в регіоні DACH, які прагнуть освоїти нові ринки, не подвоюючи обсяги роботи з оновлення даних про товари.
З технічної точки зору існує три архітектури, і вони відрізняються тим, де саме здійснюється переклад. По-перше, у самій системі магазину: платформа вбудовано управляє мовними варіантами та створює мовні підпапки, не дублюючи каталог. По-друге, у перекладацькому шарі, який вбудовано між платформою та користувачем і який перекладає вміст під час роботи. По-третє, у джерелі: дані про товари перекладаються в PIM і передаються в магазин як вміст, що підтримується нативно. Усі три підходи забезпечують багатомовний інтернет-магазин – але з різними експлуатаційними витратами, різним рівнем SEO-оптимізації та різною залежністю від одного постачальника.
Мій досвід роботи з багатомовними магазинами BigCommerce базується на впровадженнях з кількома вітринами та на Weglot, а не на новій вбудованій функції. Це важливе розрізнення: скільки вітрин потрібно ринку – це інше рішення, ніж те, де саме зберігаються переклади. Чотири критерії є вирішальними для кожного з трьох шляхів – глибина SEO, суверенність даних, обслуговування та масштабування, модель витрат.
Вбудована в платформу. Платформа самостійно управляє мовними варіантами та створює мовні підпапки URL без дублювання каталогу. BigCommerce підтримує свою вбудовану багатомовну підтримку за допомогою Translations Manager або GraphQL-API і, згідно з документацією, охоплює товари, оформлення замовлення, платежі, доставку та комунікацію після покупки. Shopware та Shopify вирішують це завдання по-іншому, кожен згідно з власною документацією: У Shopware мови є окремими об’єктами, які прив’язуються до каналів продажів, і кожен канал продажів може отримати власний домен або власний підкаталог. Shopify відображає мови через ринки, підтримує контент у Translate & Adapt та присвоює окремі URL-адреси для кожної мови. Глибина SEO: Усі три системи генерують самостійні, індексовані мовні URL-адреси; контент та метадані, специфічні для конкретного ринку, як і раніше, потребують редакційної перевірки. Суверенність даних: перекладені тексти зберігаються в базі даних платформи. Щодо текстів про товари це рідко є питанням захисту даних, оскільки особисті дані, як правило, там не містяться. Це питання залежності та прозорості: провідною системою залишається платформа, експорт здійснюється через її інтерфейси, а версіонування та аудиторський слід обмежуються тим, що пропонує платформа. Якщо місце хостингу та правова система самі стають критерієм, це слід враховувати при виборі платформи. Обслуговування та масштабування: кожна платформа має обмеження – у BigCommerce, наприклад, п’ять локалізацій на один інтернет-магазин. Модель витрат: слід підтвердити доступність та вартість обраного тарифного плану; окремо запланувати в бюджеті витрати на впровадження, переклад та редагування.
Рівень перекладу, приклад Weglot. Хмарний рівень між платформою та клієнтами, інтегрований за допомогою фрагмента коду JavaScript або плагіна. Новий контент автоматично перекладається машиною та відображається у структурі сторінки, ручні виправлення можливі згодом. Рівень SEO: тут вирішальне значення має не сам продукт, а тип інтеграції. Weglot у власній документації зазначає, що інтеграція JavaScript на стороні клієнта не є сумісною з SEO; варіанти з піддоменами та підкаталогами виконують переклад на стороні сервера, присвоюють власні URL-адреси та автоматично встановлюють атрибут hreflang. Тому спершу перевірте, який саме варіант у вас використовується – від цього залежить, чи будуть перекладені сторінки взагалі індексовані на цільовому ринку. І це стосується не лише Google: у наймасштабнішому на сьогодні дослідженні з цього приводу (Vercel та MERJ, грудень 2024 року) жоден із великих ШІ-краулерів не виконував JavaScript. Те, що з’являється лише в браузері, для них не існує – а отже, не з’являється й у їхніх відповідях. Суверенність даних: переклади зберігаються у провайдера; перевірте доступ до експорту та умови міграції для обраного тарифу. Обслуговування та масштабування: не лише новий контент, а й зміни в існуючому автоматично фіксуються та перекладаються заново. Ручні виправлення при цьому не втрачаються, вони зберігаються у списку перекладів – однак відображається нова машинна версія. Отже, перевірені метадані після зміни вихідного тексту потрібно перевіряти заново. Модель оплати: диференційована передплата залежно від обсягу тексту та кількості мов, опублікована на сторінці тарифів Weglot.
Переклад у джерелі, приклад Pimcore з Data Director та DeepL. Контент перекладається у джерелі та зберігається там. Blackbit Data Director з’єднує Pimcore з таким постачальником, як DeepL, і може автоматично запускати переклад, щойно змінюється контент джерела; крім того, доступні робочі процеси на запит. Результати зберігаються у PIM у вигляді мовних варіантів і передаються до інтернет-магазину. Ця схема не залежить від платформи: незалежно від того, чи називається цільова платформа Shopware, Shopify чи BigCommerce, мовна суверенність залишається в PIM – у проєктах Shopware ми працюємо за тією самою схемою. Глибина SEO: контент можна редакційно адаптувати до кожного ринку, а не перекладати «один до одного». Суверенність даних: перекладені поля оновлюються в PIM; обробку через DeepL слід розглядати окремо — перевіряйте місця обробки та умови договору постачальника. Обслуговування та масштабування: модель даних має підтримувати багатомовність, а тригери потрібно налаштувати заздалегідь; після цього розпізнавання відбувається автоматично. Модель витрат: слід передбачити в бюджеті витрати на PIM та інтеграцію, а також на використання послуг перекладу. Тариф DeepL «Growth API» поєднує, за даними DeepL, фіксовану базову плату, включений ліміт символів та витрати за перевищення ліміту, що залежать від обсягу використання.
П’ять питань вирішують більшу частину задачі, і жодне з них не стосується вибору платформи.
Скільки цільових мов? Нативний підхід і «шар» без проблем справляються з кількома мовами; чим більше їх кількість, тим важливішим стає автоматичне розпізнавання. До того ж: платформи мають обмеження на кількість мов для кожного інтернет-магазину – у BigCommerce, наприклад, п’ять. Про це слід знати до того, як обрати підхід, а не після.
Наскільки цільові ринки важливі з точки зору SEO? Для критично важливих ринків перевірте, наскільки можна редагувати контент і метадані, як побудовані мовні URL-адреси та як відбувається процес затвердження – приймайте рішення на основі конкретної реалізації, а не категорії. Weglot документує редагування перекладів, метазаголовків та описів; отже, редакційний контроль не є унікальною особливістю підходу на основі PIM.
Як швидко змінюється контент? Контент, що швидко оновлюється, підходить для автоматичного збору даних через шар; стабільний каталог більше виграє від редакційної якості в джерелі.
Які вимоги ставлять суверенність даних та можливість аудиту? B2B-компанії та галузі, що підлягають регулюванню, повинні відповісти на це питання до вибору шляху, а не після нього.
Який обсяг редакційних ресурсів наявний? Джерельний підхід передбачає, що хтось має налаштовувати тригери перекладу та перевіряти результати. Без цих ресурсів автоматизація не працюватиме належним чином самостійно.
Гібридна конфігурація дозволяє прив’язувати переклади продуктів і категорій до PIM, а редакційні сторінки – до окремого шару, з чітко визначеними правилами відповідальності та оновлення для кожного типу контенту. Оскільки цей розподіл є частиною ширшого руху до модульної архітектури, наша стаття про Composable Commerce пояснює, коли цей крок є доцільним – сама по собі гібридна система перекладу ще не є Composable Commerce.
Перед запуском варто перевірити чотири ризики.
Автоматизована локалізація без людського контролю. Машинний переклад передає лексику, але не завжди надійно відображає культурні нюанси, інтонацію та технічно правильні, але в контексті неточні формулювання. Хтось повинен прочитати результат.
Плануйте мовні URL-адреси та атрибут hreflang разом. Google рекомендує використовувати окремі URL-адреси для мовних версій та розмітку, що вказує на альтернативні варіанти; обидва ці аспекти слід перевірити перед запуском, і Google описує це у своїй документації щодо управління багаторегіональними веб-сайтами. І не покладайтеся на те, що ваша система забезпечить усе: значення hreflang x-default не завжди можна встановити в поширених CMS – це прогалина, з якою ми вже стикалися на практиці.
Новий ринок без налагодженої системи PIM. Вітрина запускається на новій мові, але дані про товари, що лежать в її основі, не отримують такої ж редакційної уваги, як на внутрішньому ринку. Від цього страждає якість розміщення.
Видимість на цільовому ринку не вимірюється. Найменше – у відповідях, згенерованих штучним інтелектом. Без вихідних даних неможливо сказати, чи з’являється там бренд взагалі – не кажучи вже про те, чи діє обраний шлях.
Перетворення інтернет-магазину на багатомовний – це не завдання перекладу, а архітектурне рішення, яке має три шляхи реалізації. По-перше, вбудована мовна функція платформи: мовні варіанти та підпапки за мовами створюються безпосередньо в системі магазину без дублювання каталогу – BigCommerce зробила таку вбудовану багатомовну підтримку загальнодоступною в серпні 2026 року, Shopware та Shopify пропонують подібні механізми. По-друге, перекладацький шар, такий як Weglot, що вбудовується між платформою та користувачем: нові мови запускаються за лічені години, але переклади управляються у постачальника. По-третє, переклад у джерелі: дані про товари перекладаються в PIM і надаються як контент, що підтримується нативно – у стеку Blackbit через Blackbit Data Director з інтеграцією DeepL. Який шлях підійде, залежить від кількості мов перекладу, SEO-релевантності цільових ринків, частоти оновлення контенту та вимог до суверенітету даних; гібридні конфігурації є цілком прийнятним варіантом, якщо різні типи контенту потребують різних робочих процесів. Компанія Blackbit digital Commerce з Геттінгена допомагає середнім підприємствам електронної комерції в регіоні DACH (Німеччина, Австрія, Швейцарія) у прийнятті цього рішення та реалізує його в Pimcore, Shopware, BigCommerce та Shopify.
Якщо ви плануєте інтернаціоналізацію протягом найближчих двох кварталів: опишіть нам свою конфігурацію – модель даних, ситуацію з SEO на цільових ринках, редакційні можливості – і ми визначимо три підходи, що підходять саме для вашого випадку. Без переваги щодо конкретної платформи.