Сколько сайтов WordPress может разместить сервер в 2026 году?

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

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

Последнее обновление — 22 октября 2026 года. Дата релиза WordPress сверена с официальным объявлением о выпуске 7.1.3; поведение Multisite и PHP-FPM проверено по документации WordPress и PHP, указанной ниже.

Сначала определите, что считается сайтом

Под одним словом «сайт» нередко понимают разные объекты: доменное имя, отдельную установку WordPress или сайт внутри сети WordPress Multisite. Это не взаимозаменяемые единицы. Несколько доменов могут вести на одну установку, одна установка может обслуживать несколько виртуальных узлов, а сеть Multisite объединяет отдельные сайты под общим управлением.

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

Можно ли назвать универсальное количество сайтов для одного сервера? Нет. Само число доменов не показывает, сколько PHP-запросов, фоновых задач и обращений к базе данных возникает одновременно. Оно также не говорит, допустимо ли для владельца, чтобы один сбой затронул остальные проекты.

В Nginx имена виртуальных серверов сопоставляются с запросами через директиву server_name; наличие нескольких доменов само по себе не означает, что для каждого необходим отдельный сервер. Это правило маршрутизации, а не гарантия изоляции процессов или данных. Подробности есть в документации Nginx о server_names.

Нагрузка и последствия различаются по типу сайта

Портфолио компаний, редакционные сайты, интернет-магазины и API могут использовать один и тот же движок, но по-разному нагружать систему. Среднее число просмотров за день не отражает одновременную активность, обработку изображений, поиск по каталогу, выполнение планировщика и нагрузку на базу данных.

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

Повлияет ли один сайт на остальные при размещении на общей машине? Да, если они конкурируют за процессор, память, диск или ресурсы базы данных; также влияние возможно через общие учётные данные и ошибки администрирования. Кеширование страниц или CDN могут уменьшить число обращений к серверу в отдельных сценариях, но не устраняют конкуренцию за ресурсы при динамических запросах, очистке кеша и операциях записи.

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

Разделение процессов важнее общей цифры сайтов

Сайты с оформлением заказа, изменением запасов или API-запросами лучше не оценивать по правилам, подходящим для спокойных страниц с текстом. Такие операции записывают данные, активнее используют базу и могут иметь более строгие требования к доступности. Их следует отделять от обычного контента хотя бы на уровне системного пользователя, PHP-FPM pool и учётной записи базы данных.

Однако отдельный PHP-FPM pool не является полноценной границей безопасности. Официальная документация PHP описывает настройки пулов и пользователей, но наличие отдельного пула само по себе не обеспечивает изоляцию файлов, ядра системы или всех зависимостей. Это организационный и операционный барьер, а не замена дополнительному разделению, если последствия доступа или сбоя критичны. Параметры описаны в руководстве PHP по конфигурации PHP-FPM.

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

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

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

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

Проверка ёмкости как последовательность контрольных этапов

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

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

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

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

• [ ] Разделите перечень на отдельные установки WordPress и сайты в Multisite.
• [ ] Отметьте интернет-магазины, API, сайты с особыми правами и проекты с независимыми окнами обслуживания.
• [ ] Запишите базовые показатели в обычные и загруженные периоды, включая ошибки и время ответа.
• [ ] Проверьте характерные пользовательские операции и фоновые задания в тестовой среде.
• [ ] Настройте раздельные системные и базовые учётные записи там, где это нужно по модели доступа.
• [ ] Зафиксируйте признаки остановки совместного размещения: устойчивое вытеснение ресурсов, повторяющиеся ошибки соседних сайтов или неприемлемые последствия общего сбоя.

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

Аппаратная конфигурация не обещает вместимость

У CloudUDP есть страница тарифов и конфигураций, где следует сверять доступные параметры и стоимость перед закупкой. В линейке представлены выделенные AMD EPYC с 32 ядрами и 64 потоками, варианты памяти 128 или 256 ГБ и два NVMe-накопителя по 1 ТБ; доступны варианты пропускной способности 250 Мбит/с, 1 Гбит/с и 2 Гбит/с без ограничения трафика. Эти характеристики описывают оборудование и сетевую опцию, но не позволяют перевести число ядер, объём диска или полосу в гарантированное число сайтов.

При выборе оценивайте, какой ресурс ограничивает конкретный набор проектов: память при активных PHP-процессах, CPU при динамической генерации, диск при росте медиа и баз либо пропускная способность при передаче контента. Для размещения клиентов раздельно спланируйте права доступа и резервное копирование; если команда входит на сервер через SSH или работает с Windows через RDP, порядок доступа следует сверить с руководством по подключению.

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

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