Multisite: установка

Что такое Multisite и зачем его ставить именно вам
Multisite (мультисайт) — это режим WordPress, который позволяет управлять несколькими сайтами из одной админки. Никаких копий движка, никаких отдельных папок с файлами — всё живёт под капотом одной установки.
Представьте: у вас сеть из 10 региональных интернет-магазинов, блог для сотрудников и партнёрский портал. На обычном WordPress вам пришлось бы устанавливать 12 копий, следить за обновлениями каждой и мучиться с единой базой пользователей. Multisite решает всё это одной строкой в конфиге.
Главное отличие от других страниц про WordPress: я не буду кормить вас общей теорией. Сразу покажу, как это настроить за 15 минут, на каких хостингах это работает (и не работает), и какие грабли ждут новичков.
Когда Multisite — ваш выбор, а когда — нет (проверьте себя)
Перед установкой честно ответьте на три вопроса. Если хотя бы на один ответ «да» — мультисайт ваш вариант. Если нет — лучше остаться на обычных установках.
- Вам нужно централизованное управление обновлениями — вы обновляете WordPress и плагины один раз, а изменения применяются ко всем сайтам сети. Экономия времени: для сети из 20 сайтов ~2 часа в месяц.
- Вы хотите общую базу пользователей — клиент регистрируется на одном сайте и может заходить на все остальные без повторной регистрации. Пример: сеть курсов, где каждый курс — отдельный сайт.
- Вы создаёте сеть дочерних проектов с общей темой и ядром — типичные сценарии: региональные филиалы, языковые версии, тестовые площадки для клиентов.
А вот когда Multisite противопоказан: если сайты кардинально разные по тематике, требованиям к PHP и нагрузке. Например, интернет-магазин с 50 000 товаров и лёгкий блог лучше не селить под одной крышей — проблемы с производительностью вас убьют.
Подготовка: что проверить до установки (3 конкретных параметра)
Не лезьте в wp-config, пока не убедитесь, что ваш сервер (хостинг) тянет Multisite. Вот три жёстких требования.
Параметр №1: версия PHP. Минимум 7.4, рекомендуется 8.0 или 8.1. На PHP 5.6 мультисайт не взлетит — вылетит ошибка синтаксиса в ядре WordPress. Уточните версию в панели хостинга или через phpinfo().
Параметр №2: веб-сервер Apache с mod_rewrite или Nginx. Если у вас хостинг на IIS (Windows) — готовьтесь к танцам с бубном. Nginx требует ручного написания правил рерайта, без них картинки и CSS не загрузятся на подсайтах.
Параметр №3: отключённые плагины кеширования на время установки. WP Rocket, LiteSpeed Cache, W3 Total Cache — отключите их на этапе активации Multisite. Иначе получите белый экран смерти или «headers already sent».
Проверьте прямо сейчас: зайдите в админку → «Плагины» → деактивируйте всё, кроме необходимого (например, Akismet). Я серьёзно, это сэкономит вам час.
Установка Multisite: четыре шага в wp-config и один файл .htaccess
Всё свелось к редактированию двух файлов. Никаких сложных движений — только консоль или FTP.
Шаг 1. Откройте wp-config.php (лежит в корне вашего WordPress, обычно в public_html или www). Найдите строку /* That's all, stop editing! Happy blogging. */ — и прямо перед ней вставьте эту строчку:
define('WP_ALLOW_MULTISITE', true);
Сохраните файл и зайдите в админку. В меню «Инструменты» появится пункт «Сеть». Жмите туда.
Шаг 2. Выберите способ работы с подсайтами. Вам предложат два варианта: поддомены (site1.mysite.ru) и подкаталоги (mysite.ru/site1). Для новых проектов берите поддомены — проще с SEO и контентом. Подкаталоги подходят, если у вас уже есть сайт с контентом, и вы добавляете подсайты — тогда структура URL не порушит старые ссылки.
Шаг 3. После нажатия «Установить» — WordPress сгенерирует вам код. Скопируйте обе секции: ту, что в wp-config.php (обычно 3-4 строки), и ту, что в .htaccess (набор правил). Вставьте их в соответствующие файлы, заменив старые правила RewriteEngine On.
Шаг 4. Перезайдите в админку. Теперь меню сверху должно смениться — появится пункт «Мои сайты» и «Админка сети». Поздравляю, мультисайт работает.
Пример для Nginx: попросите поддержку вашего хостинга добавить такие правила в конфигурацию сервера. Без них подсайты будут отдавать 404 на все внутренние страницы. Стандартный набор правил — 9 строк, вот одна из ключевых: try_files $uri $uri/ /index.php?/$uri;.
Действия сразу после установки: три настройки, которые сэкономят вам недели головной боли
Установка завершена, но сеть ещё не настроена. Сделайте эти три вещи, пока не начали создавать сайты.
1. Настройте «Сетевые настройки» (в админке сети → «Настройки»). Поле «Заголовок сети» — это то, как ваш проект будет называться в виртуальных страницах и вкладках браузера. «Администратор сети» — email, на который придут уведомления о регистрациях. Сразу проверьте, что он рабочий.
2. Включите «Регистрация пользователей» — без этого ваши подсайты не смогут самостоятельно регистрировать новых пользователей. Выберите «Только подсайты» или «Подсайты и пользователи» — зависит от сценария. Для сети курсов лучше второй.
3. Заблокируйте опасные плагины на уровне сети. Перейдите в раздел «Плагины» в админке сети. Деактивируйте всё, что не подходит для всех сайтов (кэш, свои сборщики логов). Включите только базовые: Akismet, Hello Dolly (если хочется), плагин для общей подписки.
Ещё один лайфхак: сразу поставьте плагин «Network Shared Media» — он позволяет подсайтам использовать файлы из медиабиблиотеки друг друга. Иначе для каждой картинки на каждом подсайте придётся загружать отдельный файл — сожрёте дисковое пространство за месяц.
Типичные ошибки новичков при установке (и как их избежать)
Я собрал пять самых частых проблем, с которыми сталкиваются студенты моего курса. Читайте и не повторяйте.
- Белый экран после активации — почти всегда из-за несовместимости плагина с Multisite. Решение: отключите все плагины через wp-config, добавив
define('WP_NO_PLUGINS', true);, потом включайте по одному. - Подсайты открывают главный сайт вместо своего содержимого — чаще всего на Nginx забыли прописать правила рерайта. Проверьте конфигурацию: должна быть директива location ~ \.php$ с try_files, как я показывал выше.
- Ошибка «headers already sent» при редактировании файлов — вы случайно вставили код до в wp-config.php. Откройте файл в редакторе без лишних пробелов и пустых строк после закрывающего тега.
- Медиафайлы не отображаются на подсайтах — права доступа к папке wp-content/uploads. Убедитесь, что директория 755, а файлы 644. На некоторых хостингах нужно ещё включить AllowOverride в Apache.
- Сайты создаются, но не видны в админке сети — проблема с базой данных. Зайдите в phpMyAdmin, проверьте таблицу wp_blogs (префикс может быть другим). Если она пуста или повреждена — выполните SQL-запрос на восстановление:
REPAIR TABLE wp_blogs;.
Я видел, как студент потратил 3 дня на поиск причины «подсайт не загружает CSS». Всё оказалось в кэше CloudFlare — отключил CDN на время установки, и всё взлетело. Поэтому первое правило: всегда проверяйте с отключёнными системами кеширования и CDN.
Как не угробить производительность: чисел и лимитов на пальцах
Multisite — мощный инструмент, но он требует дисциплины. Вот реальные цифры из опыта.
Для хостинга на 1 vCPU и 2GB RAM: максимум 15-20 средних сайтов (по ~2000 посетителей каждый в месяц). Если сайты тяжёлые — пара интернет-магазинов уложат сервер. Решение: разделяйте ресурсы, выносите медиа на отдельный CDN (например, простой DigitalOcean Spaces стоит $5 в месяц).
Ограничение WordPress по умолчанию: не более 1000 сайтов в одной сети. На практике при 500 сайтах админка начинает тормозить — список сайтов грузится 2-3 секунды. Решение: установите плагин «Multisite User Management» или используйте кастомные таблицы для быстрого поиска.
Ещё один лимит: каждая новая тема должна быть включена на уровне сети, иначе подсайты её не увидят. Фреймворки типа Divi или Elementor Pro — требуют отдельной лицензии на каждый подсайт. Иначе плагин решит, что вы пират. Учтите это в бюджете: 1 лицензия Elementor Pro = 1 год для 1 сайта.
Золотое правило: никогда не ставьте на один сервер сайты с разными версиями PHP. Если один сайт требует PHP 7.4, а второй PHP 8.1 — начнутся фатальные ошибки. Используйте разные сервера или контейнеризацию.
Добавлено: 23.04.2026
