Мультиязычный сайт на WordPress: Polylang, WPML или поддомены

Второй язык увеличивает расходы на обслуживание на 30-50 процентов: каждая правка теперь делается дважды. Технически выбор между плагином и отдельными сайтами вторичен, первично то, кто будет поддерживать перевод в актуальном состоянии.

Запрос «сделайте нам сайт на двух языках» звучит просто, пока не начинаешь считать, сколько это будет стоить в обслуживании через год. Эта статья для владельцев сайтов на WordPress, которые думают добавить английскую, казахскую или любую другую языковую версию и выбирают между Polylang, WPML и вариантом с отдельным поддоменом. Разберу три архитектуры, что каждая стоит в деньгах и времени, как выставить hreflang без дублей и что закладывать в регламент правок на будущее.

Сначала вопрос без техники: второй язык точно нужен

Прежде чем выбирать плагин, стоит проверить саму гипотезу. Если у вас сайт услуг для локального рынка (мастер по ремонту в Казани, стоматология в Кронштадте), английская версия почти никогда не приносит заявок: у неё нет своей аудитории поиска, и её заводят просто потому, что «солидно». Я видел сайты, где английская версия висела три года, получила за это время 40 визитов и ни одной заявки, а правки в неё вносились каждый раз, когда менялась цена на русской странице.

Второй язык оправдан, когда есть измеримый спрос: экспорт, работа с диаспорой, франшиза в другой стране, туристический бизнес с реальным потоком иностранных клиентов. Если такого спроса нет, но нужно показать англоязычному партнёру, что сайт «международный», часто достаточно одной статичной страницы About in English без полноценной мультиязычной архитектуры. Это не требует ни плагина, ни поддержки, ни постоянной синхронизации.

Три архитектуры и что каждая стоит в поддержке

Плагин с языками в подпапках

Самый распространённый вариант: сайт живёт на одном домене, языки различаются подпапкой (/en/, /kz/), все версии в одной базе данных, одна админка, один хостинг. Технически это делают Polylang, WPML, TranslatePress и им подобные.

Плюс: минимум инфраструктурных изменений, один сайт для владельца, общие плагины и кэш. Минус: любое обновление ядра или плагина затрагивает обе языковые версии одновременно, а ошибка в плагине мультиязычности ломает сразу весь сайт, а не одну версию.

Поддомены на одном движке

Английская версия живёт на en.site.ru, но это может быть либо тот же движок WordPress с Multisite, либо вообще отдельная установка с синхронизацией контента вручную или через API. Здесь уже требуется отдельная настройка DNS, отдельный SSL-сертификат (или wildcard-сертификат на весь домен), и отдельное решение, как переводы контента попадают на поддомен.

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

Отдельные сайты на разных доменах

Радикальный вариант: site.ru и site.com как два независимых WordPress без общей базы, часто на разных хостингах. Подходит, когда вторая страна это по сути отдельный бизнес с локальными ценами, локальной юрисдикцией, локальной поддержкой.

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

Polylang и WPML: чем отличаются на практике

Polylang в бесплатной версии закрывает базовый сценарий: перевод записей, страниц, категорий, меню, есть переключатель языков виджетом. Платная версия Polylang Pro (разово около 10-15 тысяч рублей за годовую лицензию на сайт, в зависимости от курса и продавца) добавляет перевод произвольных типов записей и полей ACF, что для сайта на кастомных полях критично: без Pro-версии кастомные поля ACF просто не переводятся штатно, нужны обходные пути.

WPML исторически считается более мощным и более тяжёлым: он тянет собственную систему управления переводами (Translation Management), интеграцию с сервисами машинного перевода, поддержку WooCommerce из коробки. Лицензия начинается от заметно более высокой суммы в год и растёт с числом доменов. На практике WPML чаще ставит на сайт свой слой поверх стандартных таблиц WordPress, из-за чего при смене темы или крупном обновлении плагинов чаще вылезают конфликты, чем у более простого Polylang.

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

Критерий	Polylang	WPML
Базовая версия	Бесплатно	Платно, от подписки
Перевод ACF-полей	Только в Pro	Есть в базовой поставке
Нагрузка на сайт	Ниже	Выше
Совместимость с темами	В целом стабильная	Чаще конфликты при апдейтах
WooCommerce	Через отдельный модуль	Нативная интеграция

hreflang и canonical: минимальная разметка без дублей

Главная техническая ошибка мультиязычных сайтов, которую я вижу у клиентов: hreflang прописан только на главной странице, а на внутренних страницах и статьях блога его просто нет. Поисковик тогда не понимает, что /en/uslugi/remont/ это перевод /uslugi/remont/, и начинает воспринимать их как два независимых документа с похожим содержанием на разных языках, что иногда роняет обе версии в дублирующие сигналы.

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

<link rel="alternate" hreflang="ru" href="https://site.ru/uslugi/remont/" />
<link rel="alternate" hreflang="en" href="https://site.ru/en/services/repair/" />
<link rel="alternate" hreflang="x-default" href="https://site.ru/uslugi/remont/" />

Polylang и WPML генерируют это автоматически для связанных через плагин страниц, но если перевод сделан руками, без привязки через плагин (например, отдельная статья, а не перевод существующей), связка не появится сама и hreflang придётся прописывать вручную в шаблоне. Canonical при этом у каждой языковой версии должен указывать сама на себя, а не на основной язык: это частая путаница, из-за которой английская версия внезапно выпадает из индекса, потому что кто-то поставил canonical на русский оригинал по аналогии с обычными дублями. Логика здесь другая, чем при обычных canonical для дублей, о которых писал в статье про канонические ссылки: переводы это не дубли, а разные документы для разных языковых аудиторий, поэтому взаимный canonical на оригинал только вредит.

Машинный перевод: где допустим, где убивает индексацию

Автоматический перевод через Google Translate API или встроенный модуль WPML снимает боль ручного перевода, но качество результата для технических и юридических страниц (условия оферты, политика конфиденциальности, описание услуг с терминами) часто получается таким, что носитель языка сразу видит машинный текст. Для внутреннего использования (перевести служебную страницу для сотрудников) это нормально, для публичной SEO-страницы, которая должна ранжироваться, почти всегда нет: низкое качество текста поисковики умеют распознавать, и такие страницы либо не попадают в топ, либо не индексируются вовсе как малополезный контент.

Рабочий компромисс, который использую сам: машинный перевод как черновик, дальше вычитка носителем языка или хотя бы редактором с уровнем языка выше intermediate, минимум на ключевых страницах (услуги, цены, контакты). Для второстепенных страниц (архив старых новостей, теговые страницы) машинный перевод без вычитки допустим, потому что они и не должны тянуть трафик.

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

Главное, что стоит понимать до старта проекта: с момента добавления второго языка любая правка контента на сайте либо делается на обоих языках сразу, либо сайт начинает расходиться. Поменяли цену услуги на русской странице, забыли обновить английскую, через полгода клиент, читающий английскую версию, увидел старую цену и написал претензию. Это не гипотетический случай, а типовая ситуация на мультиязычных сайтах без выстроенного процесса.

Практический список, что добавляется в регламент обслуживания при переходе на два языка:

• любая правка цены, условий или контактов дублируется на все языковые версии в одном заходе, а не откладывается на потом;
• обновления плагинов проверяются на тестовой копии на обеих локалях, потому что баг может проявиться только в RTL или только при активном модуле перевода;
• раз в квартал сверка hreflang через Вебмастер и Search Console на предмет пропущенных связок у новых страниц;
• список страниц без перевода (если решили не переводить архив блога целиком) фиксируется явно, чтобы не плодить полуготовые версии.

Часы на обслуживание мультиязычного сайта в среднем на 30-50 процентов больше, чем у одноязычного аналога того же объёма, именно из-за двойной работы с контентом, а не из-за самого плагина. Это стоит учитывать при обсуждении тарифа: смотрите мои тарифы на обслуживание, где для сайтов с несколькими языковыми версиями расчёт идёт индивидуально, а не по базовой сетке.

Что выбрать под свой случай

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

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

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

Что выбрать: Polylang, WPML или отдельные сайты

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

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

На 30-50 процентов дороже одноязычного при том же объёме. Плюс лицензия плагина, если берётся платная версия. Основная статья расходов это не техника, а перевод каждой правки.

Что нужно для правильной индексации

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

Можно ли обойтись машинным переводом

Для интерфейса и служебных страниц да. Для страниц, которые должны приводить трафик, нет: машинный перевод без вычитки индексируется плохо и портит впечатление о компании.