Мультисайт в WordPress: три подхода и когда какой выбрать

У вас пять сайтов на WordPress: головной корпоративный, три региональных представительства и блог. Обновление темы на всех занимает час, синхронизация контента идёт вручную, а после обновления ядра до WordPress 6.5 один из сайтов сломался, и вы узнали об этом от клиента. Задача — управлять всем из одной точки, но не потерять гибкость.

В WordPress есть три основных подхода к управлению несколькими сайтами: встроенная сеть Multisite, раздельные установки с централизованным управлением и использование внешних платформ вроде MainWP. У каждого свои ограничения, и выбор зависит от того, насколько сайты похожи друг на друга и кто ими управляет.

WordPress Multisite — одно ядро, много сайтов

WordPress Multisite — это режим, при котором несколько сайтов работают на одной установке WordPress. Один комплект файлов, одна база данных с отдельными таблицами для каждого сайта, единая панель управления сетью.

Включается добавлением одной строки в wp-config.php:

define('WP_ALLOW_MULTISITE', true);

После этого в админке появляется мастер настройки сети. Multisite поддерживается с версии WordPress 3.0, в актуальной ветке 6.x механизм не менялся.

Что получаете:

• Обновление ядра, тем и плагинов происходит один раз для всей сети.
• Общая библиотека медиафайлов опциональна — можно настроить через плагины.
• Единая панель управления пользователями: один аккаунт работает на всех сайтах сети.
• Экономия ресурсов сервера — одно ядро в памяти вместо пяти.

Чем платите:

• Плагин, несовместимый с Multisite, ломает доступ ко всем сайтам сразу. Совместимость нужно проверять заранее — у части плагинов она ограничена.
• Нельзя установить разные версии одного плагина на разные сайты сети.
• Резервное копирование затруднено: база общая, выгрузить один сайт отдельно сложнее.
• Хостинг должен поддерживать Multisite — не все тарифы это разрешают.

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

Раздельные установки с централизованным управлением

Каждый сайт — отдельная установка WordPress со своими файлами и базой данных. Управление идёт через внешний инструмент: MainWP, InfiniteWP, ManageWP или панель хостинга, если она предоставляет массовые операции.

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

Что получаете:

• Полная изоляция: падение одного сайта не затрагивает остальные.
• Гибкость в выборе плагинов и версий — на каждом сайте свой набор.
• Простое резервное копирование: каждый сайт копируется независимо.
• Возможность разнести сайты по разным серверам или хостингам.

Чем платите:

• Выше расход ресурсов: пять установок потребляют в несколько раз больше оперативной памяти и места на диске.
• Нет единой базы пользователей — синхронизацию нужно настраивать отдельно.
• Обновление быстрее, чем вручную, но медленнее, чем в Multisite: панель обновляет сайты по очереди.
• Дополнительный плагин на каждом сайте — ещё одна точка отказа.

Когда какой подход выбирать

Критерий — степень однородности сайтов и требования к изоляции.

Multisite подходит, если:

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

Раздельные установки с панелью управления подходят, если:

• Сайты разные по функциям: интернет-магазин, корпоративный сайт, форум, лендинг.
• Каждый сайт использует свой набор плагинов, и часть из них несовместима с Multisite.
• Критична отказоустойчивость: падение одного сайта не должно затрагивать другие.
• Сайты могут обновляться в разное время — например, у магазина свой график релизов.

Оставить всё как есть — без централизации — если:

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

Сравнение подходов

Что ломается и как избежать

В Multisite:

Ошибка «Не удаётся установить соединение с базой данных» после добавления третьего сайта — превышен лимит соединений MySQL на тарифе хостинга. Решение: перейти на тариф с бо́льшим лимитом или настроить пул соединений.

Плагин формы обратной связи работает только на главном сайте сети, на остальных выдаёт ошибку. Причина: плагин не поддерживает Multisite1. Проверяйте совместимость в описании плагина на WordPress.org перед установкой — ищите пометку «Multisite: Yes» или «Network: true».

Миграция одного сайта из сети в отдельную установку превращается в многочасовую задачу. Экспорт через стандартные средства не переносит настройки плагинов и виджеты. Используйте плагин NS Cloner для создания полной копии сайта внутри сети перед миграцией.

В раздельных установках:

После массового обновления плагинов через MainWP один из сайтов выдаёт белый экран. Причина: конфликт новой версии плагина с темой. Решение: в настройках MainWP включите опцию «Test updates on staging» — панель сначала обновит тестовую копию, и вы увидите проблему до того, как она попадёт на рабочий сайт.

Дочерний плагин MainWP на одном из сайтов перестал отвечать, сайт пропал из панели управления. Часто это означает, что хостинг заблокировал исходящие соединения с этого сайта к панели управления. Проверьте логи сервера и убедитесь, что IP-адрес панели не попал в чёрный список межсетевого экрана.

Что делать дальше

Если выбираете Multisite — протестируйте все плагины на совместимость с сетевым режимом на отдельной установке перед миграцией рабочих сайтов. Создайте тестовую сеть из двух сайтов, установите туда копии тем и плагинов, проверьте, что формы отправляются, корзина работает, письма приходят. Только после этого разворачивайте продакшен-сеть.

Если выбираете раздельные установки с MainWP или аналогом — настройте автоматическое резервное копирование перед первым массовым обновлением. Панель умеет откатывать изменения, но только если есть куда откатываться. Укажите в настройках хранилище для бэкапов — отдельный сервер, S3 или хотя бы другую папку на том же хосте.

Следующий шаг после выбора подхода — аудит плагинов. Составьте список того, что установлено на каждом сайте, отметьте плагины, которые дублируются, и проверьте, какие из них можно заменить одним сетевым решением. Это сократит поверхность атаки и упростит дальнейшие обновления.

1 Совместимость плагина с Multisite — способность плагина корректно работать в сетевом режиме WordPress, когда несколько сайтов используют одно ядро. Плагин должен различать контекст выполнения (на каком сайте сети он запущен) и не записывать настройки в глобальные таблицы, если они должны быть индивидуальными для каждого сайта. Проверяется по наличию тега «Network: true» в заголовке плагина или пометки в описании на WordPress.org.