WordPress Multisite на виртуальном хостинге: субдомены, DNS и wildcard SSL без боли

WordPress Multisite — мощный режим, когда одно ядро WordPress обслуживает множество сайтов. На практике это удобно для сетей франшиз, региональных версий, академий с разными курсами и внутренних порталов. На виртуальном хостинге Multisite отлично работает, если заранее продумать DNS, SSL и правила веб-сервера. В этой статье — системная инструкция: от выбора схемы сети до wildcard SSL и типовых ловушек, с упором на реальность shared-хостинга. Если вы только выбираете платформу, посмотрите тарифы на виртуальный хостинг.

Когда Multisite — это правильно, а когда нет

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

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

Важно: в Multisite плагины ставятся глобально, а включать их можно на весь «Network» или по сайтам. Сильно разные стеки редко уживаются.

Схема сети: субдомены или подкаталоги

WordPress предлагает две схемы:

• Субдомены: site1.example.com, shop.example.com, blog.example.com. Нужен DNS wildcard и, как правило, wildcard SSL.
• Подкаталоги: example.com/site1, example.com/shop. Проще в DNS/SSL, но есть ограничения и конфликт с существующими путями.

На виртуальном хостинге субдомены обычно предпочтительнее, если требуется изоляция брендов/регионов и независимые cookie-домены. Подкаталоги проще, если сеть небольшая и не планируются 100+ сайтов.

Подготовка окружения на виртуальном хостинге

Версия PHP и ресурсы

Рекомендуется PHP 8.2 или 8.3, memory_limit от 256M, upload_max_filesize и post_max_size под ваши потребности (часто 32–128M), max_execution_time 60–120. На современных shared-платформах это меняется в панели или через .user.ini.

; .user.ini для PHP-FPM на виртуальном хостинге
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 120
max_input_vars = 5000

Если хостинг использует Apache с mod_php, параметры можно задавать в .htaccess через директивы php_value/php_flag. На PHP-FPM это обычно не сработает — используйте .user.ini или панель.

DNS: wildcard для субдоменов

Для схемы с субдоменами создайте wildcard-запись в зоне домена:

• A: *.example.com на IP виртуального хостинга.
• Если есть IPv6 — AAAA для *.example.com.
• TTL 300–1800 для ускорения изменений без потери кэш-эффективности.

Если у вас CDN или внешний балансировщик, указывайте их целевой IP/имя. Помните, что wildcard *.example.com не покрывает поддомены второго уровня вида *.sub.example.com.

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

SSL: почему нужен wildcard

Варианты:

• Wildcard SSL для *.example.com и обычный на корень example.com (или один сертификат, включающий оба SAN: example.com и *.example.com).
• Либо SAN-сертификаты с явным перечислением субдоменов. Подходит, если сайтов мало и список фиксирован. Для динамической сети это неудобно.

Wildcard от ACME-провайдеров обычно требует валидацию DNS-01: вам нужно добавить TXT-запись _acme-challenge.example.com. На виртуальном хостинге эту процедуру часто автоматизирует панель; если же нет — придется добавить TXT вручную на этапе выпуска и продления. Обратите внимание на время жизни TXT (TTL) и распространение записи. Если автоматизируете выпуск, пригодится материал про автоматизацию DNS-01 для wildcard-сертификатов.

Сертификат для *.example.com не покрывает корневой example.com — убедитесь, что он тоже включен в сертификат либо выпущен отдельно. При необходимости можно оформить коммерческий сертификат в разделе SSL-сертификаты.

Пошаговая активация WordPress Multisite

1) Резервная копия и подготовка

• Сделайте полный бэкап файлов и БД.
• Отключите кэш-плагины на время миграции (меньше шансов ловить артефакты).
• Проверьте ЧПУ: Настройки → Постоянные ссылки → ЧПУ включены.

2) Разрешаем установку сети

Включаем установщик сети в wp-config.php (строкой выше /* That's all, stop editing! */):

define('WP_ALLOW_MULTISITE', true);

Зайдите в Инструменты → Настройка сети. Выберите схему:

• Sub-domains: если у вас настроен wildcard DNS и вы хотите site.example.com.
• Sub-directories: если достаточно example.com/site.

Мастер покажет необходимые вставки в wp-config.php и .htaccess. Пример для субдоменов:

// wp-config.php (пример для субдоменов)
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
// Не задавайте WP_SITEURL/WP_HOME в multisite — используйте константы выше.

.htaccess для Apache (замените текущие правила WordPress):

# .htaccess для Multisite с субдоменами
# Если используется Apache, вставьте вместо стандартных правил WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# Добавочное правило для wp-.* и файлов — пропускаем напрямую
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule . - [L]

# Маршрутизация в index.php
RewriteRule . index.php [L]
</IfModule>

Для подкаталогов правила отличаются. Мастер установки покажет точную версию под вашу схему. Сохраняйте .htaccess в корне сайта, рядом с wp-config.php.

3) Вход и проверка

После перезапуска сети войдите снова. В верхнем меню появится пункт «Моя сеть». Создайте тестовый сайт и проверьте:

• Что админка и фронтэнд доступны по субдомену/подкаталогу.
• Что загружаемые файлы сохраняются в wp-content/uploads/sites/<ID>.

HTTPS и принудительный редирект

Даже с валидным сертификатом часть запросов может приходить на http. На виртуальном хостинге удобнее всего принудить HTTPS через .htaccess.

# Принудительный HTTPS и www-нормализация (пример)
<IfModule mod_rewrite.c>
RewriteEngine On

# Принудительно без www (или адаптируйте под вашу политику)
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]

# Принудительный HTTPS
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

Для Nginx-проксирующих инсталляций редирект обычно выполняет сам Nginx. На чистом виртуальном хостинге с Apache это делает .htaccess. После включения HTTPS проверьте отсутствие смешанного контента в темах/плагинах.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Cookie, домены и авторизация

В Multisite WordPress сам корректно настраивает cookie-домены под субдомены, если вы не переопределяете константы. Частая ошибка — вручную поставить COOKIE_DOMAIN или WP_SITEURL и получить проблемы с авторизацией или бесконечными редиректами. Рекомендация: не задавайте эти константы без необходимости.

Для административной части включите SSL:

define('FORCE_SSL_ADMIN', true);

Если админка идёт за обратным прокси, убедитесь, что хостинг передаёт корректный заголовок X-Forwarded-Proto: https, иначе WordPress может «думать», что соединение не защищено и зациклиться на редиректах. На классическом виртуальном хостинге без внешнего прокси это не требуется.

Регистрация сайтов и пользователей

В «Моя сеть → Настройки» задайте правила:

• Кто может создавать сайты — только администратор сети или все пользователи.
• Ограничения доменов e-mail для регистрации.
• Белый/черный списки имён сайтов (актуально для подкаталогов, чтобы не пересекаться с системными путями).

Крон: как запускать задачи по расписанию

В Multisite фоновые задачи масштабируются по числу сайтов. Привычный совет — отключить псевдокрон и завести системный:

// wp-config.php
define('DISABLE_WP_CRON', true);

В панели хостинга создайте Cron на каждые 5 минут. Команда зависит от расположения PHP и сайта; общая форма:

/usr/bin/php -q /home/USER/www/example.com/wp-cron.php >/dev/null 2>&1

Если у вас несколько сетей или нестандартный путь, скорректируйте. При высокой нагрузке можно запускать отдельные задачи через WP-CLI, но на виртуальном хостинге это не всегда доступно.

Производительность и кэш

Multisite добавляет уровень маршрутизации и больше запросов к БД на некоторых страницах. На виртуальном хостинге обратите внимание на:

• Кэширование страниц плагином, который поддерживает режим сети. Включать по сайтам осознанно.
• Минификация и критический CSS — уменьшите TTFB и нагрузку.
• Оптимизация медиа: WebP/AVIF, ленивая загрузка, генерация миниатюр по потребности.
• Оптимизация опкэша PHP и автозагрузчика (Composer autoload classmap authoritative, если применимо).

Объект-кэш Redis на виртуальном хостинге встретится не всегда; если провайдер поддерживает, включайте сетью, но учитывайте ограничение по памяти и количеству ключей. При росте трафика и необходимости тонкой настройки стеков подумайте о миграции на облачный VDS.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Особенности подкаталогов

Сеть подкаталогов проще в SSL/DNS, но имеет нюансы:

• Нельзя создать сайт с путём, совпадающим с реальной директорией/файлом на диске.
• Если изначальный сайт старше 30 дней, WordPress блокирует переключение на подкаталоги без дополнительных действий — это защита от конфликтов URL. Готовьте миграционный план.

Домены для отдельных сайтов сети

Современный WordPress умеет домаппинг без плагинов: в «Сайты → Редактировать сайт → Адрес сайта (URL)» укажите нужный домен. Для подмены на внешний домен проверьте, что:

• DNS домена или субдомена указывает на ваш хостинг.
• Сертификат покрывает этот домен (SAN или отдельный сертификат).
• Политика редиректов .htaccess не ломает карту доменов.

Если доменов не хватает или требуются новые зоны под регионы, используйте регистрацию доменов. Для стратегии захвата и защиты имён пригодится обзор про защиту бренда доменами и субдоменами.

Типичные ошибки и их устранение

404 на новых сайтах

• На Apache: проверьте корректную вставку правил .htaccess именно в корне сайта и права на файл.
• На Nginx-хостинге без .htaccess: перепроверьте, проксирует ли панель правильные правила переписывания (обычно на shared всё уже учтено).

Бесконечные редиректы между http и https

• Дублирование правил: и панель, и .htaccess одновременно принуждают HTTPS. Уберите одно.
• Прокси без X-Forwarded-Proto. Для классического shared это редко, но проверьте.
• Жёстко заданные WP_HOME/WP_SITEURL. В Multisite их не задают.

SSL: «сертификат не покрывает домен»

• Проверьте, что в сертификате есть оба: example.com и *.example.com.
• Wildcard не покрывает второй уровень: *.sub.example.com — нужен отдельный SAN или второй wildcard.

Куки: вылет из админки на субдоменах

• Удалите переопределение COOKIE_DOMAIN и WP_SITEURL из wp-config.php.
• Убедитесь, что домен в настройках сайта точно совпадает с используемым.

Медиа: ошибки загрузки

• Проверьте права на wp-content/uploads и подпапки sites/<ID>.
• Увеличьте upload_max_filesize и post_max_size в .user.ini или панели.

Безопасность сети

• Ограничьте регистрацию пользователей и сайтов, если сеть не публичная.
• Включите обновления ядра и плагинов по расписанию, тестируйте на отдельном сайте сети перед глобальным включением.
• Минимизируйте список сетевых плагинов; по возможности включайте их на конкретных сайтах.
• Добавьте заголовки безопасности через .htaccess или панель (HSTS после полной уверенности, что всё работает по HTTPS).

# Минимальные заголовки безопасности через Apache (.htaccess)
<IfModule mod_headers.c>
Header always set X-Frame-Options SAMEORIGIN
Header always set X-Content-Type-Options nosniff
Header always set Referrer-Policy no-referrer-when-downgrade
# HSTS включайте только убедившись, что все субдомены на HTTPS
# Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>

Миграции: субдомены ↔ подкаталоги

Смена схемы в живой сети — больной сценарий: меняется структура URL, кэш, иногда и SEO. Если всё же нужно:

• Сделайте полные бэкапы, протестируйте на копии.
• Сформируйте таблицу 301-редиректов.
• Переиздайте SSL (возможно, уйдёте от wildcard к обычному, или наоборот).
• Проверьте правила .htaccess и базовые константы в wp-config.php.

Чек-лист перед запуском в прод

1. PHP 8.2/8.3, лимиты ресурсов выставлены, кэш-плагин протестирован в режиме сети.
2. DNS: A/AAAA для домена и wildcard, TTL адекватный, записи распространяются.
3. SSL: сертификат покрывает и корень, и *.example.com. Автопродление проверено.
4. wp-config.php: заданы MULTISITE, SUBDOMAIN_INSTALL, DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE, без лишних WP_SITEURL/COOKIE_DOMAIN.
5. .htaccess: правила переписи именно для выбранной схемы, редирект на HTTPS не дублируется.
6. Cron: системный запущен, WP_CRON отключен.
7. Админ-аккаунты, роли и политика регистрации выверены.

Ответы на «а если»

А если хостер не даёт wildcard SSL? Можно работать на SAN-сертификатах, если число субдоменов небольшое и редко меняется. Для динамической сети лучше сменить подход: подкаталоги вместо субдоменов или перенести SSL-терминацию на уровень, где wildcard доступен.

А если DNS управляется внешним провайдером? Ничего страшного: для wildcard важны только записи в зоне. Важно лишь, чтобы ACME-валидация wildcard была с вашей стороны реализуема (ручной TXT или через API-провайдера DNS).

А если провайдер на виртуальном хостинге использует Nginx без .htaccess? Тогда правила переписывания уже зашиты в шаблоны. Вам остаётся корректно настроить wp-config.php, DNS и SSL. Редиректы на HTTPS лучше включать штатными настройками панели.

Итоги

Запустить WordPress Multisite на виртуальном хостинге абсолютно реально: ключ к успеху — верно выбрать схему (субдомены или подкаталоги), заранее подготовить DNS и сертификаты, строго следовать подсказкам мастера сети и не переопределять лишнего в wp-config.php. Wildcard SSL снимает рутину с выпуском сертификатов для каждого субдомена и делает масштабирование сети безболезненным. Соблюдая описанные практики, вы избежите 90% типичных ловушек: 404 на новых сайтах, редирект-ловушек и проблем с cookie. Остальные 10% решаются внимательной проверкой .htaccess, констант и диагностики на стороне PHP и панели хостинга.