Многоязычный сайт на WordPress: плагины и структура URL

Когда клиент просит сделать многоязычный сайт на WordPress, первый вопрос не «какой плагин», а «как будет выглядеть URL для каждого языка». От этого решения зависит вся дальнейшая работа: индексация в Google и Яндексе, настройка hreflang, склейка дублей и даже то, сколько будет стоить поддержка сайта через год. Ниже - разбор двух главных плагинов для мультиязычности и вариантов структуры адресов, основанный на проектах, которые я делал для интернет-магазинов и корпоративных сайтов.

Когда нужен мультиязычный WordPress и какие есть варианты структуры

Мультиязычность нужна не только экспортёрам и туристическим компаниям. Из моей практики: интернет-магазины, которые продают на СНГ и Европу, IT-компании с англоязычной версией для инвесторов, региональные сайты с татарским или казахским разделом. У WordPress нет встроенной поддержки нескольких языков, поэтому всё держится на плагинах: они переводят интерфейс, дублируют записи и переключают URL в зависимости от языка.

Варианта структуры URL по сути три:

• подпапка - example.ru/en/, example.ru/de/
• поддомен - en.example.ru, de.example.ru
• отдельный домен для каждого языка - example.com и example.de

Выбор влияет на то, как поисковики видят языковые версии: как один сайт с разделами или как отдельные ресурсы. К этому вопросу вернусь ниже, а сначала о плагинах, потому что структура URL завязана на том, какой из них вы ставите.

WPML: возможности и стоимость

WPML - самый распространённый плагин для мультиязычности, из моих проектов он стоит примерно в 7 случаях из 10. Он переводит записи, страницы, произвольные типы записей, меню, виджеты и строки в теме. Есть модуль WPML WooCommerce Multilingual, который дублирует товары, категории и переводит письма заказа - без него мультиязычный магазин собирать почти бессмысленно.

Лицензия Multilingual CMS стоит около 99 долларов в год, для магазина понадобится тариф с модулем WooCommerce - там цена выше. Это разовый годовой платёж за обновления и поддержку плагина, я закладываю его в смету клиенту отдельной строкой, потому что это не моя услуга, а лицензия разработчика плагина.

Из плюсов: гибкая система перевода (можно переводить вручную, через переводчика в интерфейсе или подключить машинный перевод), нормальная работа с ACF-полями, поддержка RTL-языков вроде арабского. Из минусов: плагин тяжёлый, на слабом хостинге ощутимо просаживает админку, а при обновлении темы или конструктора страниц (особенно Elementor) иногда ломается синхронизация переводов - на одном проекте я потратил день на то, чтобы вернуть связь между русской и английской версией лендинга после апдейта.

Polylang: бесплатный путь и его ограничения

Polylang - вариант для тех, кому не нужна вся тяжёлая машинерия WPML. Базовая версия бесплатна и покрывает перевод записей, страниц, категорий, меню и виджетов. Для WooCommerce есть отдельное расширение Polylang for WooCommerce, платное, но заметно дешевле годовой лицензии WPML.

Разница на практике:

Я ставлю Polylang на проекты, где языков два-три, бюджет ограничен и нет сложной кастомной структуры данных. Если у клиента интернет-магазин с десятками произвольных типов записей, вариациями товаров и сложными фильтрами, WPML отрабатывает свою цену за счёт меньшего числа ручных доработок.

Структура URL: подпапки, поддомены и отдельные домены

Это решение принимается один раз в начале проекта, потому что смена структуры URL после индексации сайта означает настройку редиректов на сотни страниц и временную просадку трафика на 3-6 недель, пока поисковики переиндексируют новые адреса.

Подпапки (example.ru/en/) - вариант, который я рекомендую в большинстве случаев. Все языковые версии наследуют ссылочный вес основного домена, единый SSL-сертификат, простая аналитика в Google Search Console и Яндекс.Вебмастере через один аккаунт. И WPML, и Polylang настраивают такую структуру буквально парой кликов.

Поддомены (en.example.ru) - имеет смысл, если языковые версии сильно различаются по контенту или ведутся разными командами. Технически поисковики иногда считают поддомен отдельным сайтом, поэтому вес не всегда передаётся полностью, а SSL и DNS настраиваются отдельно для каждого поддомена.

Отдельные домены (example.com, example.de) - самый дорогой вариант в поддержке: отдельная регистрация, отдельный хостинг или минимум отдельная настройка сервера, отдельная репутация в поиске с нуля. Оправдан, когда бренд реально выходит на рынок другой страны и там работает локальная команда со своим маркетингом, а не просто переведённая версия сайта.

Для 90% проектов, которые проходили через меня, подпапки - оптимальный баланс между SEO-эффектом и трудозатратами на поддержку.

Перевод меню, виджетов и hreflang для SEO

Плагин переводит записи и страницы, но забывает переключить контент внутри виджетов, подвал, тексты форм и уведомления от плагинов вроде контактной формы или калькулятора доставки. Это приходится дособирать вручную: в WPML - через раздел String Translation, в Polylang - через модуль перевода строк темы. На среднем сайте с кастомной темой это 2-4 часа работы, которые заказчики обычно не закладывают в смету заранее.

Отдельная тема - тег hreflang. Он сообщает поисковику, какая страница на каком языке предназначена для какой аудитории, и без него две языковые версии одной страницы конкурируют друг с другом в выдаче вместо того, чтобы показываться нужной аудитории. WPML и Polylang генерируют hreflang автоматически при правильной настройке языковых версий, но я всегда проверяю результат через просмотр исходного кода страницы или Google Search Console - раздел «Международный таргетинг» показывает ошибки соответствия сразу.

Если на сайте есть кастомные шаблоны или блоки, собранные в Elementor и не привязанные к стандартным полям WordPress, автоматика может их пропустить, и тогда часть текста на переведённой странице остаётся на языке оригинала. Для таких случаев логичнее сразу закладывать разработку под мультиязычность на этапе вёрстки шаблонов, а не чинить постфактум - за этим обычно обращаются на разработку и доработку сайта, когда стандартных настроек плагина уже не хватает.

Мультиязычный интернет-магазин: WooCommerce, оплата и доставка

Со связкой WordPress плюс WooCommerce мультиязычность усложняется: нужно переводить не только карточки товаров, но и письма о заказе, статусы в личном кабинете, тексты на странице оплаты. Модуль WPML WooCommerce Multilingual или Polylang for WooCommerce дублирует товары между языковыми версиями, но SKU, остатки и цены синхронизируются как один товар, что удобно для складского учёта.

Платёжные и логистические интеграции при этом остаются языконезависимыми на уровне кода: если магазин принимает оплату через эквайринг Т‑Банка, виджет подключается один раз и просто подхватывает текущий язык интерфейса WooCommerce. То же с доставкой: интеграция с СДЭК для расчёта стоимости по индексу получателя работает одинаково для всех языковых версий, разница только в переведённых названиях служб доставки в чекауте.

Из практики: на магазине с русской и английской версией расхождение в переводе статусов заказа («в обработке» вместо «processing») - частая причина обращений в поддержку от иностранных покупателей, которые не понимают, что происходит с заказом. Такие мелочи стоит проверять руками до запуска, автоматический перевод плагина их не ловит.

Частые ошибки при запуске многоязычного сайта

За несколько лет работы с мультиязычными проектами вижу одни и те же грабли:

• Забывают переключить язык у шаблонов писем WooCommerce и плагинов форм - клиент получает письмо на русском, хотя сайт смотрел на английском.
• Ставят Polylang, а потом решают добавить сложный кастомный тип записей с ACF-полями и упираются в то, что перевод полей требует ручной настройки фильтров в functions.php.
• Меняют структуру URL с подпапок на поддомены после того, как сайт уже проиндексирован, и теряют часть позиций на 1-2 месяца.
• Не проверяют hreflang после переезда на новый хостинг или смену темы - тег иногда перестаёт генерироваться из-за конфликта кэширующих плагинов.
• Дублируют контент через простое копирование без привязки языковых версий друг к другу, из-за чего поисковик видит две одинаковые страницы на разных языках как дубли.

Большинство этих проблем решается на этапе планирования: если сразу понятно, сколько языков, какая структура URL и нужен ли WooCommerce, выбор между WPML и Polylang делается за 15 минут, а не переигрывается через полгода.

Частые вопросы

Какой плагин лучше для многоязычного сайта на WordPress - WPML или Polylang?

Если бюджет ограничен и языков два-три без сложной структуры данных, беру Polylang. Для интернет-магазина с большим каталогом и кастомными типами записей WPML экономит время за счёт готовых интеграций, несмотря на годовую лицензию.

Какая структура URL лучше для SEO - подпапки или поддомены?

Подпапки вида example.ru/en/ в большинстве случаев работают лучше: они наследуют ссылочный вес основного домена и проще в администрировании через один аккаунт Google Search Console. Поддомены оправданы, только если версии сайта ведутся разными командами с разным контентом.

Можно ли переехать с одной структуры URL на другую без потери позиций?

Полностью без потерь не получится: даже с корректными 301-редиректами поисковики переиндексируют новые адреса от 3 до 6 недель, и в этот период возможна просадка трафика. Переезд стоит планировать заранее, а не после того, как сайт уже набрал позиции.

Нужен ли hreflang, если на сайте всего два языка?

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