Вы сделали сайт на Tilda, добавили каталог, настроили оформление заказа. Теперь нужно запустить версии на английском и немецком. Кажется, достаточно просто перевести текст.
По данным CSA Research, 76% покупателей предпочитают покупать на родном языке, а 40% не купят на другом языке вообще. Но добавить языковую версию и сделать её рабочей — это разные задачи.
На практике мультиязычный магазин сложнее обычного мультиязычного сайта. Здесь есть динамический каталог, корзина, оформление заказа, уведомления об оплате, сообщения об ошибках. Каждый из этих элементов требует отдельного внимания. Если что-то упустить, покупатель из Германии увидит каталог на немецком языке с русскоязычной корзиной.
Что именно нужно перевести в магазине
В интернет-магазине на Tilda есть несколько категорий контента, которые ведут себя по-разному. Статичный текст страниц — это меньшая часть проблемы.
Статичный контент
Описание магазина, тексты о компании, условия доставки, статичные блоки на главной. Это переводится стандартно, любой прокси-переводчик справится.
Каталог товаров
Tilda загружает карточки товаров динамически через JavaScript. Названия, описания, характеристики, ценники генерируются после загрузки страницы. Большинство переводчиков видят только HTML-структуру, а не то, что подгружается после.
Результат: товар в каталоге называется «Leather wallet», а при переходе в карточку товара название на русском. Или весь каталог остаётся непереведённым.
Корзина и оформление заказа
Tilda Store — отдельный модуль со своей логикой. Корзина, страница оформления заказа, поля адреса доставки, выбор способа оплаты, кнопка «Оплатить» — всё это отдельные компоненты. Большинство сервисов их не переводит.
Системные сообщения
«Товар добавлен в корзину», «недостаточно товара на складе», уведомления об ошибках — всё это генерируется динамически. Часто остаётся на языке исходного сайта, даже когда всё остальное переведено.
Письма и уведомления
Подтверждение заказа на email — отдельная история. Tilda отправляет письма через свой механизм, и Multify на этот процесс не влияет. Это не баг и не ограничение конкретного сервиса: письма живут вне зоны ответственности прокси.
Технически это можно решить через внешнюю автоматизацию. Multify передаёт в данных формы поля с языком, страной и доменом, откуда была отправлена заявка. Если подключить n8n, Make или аналог, можно настроить логику: пришла заявка с немецкой версии — отправить письмо по немецкому шаблону. Но это отдельная интеграция, которую нужно настраивать самостоятельно.
Почему стандартные решения не справляются
Weglot и Linguise переводят статичный HTML. Динамический контент (каталог, корзина, сообщения) они или не видят, или переводят нестабильно.
Конкретная проблема: когда пользователь добавляет товар в корзину, Tilda обращается к своим серверам и получает данные в реальном времени. К этому моменту переводчик на клиентской стороне уже завершил обработку страницы. Новые данные он не видит.
Решение — перевод на серверной стороне. Когда все запросы к Tilda проходят через прокси, каждый ответ (включая данные каталога и состояние корзины) переводится на сервере, в браузер уже приходит готовый результат. Пользователь всегда видит переведённый контент, независимо от того, как он оказался на странице.
Валюты: три подхода и их последствия
Мультиязычный магазин почти всегда требует мультивалютности. Для немецкого покупателя цены должны быть в евро, для британского — в фунтах. Есть три подхода, и у каждого разные последствия для SEO.
Конвертация на JavaScript
Самый распространённый способ: скрипт на странице берёт рублёвую цену и пересчитывает её в нужную валюту прямо в браузере. Пользователь видит евро, а в HTML по-прежнему рубли.
Для SEO это плохо. Googlebot сканирует страницу и видит цены в рублях. Если ваш сайт для немецкого рынка, он фиксирует расхождение между тем, что индексирует, и тем, что видит пользователь. Это влияет на ранжирование по немецким запросам.
Ручное ведение нескольких каталогов
Отдельный каталог с ценами в евро для немецкой версии. Работает, но требует обновления вручную при каждом изменении цен. Для небольшого каталога приемлемо, для 200+ товаров — нет.
Конвертация на сервере
Цены пересчитываются на сервере, а пользователь получает готовую страницу с нужной валютой. Googlebot видит ровно то же, что видит немецкий покупатель: цены в евро, SEO корректное, данные актуальные.
Можно выбрать источник курсов: Центробанк для рублёвого рынка, ECB для европейского, или зафиксированный курс — если не хотите, чтобы цены менялись каждый день вместе с курсом.
SEO: что нужно настроить для каждой языковой версии
Мультиязычный магазин без правильного SEO-фундамента будет невидим в поисковиках целевых рынков.
hreflang
Теги hreflang сообщают Google, что у вас несколько языковых версий одной страницы. Без них поисковик не понимает, какую версию показывать пользователям из каждой страны, и может расценить языковые версии как дублированный контент.
Для магазина это особенно важно: у каждого товара, каждой категории и каждой страницы чекаута должен быть корректный hreflang. Официальная документация Google подробно описывает правила реализации.
Sitemap для каждого языка
В sitemap должны быть все языковые версии всех страниц. 300 товаров и три языка — это 900 страниц в sitemap, каждая с указанием своего языка.
Метатеги для каждой версии
Title и description в поисковой выдаче должны быть на языке пользователя. Немецкий покупатель видит немецкое описание товара, французский — французское.
URL-структура
Возможно 3 модели:
- поддомены (de.yourshop.com) — самый простой способ, подходит для большитнства интернет-магазинов
- папки (yourshop.com/de/)
- разные домены (yourshop.com/yourshop.de/)
Локализация: что идёт дальше перевода
Технически перевод можно настроить за день. Но чтобы магазин работал для покупателей из конкретной страны, нужно учесть несколько дополнительных вещей.
Форматы дат и чисел. В Германии цена пишется как «19,99 €», в США — «$19.99». Разделитель тысяч, позиция знака валюты, формат даты. Мелочи, которые сразу заметны местному покупателю.
Способы оплаты. Российский покупатель привык к ЮКассе или СБП. Европейский ожидает Stripe, PayPal или SEPA-перевод. Показывать все способы оплаты всем пользователям не имеет смысла, это создаёт путаницу. Лучше показывать только те, которые работают в конкретном регионе.
Условия доставки. Для каждого рынка свои сроки, свои перевозчики, своя стоимость доставки. Это для разных регионов настраивается отдельно.
Правовые требования. Для европейского рынка нужен cookie banner в соответствии с GDPR, политика конфиденциальности на языке пользователя, иногда обязательные сведения о продавце (Impressum для Германии).