WordPress Multisite: хостинг, поддомены и подкаталоги

WordPress Multisite позволяет запустить много сайтов на одной установке WordPress: один набор файлов ядра, один каталог плагинов и тем, одна база данных, один пул процессов PHP и экран Network Admin над всем этим. Он подходит, когда сайты принадлежат одному владельцу, похожи друг на друга и управляются вместе: сайты факультетов университета, франшиза, языковые версии, магазин с региональными витринами. Он не подходит, когда сайты никак не связаны, принадлежат разным клиентам или требуют разных плагинов и разного уровня риска. Выбор, который дорого отменять, - подкаталог (example.com/shop/) или поддомен (shop.example.com). Дальше разберём, как его сделать, чего Multisite требует от хостинга и где он тихо усложняет жизнь по сравнению с несколькими отдельными установками.

Что такое Multisite на самом деле#

В обычной установке WordPress в базе данных один набор таблиц: wp_posts, wp_options, wp_comments и так далее. Multisite сохраняет эту схему для первого сайта и добавляет нумерованную копию таблиц каждого сайта: wp_2_posts, wp_2_options, wp_3_posts и т. д. У каждого сайта примерно дюжина собственных таблиц. Несколько таблиц общие для всей сети:

• wp_users и wp_usermeta - один список учётных записей на всю сеть. У человека один логин, а роль на каждом сайте выдаётся отдельно.
• wp_blogs и wp_site - реестр сайтов и сетей.
• wp_sitemeta - настройки всей сети, включая список суперадминистраторов и перечень плагинов, активированных на уровне сети.
• wp_signups и wp_registration_log - используются, когда люди могут сами регистрировать сайты.

Файлы делятся так же. Код общий: один wp-content/plugins, один wp-content/themes, одна копия ядра. Загрузки раздельные: каждый сайт, кроме первого, пишет в wp-content/uploads/sites/<id>/. Настройки, содержимое, меню, виджеты и активная тема - у каждого сайта свои. Какие плагины установлены - решение сети, а какие из них активны - решение сайта, если только суперадминистратор не включил их для всей сети.

В этом общем и весь смысл. Вы обновляете WordPress один раз, исправление уязвимости в плагине появляется на всех сайтах одновременно, а новый сайт - это форма, а не новый сервер. Здесь же и весь риск, о нём ниже.

Терминология путает. Сеть (network) - вся установка целиком. Сайт (site) - один её участник. Суперадминистратор (super admin) - роль уровня сети: она устанавливает плагины и темы, создаёт и удаляет сайты и правит любых пользователей. Обычный администратор сайта в сети Multisite вообще не может устанавливать плагины и темы, а только включать те, что суперадминистратор сделал доступными. Клиенты, которые рассчитывают ставить собственные плагины, часто остаются недовольны.

Поддомены или подкаталоги#

Этот выбор делается один раз, при настройке сети, и позже WordPress не даст изменить его из интерфейса. Переход потом означает правку wp-config.php, правил перезаписи и адресов в таблицах каждого сайта, плюс много проверок, поэтому решайте сразу.

Практические различия такие.

DNS и сертификаты. Сети на подкаталогах не нужно ничего, кроме DNS-записи, которая у вас уже есть для основного домена, и один сертификат покрывает все сайты. Сети на поддоменах нужно, чтобы имя каждого сайта указывало на сервер и чтобы каждое имя покрывал сертификат. Обычно для этого делают wildcard-запись DNS *.example.com на тот же адрес, что и основной домен, и wildcard-сертификат либо сертификат на каждое имя. Wildcard-сертификаты обычно выпускают через проверку по DNS, а для неё нужно, чтобы у вашего DNS-провайдера был API, который сможет вызвать ваш инструмент. О том, что wildcard-запись покрывает, а что нет, читайте в DNS-записях простыми словами, а об общей идее «одно имя на сервис» - в поддоменах для серверов.

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

Конфликты путей. В сети на подкаталогах первый сегмент пути принадлежит Multisite. Сайт с именем blog занимает /blog/, поэтому страница, рубрика или тип записи на главном сайте с тем же слагом blog с ним столкнётся. WordPress не даёт при создании сайта взять часть зарезервированных имён (wp-admin, files, page, feed и подобные), но не может знать обо всех слагах, которые вы использовали в содержимом главного сайта. Поддомены этой проблемы лишены.

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

Порты и нестандартные адреса. Multisite ненадёжно работает, если адрес сайта содержит нестандартный порт, и экран настройки сети об этом предупредит. Запускайте его на стандартных портах за прокси.

Практическое правило, которое работает: если вы можете настроить wildcard-запись и сертификат для неё, а сайты в голове посетителя отдельные, берите поддомены; если сайты - разделы одного целого или вы ограничены одной DNS-записью, берите подкаталоги. И при любом выборе каждому сайту позже можно дать собственное доменное имя, как описано в разделе про domain mapping.

Включаем Multisite#

Начинайте с работающего одиночного сайта и свежей резервной копии. Как дойти до этого состояния с нуля, рассказано в статье установка WordPress вручную.

1. Добавьте одну строку в wp-config.php, выше комментария, который просит прекратить редактирование:

define( 'WP_ALLOW_MULTISITE', true );

1. В панели управления отключите все плагины (плагины, которые меняют перезапись адресов или перенаправления, мешают следующему шагу; потом включите их обратно).
2. Откройте Tools, затем Network Setup. WordPress предложит выбрать поддомены или подкаталоги, название сети и почту суперадминистратора.
3. Нажмите Install. Сам WordPress изменения не записывает. Он показывает два блока кода для вставки: константы для wp-config.php и правила перезаписи для .htaccess или веб-сервера.

Для сети на поддоменах блок для wp-config.php выглядит так, его нужно вставить сразу после строки WP_ALLOW_MULTISITE:

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 );

Для сети на подкаталогах отличие только в SUBDOMAIN_INSTALL: там false. Именно эта константа - весь выбор между поддоменами и подкаталогами в коде, и поэтому изменить его позже можно, но никогда не одной строкой: каждый адрес в базе записан под прежнюю схему.

Затем замените стандартные правила перезаписи WordPress. На Apache в .htaccess для сети на подкаталогах используется:

RewriteEngine OnRewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]RewriteBase /RewriteRule ^index\.php$ - [L]# add a trailing slash to /wp-adminRewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]RewriteCond %{REQUEST_FILENAME} -f [OR]RewriteCond %{REQUEST_FILENAME} -dRewriteRule ^ - [L]RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]RewriteRule . index.php [L]

Для сети на поддоменах из этих правил убирается необязательный префикс с именем сайта:

RewriteEngine OnRewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]RewriteBase /RewriteRule ^index\.php$ - [L]RewriteCond %{REQUEST_FILENAME} -f [OR]RewriteCond %{REQUEST_FILENAME} -dRewriteRule ^ - [L]RewriteRule ^(wp-(content|admin|includes).*) $1 [L]RewriteRule ^(.*\.php)$ $1 [L]RewriteRule . index.php [L]

На nginx нет .htaccess. Сети на поддоменах не нужно ничего особенного, кроме try_files $uri $uri/ /index.php?$args; и server_name, подходящего под wildcard, а сети на подкаталогах добавляется блок, который убирает префикс сайта из путей админки и PHP:

if (!-e $request_filename) {    rewrite /wp-admin$ $scheme://$host$uri/ permanent;    rewrite ^(/[^/]+)?(/wp-.*) $2 last;    rewrite ^(/[^/]+)?(/.*\.php) $2 last;}

Какой веб-сервер у вашего хостинга и читает ли он вообще .htaccess - это первое, что нужно выяснить до начала. Именно на шаге с правилами перезаписи большинство неудачных настроек Multisite и ломается: все подсайты отдают 404 главного сайта, а админка уходит в бесконечное перенаправление.

1. Сохранив оба файла, войдите заново (cookie меняются), затем включите плагины из Network Admin.

Если интерфейс не нужен, WP-CLI делает всё преобразование одной командой из каталога сайта:

$ wp core multisite-convert --title="Example Network" --subdomains$ wp site list

Для сети на подкаталогах уберите --subdomains. Команда сама запишет константы и создаст сетевые таблицы; правила перезаписи всё равно должны быть на месте.

Wildcard DNS для сетей на поддоменах#

Чтобы shop.example.com открылся, имя должно указывать на сервер. Есть два варианта: создавать A-запись вручную для каждого нового сайта или один раз создать wildcard-запись:

example.com.      3600  IN  A  203.0.113.10*.example.com.    3600  IN  A  203.0.113.10

Wildcard подходит под любое имя глубиной в одну метку, у которого нет своей записи, так что shop.example.com и anything.example.com оба разрешатся, а a.b.example.com - нет. Явная запись для mail.example.com или www.example.com всегда приоритетнее wildcard, так что почту и другие сервисы можно держать на отдельных адресах.

Сервер тоже должен отвечать на эти имена. WordPress маршрутизирует по заголовку Host: когда приходит запрос на shop.example.com, он ищет имя хоста в wp_blogs и загружает этот сайт. Значит, веб-сервер должен отправлять все такие имена в один каталог WordPress: через виртуальный хост по умолчанию или запись server_name *.example.com. Проверьте это до создания настоящих сайтов:

$ dig +short shop.example.com203.0.113.10$ curl -sI https://shop.example.com/ | head -n 1

Если первая команда ничего не выводит, wildcard-записи нет или она ещё не распространилась. Если выводится адрес, но вторая команда показывает предупреждение о сертификате, с DNS всё в порядке, а имя сертификатом не покрыто.

На RE:NODE в тарифы приложений и веб-хостинга входит слот обратного прокси: вы направляете A-запись на показанный адрес, и сертификат выпускается и продлевается автоматически. Это относится к сертификату для имён, которые вы там подключили. Мы не утверждаем, что wildcard-имена или wildcard-сертификаты поддерживаются, и не публикуем, сколько слотов прокси в каждом тарифе, поэтому если вы планируете сеть на поддоменах с большим числом имён, спросите у поддержки до начала работы. Сеть на подкаталогах этот вопрос снимает: имя всего одно. Как устроена часть про сертификат, объясняет статья ваш домен и его сертификат.

Создание сайтов, пользователи и domain mapping#

Когда сеть работает, новые сайты создаются в Network Admin: Sites, затем Add New, или через WP-CLI:

$ wp site create --slug=shop --title="Shop" --email=admin@example.com$ wp site list --fields=blog_id,url,registered$ wp super-admin add alice$ wp plugin activate wordpress-seo --network$ wp theme enable twentytwentyfive --network

--slug становится поддоменом или подкаталогом в зависимости от типа сети. wp theme enable --network делает тему доступной всем сайтам, а обычная команда wp theme enable <theme> --url=shop.example.com - только одному.

В Network Admin, в разделе Settings, находятся самые важные параметры:

• Registration: отключена, только учётные записи, вошедшие пользователи могут регистрировать сайты или и то и другое. Оставьте отключённой, если вы не запускаете публичный сервис: открытая регистрация сайтов быстро привлекает спам-сайты.
• Upload file types and size: сетевой Max upload file size задаётся здесь (поле fileupload_maxk, значение по умолчанию маленькое, 1500 КБ) отдельно от upload_max_filesize в PHP. Действуют оба ограничения, и срабатывает меньшее. См. настройки php.ini, которые важны.
• Menu settings: видят ли администраторы сайтов меню Plugins вообще.

Одна константа, которую стоит задать сразу, определяет, куда попадёт посетитель, запросивший несуществующий сайт:

define( 'NOBLOGREDIRECT', 'https://example.com' );

Без неё опечатка в поддомене покажет типовую страницу «такого сайта не существует».

Domain mapping - это присвоение сайту собственного домена, www.shop-example.net, вместо имени под доменом сети. Начиная с WordPress 4.5 это встроено и плагин не нужен: в Network Admin откройте сайт на редактирование и замените Site Address (URL) на новый домен. Остальное происходит вне WordPress:

1. Направьте A-запись нового домена на тот же сервер.
2. Убедитесь, что веб-сервер отвечает на это имя и сертификат его покрывает.
3. Измените Site Address в разделе Sites, Edit в Network Admin.
4. Выполните поиск с заменой в таблицах самого сайта, потому что в содержимом всё ещё старые адреса:

$ wp search-replace 'shop.example.com' 'www.shop-example.net' \    --url=shop.example.com --network --dry-run

Сначала запустите с --dry-run, посмотрите на количество замен, затем запустите без него. В сети на поддоменах отдельный домен означает и отдельную cookie входа, так что пользователи, вошедшие на домене сети, там не вошли. В некоторых конфигурациях также добавляют define( 'COOKIE_DOMAIN', '' );, чтобы WordPress не навязывал cookie родительскому домену.

Во что Multisite обходится по ресурсам#

Multisite не уменьшает расход ресурсов на один сайт сколько-нибудь заметно. Он экономит дублирование файлов ядра, плагинов и тем на диске и труд по поддержке многих установок. Всё остальное он делает общим, а общее - значит спорное.

Процессы PHP и память. Один сайт или сто, WordPress загружается на каждый запрос с активными плагинами и темой того сайта, который обслуживается. Память на запрос зависит от того, что включено на этом сайте, а не от размера сети. Но все сайты берут ресурсы из одного пула воркеров PHP и одного лимита памяти. Один загруженный сайт или медленный плагин на одном сайте могут занять воркеры, нужные остальным. В статье сколько RAM нужно WordPress даны цифры на один сайт; для сети складывайте загруженные сайты, а не считайте все подряд, и оставляйте запас на пик самого нагруженного.

База данных. Каждый сайт добавляет около дюжины таблиц, так что сеть из 200 сайтов содержит больше двух тысяч таблиц. Для MySQL это нормально, но инструменты и плагины, которые обходят все таблицы, - плагины резервного копирования, поиск с заменой по всей сети, некоторые скрипты миграции - работают медленнее. У самого WordPress есть защита для больших сетей: когда в сети больше 10 000 сайтов или пользователей (порог wp_is_large_network, его можно менять фильтром), он пропускает некоторые сетевые запросы подсчёта, которые иначе были бы слишком медленными. На небольшом тарифе вы вряд ли упрётесь в этот предел, но эффект от десяти тысяч строк автозагрузки в wp_options почувствуете гораздо раньше. Каждый сайт при каждом запросе загружает свои автозагружаемые опции, поэтому плагин, раздувающий wp_options на одном сайте, замедляет только этот сайт, а вот общие таблицы wp_users и wp_usermeta растут вместе со всей сетью и затрагиваются при каждом входе.

Объектный кэш. Постоянный объектный кэш помогает Multisite больше, чем одиночному сайту, потому что каждый запрос делает хотя бы несколько обращений к общим сетевым таблицам. Ключи кэша включают идентификатор сайта, так что хороший плагин объектного кэша разделяет сайты. Настройку описывает статья объектный кэш Valkey для WordPress, а скорость WordPress и кэширование рассказывает о кэше страниц, который в сети должен учитывать сеть, иначе вместо страниц одного сайта по имени другого будут отдаваться чужие.

WP-Cron. У каждого сайта своё расписание задач, оно хранится в собственной таблице wp_<id>_options, и WP-Cron срабатывает от просмотров страниц каждого сайта по отдельности. Тихий сайт в сети из пятидесяти может днями не публиковать запланированные записи. Исправление через настоящий cron из статьи WP-Cron или настоящий cron остаётся в силе, но с одним изменением: запускать нужно просроченные задачи для каждого сайта, а не для одного. При установленной DISABLE_WP_CRON это делает одна строка cron:

$ wp site list --field=url | xargs -I % wp --url=% cron event run --due-now

Запускайте её каждые пять минут. Каждый сайт - это отдельная загрузка WordPress, так что в сети из пятидесяти сайтов она выполняется заметное время и на это время нагружает CPU. Разнесите запуски по времени или разбейте список, если доля CPU в вашем тарифе небольшая. Вкладка Schedules в панели RE:NODE - место, где настраивается задача в стиле cron на тарифах, где она есть.

Диск и загрузки. Папки загрузок растут по каждому сайту и не являются общими, так что один сайт с большой медиатекой может заполнить диск всем остальным. В Network Admin можно задать квоту места для загрузок на сайт (blog_upload_space, по умолчанию 100 МБ); стоит включить её, если вы отдаёте сайты другим людям.

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

Когда Multisite не нужен#

Multisite привлекает тем, что выглядит коротким путём к управлению многими сайтами. Это компромисс, и для многих задач - неудачный.

Сайты принадлежат разным людям. Общий каталог плагинов, общая таблица пользователей и общая роль суперадминистратора означают, что тот, кто управляет сетью, управляет каждым сайтом. Клиент, которому нужно поставить свой плагин, не сможет. Клиент, которому нужна тестовая копия, другая версия PHP или восстановление только его сайта, обнаружит, что ничто из этого не делается просто.

Один сайт намного рискованнее остальных. Уязвимый плагин, установленный в сети, установлен везде, даже если пользуется им один сайт, а скомпрометированная учётная запись суперадминистратора - это скомпрометированная сеть. Один заражённый сайт способен добраться до общей базы и общего каталога кода. Защита здесь важнее; начните со статьи защита WordPress.

Нужно восстановление отдельного сайта. Резервная копия сети Multisite - это копия одной базы и одного дерева файлов. Чтобы вернуть один сайт ко вчерашнему состоянию, его таблицы и папку uploads/sites/<id>/ приходится выгружать вручную. WP-CLI делает выгрузку терпимой:

$ wp db export shop-site.sql --tables=$(wp db tables --scope=blog --url=shop.example.com --format=csv)

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

Сайтам нужно разное ПО. Одна версия WordPress, одни версии плагинов, одна версия PHP для всех. Если одному сайту нужен старый плагин, который ломается на современном PHP, он тормозит остальных. Если одному нужен плагин, несовместимый с Multisite (таких много, особенно тех, что пишут собственные таблицы или рассчитывают на единственную wp_options), использовать его нельзя вовсе. Прежде чем решаться, проверьте в документации каждого плагина, поддерживается ли Multisite.

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

Вам нужна просто удобная админка. Если настоящая цель - обновлять много сайтов в одном месте, это дают WP-CLI по SSH или панель управления, и при этом ничего не приходится делить. Отдельные установки, обновляемые скриптом, менее изящны, чем Multisite, и гораздо проще изолируются.

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

На RE:NODE путь с отдельными установками дёшево проверить. Линейка WordPress ставит WordPress с wp-config.php, уже настроенным на собственную базу MySQL, и начинается от $5 в месяц, а у каждого тарифа свои слоты резервных копий и своя панель. Несколько маленьких тарифов дают восстановление по сайтам, собственные лимиты CPU и памяти на каждый и отсутствие общей зоны поражения, ценой того, что обновлять придётся каждый. Перенос сайта между установками описан в статье перенос WordPress на новый хостинг, она пригодится и если вы позже решите разделить сеть.

Перенос сайта в сеть и из неё#

Перенос сайтов - момент, когда Multisite перестаёт быть аккуратным. Существующий одиночный сайт можно импортировать встроенными Tools, Export и Import, которые переносят записи, страницы и ссылки на медиафайлы, либо плагином, переносящим таблицы. Поскольку префикс таблиц меняется на wp_<id>_, простое копирование базы не сработает: нужно переименовать таблицы, обновить строку wp_<id>_options, в которой хранятся роли пользователей (wp_<id>_user_roles), и исправить адреса.

В обратную сторону сайт покидает сеть так: выгружаются его таблицы, они переименовываются обратно на префикс по умолчанию, папка uploads/sites/<id>/ копируется в wp-content/uploads/, а затем выполняется поиск с заменой путей и адресов. Пользователей придётся создать заново, потому что они живут в общей таблице wp_users. Продумайте это заранее: это настоящая цена выбора Multisite для сайтов, которые позже могут стать независимыми.

Устранение неполадок#

Все подсайты показывают главный сайт или 404. Правила перезаписи остались от одиночного сайта или веб-сервер не направляет имя хоста в этот каталог WordPress. Примените заново блок из Network Setup для вашего типа сети и убедитесь, что виртуальный хост отвечает на wildcard.

Цикл перенаправлений на `/wp-admin/`. Обычно виноваты cookie. Проверьте, что DOMAIN_CURRENT_SITE в точности совпадает с хостом в адресной строке (с www или без), очистите cookie домена и убедитесь, что define( 'COOKIE_DOMAIN', '' ); не задан значением, которое не совпадает.

«Error establishing a database connection» только на одном подсайте. Таблицы сайта отсутствуют или неверен префикс - чаще всего после восстановления вручную. Проверьте, что wp db tables --url=shop.example.com перечисляет таблицы wp_<id>_. Если не работает вся сеть, начните со статьи белый экран и ошибки 500 в WordPress.

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

Новые сайты на поддоменах выдают предупреждение о сертификате. DNS работает, но сертификат покрывает только основной домен. Либо расширьте сертификат до wildcard, либо добавьте каждое имя в него до создания сайта.

FAQ#

Можно ли позже преобразовать одиночный сайт WordPress в Multisite?

Да. Добавьте WP_ALLOW_MULTISITE, запустите Tools, Network Setup (или wp core multisite-convert) и вставьте сгенерированные константы и правила перезаписи. Сначала сделайте резервную копию. Сети на подкаталогах предлагаются только для установок младше месяца, поэтому более старый сайт превращается в сеть на поддоменах, если не поправить это вручную.

Можно ли потом переключиться между поддоменами и подкаталогами?

Не из интерфейса. Нужно менять SUBDOMAIN_INSTALL, правила перезаписи и каждый сохранённый адрес на каждом сайте. В сети с настоящим содержимым это целый проект, так что считайте выбор окончательным.

Ускоряет ли Multisite WordPress?

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

Может ли у каждого сайта быть своё доменное имя?

Да, во встроенном domain mapping начиная с WordPress 4.5. Направьте новый домен на сервер, убедитесь, что веб-сервер и сертификат его покрывают, затем измените Site Address в разделе Sites в Network Admin и выполните поиск с заменой.

Сколько сайтов может вместить сеть?

В самом ПО жёсткого предела нет. На практике пределы задают база данных (около дюжины таблиц на сайт), общие воркеры PHP и память, а также время, которое занимают сетевые задачи вроде резервного копирования и cron. Когда активных сайтов больше нескольких сотен, задумайтесь, не нужен ли отдельный сервер базы данных и настроенное кэширование.

Работают ли плагины в Multisite?

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