Представьте владельца магазина косметики: он добавил английскую версию сайта через плагин за один вечер и не понимает, почему заказов из-за границы всё равно нет. Открываешь сайт, а там форма оплаты осталась на языке оригинала, и адрес доставки просят ввести в формате, который иностранный покупатель просто не поймёт. Перевод текста – это заметная, но небольшая часть задачи. Остальное – валюта, привычные способы оплаты, юридические тексты под конкретную страну и правильная выдача в поиске.
Разберём, как эта задача решается технически на разных платформах, какую URL-структуру выбрать, зачем нужен hreflang и что обычно забывают перевести в первую очередь.
Зачем магазину вообще несколько языков
Тут не только про перевод карточек товара. Возьмём магазин, который продаёт в Украине и начинает отправлять заказы в Германию. У немецких покупателей другие привычки в оплате – Klarna, SOFORT, банковский перевод по счёту, а не карта в один клик. Цены там принято показывать сразу с НДС, это не пожелание, а требование закона. Срок возврата товара – 14 дней по правилам ЕС, и если на сайте написано что-то другое, это уже вопрос к юристам, а не к копирайтеру.
По сути мультиязычность – это локализация под конкретный рынок, где сам язык лишь самая заметная часть. Валюта, способы оплаты, доставка, условия возврата – всё это меняется вместе с языком, хотя технически лежит совсем в других настройках магазина.
Технические варианты в зависимости от платформы
Здесь всё упирается в то, на чём построен сам магазин.
WordPress: Polylang или WPML
Для WooCommerce чаще всего берут один из двух плагинов. Polylang – бесплатный в базовой версии и проще в настройке, но перевод товаров приходится синхронизировать вручную или через дополнительные модули. WPML стоит денег, зато из коробки умеет String Translation и работает с полями ACF, что для магазина с кучей кастомных атрибутов товара часто оказывается решающим. Оба плагина создают отдельный пост под каждую языковую версию страницы и связывают их между собой – именно эта связь и даёт переключатель языков и корректные hreflang-теги.
Момент, который часто упускают: категории, метки и атрибуты товаров нужно переводить отдельно, они не подтягиваются автоматически вместе с переводом самого товара.
OpenCart: языковые пакеты из коробки
В OpenCart мультиязычность встроена в ядро, сторонний плагин не нужен. Ставишь языковой пакет через Extensions, добавляешь язык в Localisation → Languages – и у каждого товара, категории или информационной страницы появляются отдельные поля под каждый подключённый язык прямо в форме редактирования. Минус в том, что валюта и язык в OpenCart – разные сущности: валюту настраивают отдельно в Localisation → Currencies, и без ручной привязки покупатель из Германии вполне может увидеть цену в гривне вместо евро.
Laravel или кастомная разработка
Здесь мультиязычность – уже инженерная задача, а не настройка готового плагина. Локаль обычно определяется по префиксу URL через middleware (route group с параметром {locale}), тексты интерфейса лежат в файлах resources/lang, а контент товаров – в отдельных полях базы данных (name_ru, name_en, name_de или отдельная таблица переводов). Плюс такого подхода – полный контроль над тем, что и как переводится, вплоть до логики показа цен и валют по странам. Минус – это нужно спроектировать заранее: добавить мультиязычность в готовый кастомный магазин задним числом обходится намного дороже, чем заложить её на старте разработки.
Структура URL: подпапки, поддомены или отдельные домены
Вариантов три, и выбор влияет на SEO сильнее, чем кажется на первый взгляд.
- Подпапки (shop.com/ru/, shop.com/en/) – самый простой вариант технически, весь накопленный вес домена работает на все языковые версии сразу. Именно так по умолчанию работают и Polylang, и WPML.
- Поддомены (ru.shop.com, en.shop.com) – удобно, если языковые версии обслуживают разные команды или вообще разные технические системы, но Google местами воспринимает поддомены как отдельные сайты, и вес под каждый придётся наращивать заново.
- Отдельные домены (shop.ru, shop.de) – максимум доверия у локальной аудитории, покупать в местной зоне людям привычнее, но это и отдельное продвижение, отдельные ссылки, отдельная репутация с нуля для каждого домена.
Для большинства магазинов, выходящих на пару новых языков без бюджета на продвижение каждого как самостоятельного проекта, подпапки – разумный вариант по умолчанию. Отдельные домены оправданы, когда рынок требует локальной регистрации бизнеса юридически – так бывает, например, при выходе на некоторые ближневосточные страны.
hreflang: зачем это Google и что ломается без него
Без hreflang Google видит две страницы с очень похожим содержанием на разных языках и сам решает, какую показать пользователю из Берлина – угадывает нечасто. Хуже того, это может восприниматься как дублирование контента, хотя по сути дубля нет, просто разные языки одного и того же товара.
Тег hreflang в head страницы сообщает поисковику: вот эта страница на русском, а вот её пара на немецком, показывай каждому свою. Выглядит это так:
<link rel=»alternate» hreflang=»ru» href=»https://shop.com/ru/product» />
<link rel=»alternate» hreflang=»de» href=»https://shop.com/de/product» />
<link rel=»alternate» hreflang=»x-default» href=»https://shop.com/» />
Polylang и WPML генерируют эти теги автоматически, поэтому в WordPress самая частая причина поломки – не сам плагин, а кеширование страницы: статический кеш ещё какое-то время отдаёт старую версию head без обновлённых тегов после добавления нового языка. В кастомных решениях hreflang прописывают вручную для каждой пары страниц – и именно тут легче всего забыть одну языковую версию при добавлении нового товара, карточка выходит без пары, ссылка hreflang ведёт в никуда.
Что на самом деле нужно перевести
Тексты на страницах товаров – очевидная часть работы. Менее очевидная:
- Meta title и meta description под каждую языковую версию – если оставить русские мета-теги на английской странице, Google хуже поймёт, о чём она.
- Alt-тексты изображений – влияют и на SEO, и на доступность для людей, использующих скринридеры.
- Письма с подтверждением заказа, сменой статуса доставки, сбросом пароля – покупатель из Германии, получивший письмо на русском после оформления заказа, доверия к магазину не прибавит.
- Страница checkout: названия полей формы, сообщения об ошибках валидации, кнопки оплаты.
- Юридические страницы – условия возврата, политика конфиденциальности, публичная оферта. Здесь мало просто перевести, нужно ещё проверить, соответствует ли содержание местному законодательству.
Частые ошибки
Самая распространённая – перевести всё машинным переводчиком и оставить как есть. Для внутренней документации это нормально, для публичного сайта, который продаёт, – нет: носитель языка сразу почувствует неестественные формулировки, а в юридических текстах машинный перевод может исказить смысл пункта о возврате денег.
Вторая – забыть про checkout. Бывает так: карточки товаров переведены безупречно, а кнопка оплаты и поля формы остались на языке оригинала. Покупатель доходит почти до конца воронки и теряется именно там, где должен был случиться заказ.
Третья – hreflang, который указывает сам на себя или на несуществующую страницу. Случается, когда перевод товара удаляют, а ссылка на него из других языковых версий остаётся.
И последняя, менее техническая: запускать новую языковую версию без хотя бы беглой проверки носителем языка. Машинный перевод плюс пятнадцать минут человека, который реально говорит на этом языке, – и половина неловкостей исчезает ещё до запуска.
Читайте также: Сколько стоит кастомный интернет-магазин на Laravel в Украине: от чего зависит цена; Как открыть интернет-магазин в Украине: гайд для новичков.
