Как выбрать VPS для WordPress в 2026: RAM, PHP, MySQL, кеш и безопасность

Для WordPress нельзя выбирать VPS только по числу посетителей или абстрактно под CMS. Блог с полным page cache и интернет-магазин с личными кабинетами при одинаковом трафике создают разную нагрузку.

Базовые ориентиры выглядят так:

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

Для большинства проектов подойдёт стек:

• Nginx или Apache;
• PHP-FPM;
• OPcache;
• MySQL или MariaDB;
• page cache;
• Redis object cache для динамических сайтов;
• CDN и WAF;
• Внешние бэкапы;
• staging-копия для обновлений.

Минимальные 1 GB RAM подходят только для очень простого сайта с небольшим трафиком. На таком VPS память быстро заканчивается при обновлении плагинов, импорте данных, работе конструктора или всплеске посещаемости.

Для обычного WordPress разумным минимумом лучше считать 2 GB RAM, а для WooCommerce и тяжёлых визуальных конструкторов — от 4 GB и больше, контролируя наличие запаса.

Кеширование обязательно. Без него каждый запрос снова запускает PHP и обращается к базе данных. Page cache снижает нагрузку на публичные страницы, OPcache ускоряет PHP, а Redis уменьшает количество повторных запросов к базе.

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

На нагруженном сайте стандартный wp-cron лучше заменить системным cron. Иначе фоновые задачи запускаются при посещениях и могут создавать дополнительную нагрузку в момент пика.

До запуска также нужно:

• Ограничить или отключить XML-RPC, если он не используется;
• Включить автоматические бэкапы;
• Настроить WAF и CDN;
• Регулярно обновлять WordPress, темы и плагины;
• Проверять изменения на staging;
• Следить за CPU, RAM, диском и медленными запросами.

Главная ошибка — выбирать VPS впритык. Лучше оставить запас по RAM и CPU хотя бы на обновления, резервное копирование, импорт данных и кратковременные всплески нагрузки.

От чего зависят требования WordPress к VPS

Посещаемость и количество одновременных запросов

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

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

Также имеет значение, сколько запросов создаёт одна страница. WordPress может обращаться к PHP, базе данных, внешним API и файловой системе несколько раз за одно открытие.

Снизить нагрузку помогают page cache, CDN и оптимизированная тема. Если готовая HTML-страница отдаётся из кеша, серверу не приходится заново выполнять PHP и запросы к базе для каждого посетителя.

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

Тема, плагины и конструкторы страниц

Лёгкая тема с несколькими проверенными плагинами обычно требует меньше CPU и RAM, чем сайт с большим набором расширений и визуальным конструктором.

Elementor, WPBakery и похожие инструменты добавляют сложную разметку, дополнительные стили, скрипты и динамические запросы. Это влияет не только на скорость браузера, но и на работу PHP во время редактирования и генерации страниц.

Особенно заметную нагрузку могут создавать:

• Плагины статистики;
• Поиск и фильтрация;
• Резервное копирование на самом сервере;
• Импорт и экспорт;
• Сканеры безопасности;
• Генерация изображений;
• Связанные записи и сложные виджеты;
• Плагины с медленными SQL-запросами.

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

При этом кеш закрывает не все сценарии. Авторизованные пользователи и персонализированные страницы часто обходят полный page cache и создают динамическую нагрузку.

Динамические страницы и авторизованные пользователи

Блог и обычный корпоративный сайт можно почти полностью отдавать из page cache. WooCommerce, личные кабинеты, форумы и сервисы с авторизацией работают иначе.

Корзина, оформление заказа, профиль пользователя, история покупок и административная панель формируются индивидуально. Эти страницы нельзя бездумно кешировать как общий HTML для всех посетителей.

В результате каждый запрос запускает PHP и обращается к базе данных. Чем больше одновременных авторизованных пользователей, тем важнее становятся:

• Производительность отдельных ядер CPU;
• Объём RAM для PHP-FPM и базы;
• Скорость NVMe;
• OPcache;
• Redis object cache;
• Оптимизация SQL-запросов.

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

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

Запас ресурсов под обновления и пиковую нагрузку

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

Особенно чувствительна оперативная память. Её одновременно используют:

• Операционная система;
• Веб-сервер;
• Процессы PHP-FPM;
• MySQL или MariaDB;
• Redis;
• Антивирус и другие защитные инструменты;
• Резервное копирование;
• Панель управления, если она установлена.

При нехватке RAM сервер начинает активно использовать swap или завершать процессы через OOM killer. Для пользователя это проявляется как медленная загрузка, ошибки 502, 503 или недоступность базы данных.

Поэтому VPS лучше выбирать с запасом хотя бы 25–30% по памяти и CPU при обычной нагрузке. Для проектов с рекламными кампаниями, новостными всплесками и массовыми импортами запас должен быть ещё больше.

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

Конфигурации VPS для разных сайтов на WordPress

Блог и небольшой информационный сайт

Для простого блога или небольшого информационного сайта обычно достаточно 1–2 vCPU, 2 GB RAM и NVMe-диска.

Если страницы хорошо кешируются, а тема и плагины не перегружены, такой VPS спокойно справится с умеренной посещаемостью. Основную роль здесь играют page cache, OPcache и CDN: большая часть запросов может обслуживаться без повторного запуска PHP и обращения к базе.

Переходить на 4 GB RAM стоит, если активно используется визуальный редактор, резервные копии создаются прямо на сервере или сайт периодически получает заметные всплески трафика.

Корпоративный сайт обычно похож по нагрузке, но чаще содержит больше интеграций и служебных функций.

Корпоративный сайт

Для корпоративного сайта разумной отправной точкой будут 2 vCPU и 2–4 GB RAM. Диск, конечно же - NVMe.

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

Если проект используется как важный канал продаж, лучше сразу выбирать 4 GB RAM. Это даёт запас для обновлений, резервного копирования, импорта данных и фоновых задач.

Для магазина этого уже обычно недостаточно, поскольку большая часть запросов не может полностью обслуживаться из page cache.

WooCommerce

Для небольшого WooCommerce-магазина стоит начинать примерно с 4 vCPU и 6–8 GB RAM, не забывая про быстрое NVMe-хранилище.

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

Особенно важны производительность CPU, запас RAM для PHP-FPM и MySQL, Redis object cache и быстрый NVMe-диск. При большом каталоге также растёт нагрузка от поиска, фильтров, импорта и пересчёта товаров.

Если в магазине одновременно работают менеджеры, покупатели, платёжные интеграции и фоновые задачи, конфигурация без запаса быстро упрётся в память или CPU.

У новостного сайта нагрузка формируется иначе: она сильнее зависит от резких всплесков посещаемости.

Новостной или контентный проект

Для новостника или крупного контентного сайта обычно требуется от 4 vCPU и 8 GB RAM, а при высоком трафике — 8 vCPU и 16 GB RAM и выше. Диск исключительно NVMe.

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

Здесь особенно важны full-page cache, CDN, WAF и правильная работа кеша после обновления материалов. Если каждая новая статья массово очищает весь кеш, сервер может резко получить сотни динамических запросов одновременно.

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

Сайты на Elementor и WPBakery могут иметь меньший трафик, но всё равно требовать заметно больше ресурсов из-за самого конструктора.

Сайт на Elementor или WPBakery

Для проекта на Elementor или WPBakery разумным минимумом будут 2–4 vCPU и 4 GB RAM.

Конструкторы увеличивают объём PHP-кода, запросов к базе, CSS и JavaScript. Особенно тяжёлой может быть административная часть: редактирование страниц, сохранение шаблонов и генерация стилей требуют больше памяти, чем обычный просмотр сайта.

Если одновременно используются WooCommerce, мультиязычность, сложные формы и несколько крупных аддонов для конструктора, лучше ориентироваться на 6–8 GB RAM.

Page cache заметно ускоряет публичную часть, но не помогает редактору и авторизованным пользователям. Поэтому такой сайт может быстро открываться для посетителей и при этом тормозить в админке.

После разбора типов сайтов можно свести ориентиры по посещаемости, vCPU, RAM и диску в одну таблицу конфигураций.

Таблица конфигураций по посещаемости

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

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

До 1 000 посещений в сутки

Для небольшого блога или сайта компании обычно достаточно 1–2 vCPU и 2 GB RAM. Такая конфигурация подходит для лёгкой темы, небольшого числа плагинов и хорошо настроенного page cache.

Если сайт построен на Elementor, регулярно создаёт локальные бэкапы или использует тяжёлый плагин безопасности, лучше сразу выбирать 4 GB RAM.

Даже при небольшом трафике тариф на 1 GB может оказаться слишком тесным: память понадобится операционной системе, PHP-FPM, базе данных и фоновым процессам.

При росте посещаемости основным ограничением становятся одновременные запросы и работа PHP.

От 1 000 до 10 000 посещений в сутки

Для этого диапазона разумной отправной точкой будут 2–4 vCPU и 4 GB RAM.

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

Для WooCommerce и личных кабинетов лучше ориентироваться минимум на 6–8 GB RAM, поскольку значительная часть запросов остаётся динамической.

Если CPU регулярно загружен, а PHP-FPM создаёт очередь, одного увеличения RAM может быть недостаточно — потребуется больше вычислительных ядер или оптимизация кода.

Следующий диапазон уже требует более внимательной настройки базы и object cache.

От 10 000 до 50 000 посещений в сутки

Для контентного проекта или новостника обычно рассматривают 4–8 vCPU и 8–16 GB RAM.

При хорошем full-page cache значительную часть нагрузки можно перенести на CDN. Но после очистки кеша, публикации новости или массового захода пользователей сервер должен выдержать всплеск динамических запросов.

В этом диапазоне становятся особенно полезны Redis object cache, отдельный мониторинг MySQL, настройка PHP-FPM и контроль медленных запросов.

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

После 50 000 посещений один VPS всё ещё может справляться, но запас для ошибок и пиков становится критичным.

Более 50 000 посещений в сутки

Для высоконагруженного WordPress стоит начинать с 8 vCPU и 16 GB RAM, а затем подбирать ресурсы по фактическим метрикам.

На этом уровне обычно требуются CDN, WAF, Redis, эффективный page cache, внешний мониторинг и отдельная staging-копия. Базу данных и файловое хранилище при дальнейшем росте могут вынести на отдельные узлы.

Один мощный VPS подходит не всегда. Если проект регулярно сталкивается с резкими пиками, выгоднее предусмотреть масштабирование, балансировщик нагрузки или managed database.

Главный ориентир — не среднее число визитов, а загрузка CPU, расход RAM, время ответа PHP, число запросов к базе и поведение сайта в часы максимальной активности.

После выбора примерного диапазона можно отдельно разобрать, сколько ядер, памяти и дискового пространства действительно требуется WordPress.

Как выбрать CPU, RAM и диск

Сколько ядер нужно WordPress

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

Для небольшого блога или корпоративного сайта достаточно 1–2 vCPU. Если используется WooCommerce, тяжёлый конструктор, активная админка или много одновременных запросов, лучше начинать с 4 vCPU.

Дополнительные ядра особенно полезны, когда одновременно работают:

• Несколько процессов PHP-FPM;
• База данных;
• Redis;
• cron-задачи;
• Резервное копирование;
• Импорт товаров;
• Генерация изображений;
• Сканирование безопасности.

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

При этом добавление ядер не решит проблему, если сервер упирается в оперативную память.

Сколько оперативной памяти закладывать

RAM используется не только самим WordPress. В памяти одновременно находятся операционная система, веб-сервер, PHP-FPM, MySQL или MariaDB, OPcache, Redis и фоновые процессы.

Для простого сайта разумным минимумом будут 2 GB RAM. Для Elementor, WPBakery, корпоративного проекта с несколькими интеграциями или небольшого WooCommerce лучше ориентироваться на 4–8 GB.

Запас особенно нужен для:

• Обновления WordPress и плагинов;
• Импорта данных;
• Создания резервной копии;
• Работы редакторов;
• Всплесков посещаемости;
• Одновременного запуска нескольких PHP-процессов.

Если память заканчивается, сервер начинает использовать swap или завершать процессы. В результате появляются ошибки базы данных, 502, 503, зависания админки и медленная загрузка страниц.

При обычной нагрузке желательно оставлять свободными хотя бы 25–30% RAM. Тогда сервер сможет пережить кратковременный пик без аварийного завершения сервисов.

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

Почему NVMe важнее большого объёма медленного диска

WordPress постоянно обращается к файловой системе и базе данных. Он читает PHP-файлы, плагины, темы, кеш, изображения и таблицы MySQL.

Для такой нагрузки важны не только гигабайты, но и скорость случайных операций ввода-вывода. NVMe обычно заметно быстрее обычного HDD и многих SATA SSD, особенно при большом числе мелких запросов.

Быстрый диск помогает ускорить:

• Запросы к базе данных;
• Загрузку плагинов и тем;
• Работу административной панели;
• Генерацию кеша;
• Импорт и экспорт;
• Создание резервных копий;
• Обработку изображений.

Для небольшого сайта 40 GB NVMe часто полезнее, чем 200 GB медленного диска. Объём можно экономить за счёт внешнего хранения бэкапов, CDN и object storage для тяжёлых файлов.

Но быстрый диск не компенсирует нехватку RAM или перегруженный CPU. Поэтому решение о переходе на более мощный тариф нужно принимать по совокупности метрик.

Когда пора переходить на более мощный VPS

Увеличивать ресурсы стоит не после первого всплеска, а когда ограничения стали регулярными и влияют на пользователей.

Основные признаки:

• CPU часто держится выше 80–90%;
• Свободной RAM почти не остаётся;
• Активно используется swap;
• Появляются ошибки 502, 503 или OOM;
• PHP-FPM формирует очередь;
• База данных отвечает медленно;
• Админка тормозит даже без высокого внешнего трафика;
• Бэкапы и обновления заметно ухудшают работу сайта;
• Диск регулярно упирается в лимит IOPS или свободного места.

Перед апгрейдом стоит проверить кеш, тяжёлые плагины, медленные SQL-запросы и настройки PHP-FPM. Иногда оптимизация даёт больший эффект, чем переход на дорогой тариф.

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

После выбора процессора, памяти и диска можно переходить к серверному стеку: веб-серверу, PHP-FPM, OPcache, базе данных и Redis.

Рекомендуемый стек для WordPress 

Nginx или Apache

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

Apache удобен тем, что поддерживает .htaccess. Многие плагины и инструкции WordPress рассчитывают именно на него, поэтому настройка редиректов и ЧПУ обычно не требует ручного переноса правил в основной конфигурационный файл.

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

Для нового проекта часто выбирают Nginx с PHP-FPM. Если сайт переносится с Apache и активно использует .htaccess, проще сначала сохранить прежний стек, а переход на Nginx провести отдельно после тестирования.

Сам веб-сервер не выполняет PHP-код. Для этого нужен отдельный обработчик.

PHP-FPM и актуальная версия PHP

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

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

Настройку PHP-FPM нужно подбирать с учётом:

• Объёма RAM;
• Среднего потребления одного PHP-процесса;
• Числа одновременных запросов;
• Доли страниц без полного кеша;
• Нагрузки административной панели и cron.

Для нового сайта стоит использовать актуальную поддерживаемую версию PHP, совместимую с WordPress, темой и плагинами. Перед сменой версии её нужно проверить на staging-копии: устаревшее расширение может вызвать предупреждения, ошибки или полную недоступность сайта.

После выбора PHP следует включить OPcache, чтобы интерпретатор не компилировал одни и те же файлы при каждом запросе.

OPcache для ускорения PHP

При обычной работе PHP читает и компилирует файлы приложения перед выполнением. OPcache сохраняет уже скомпилированный байткод в памяти и повторно использует его для следующих запросов.

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

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

OPcache не заменяет page cache и Redis:

• page cache хранит готовый HTML;
• OPcache ускоряет выполнение PHP;
• Redis сохраняет объекты и результаты повторяющихся запросов.

После ускорения PHP следующим важным компонентом становится база данных.

MySQL или MariaDB

WordPress поддерживает MySQL и MariaDB. Для большинства проектов обе системы подходят, поэтому выбирать стоит по совместимости, доступным версиям и опыту администратора.

Производительность базы зависит не только от названия продукта. Важнее объём выделенной памяти, скорость диска, индексы, размер таблиц и качество запросов плагинов.

Со временем в базе могут накапливаться:

• Устаревшие ревизии;
• Временные данные;
• Просроченные transients;
• Сессии;
• Журналы плагинов;
• Остаточные таблицы удалённых расширений.

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

На обычном VPS база чаще всего работает на том же сервере и не должна быть открыта в интернет. При росте нагрузки её можно вынести на отдельный узел или managed-сервис.

Снизить количество повторных запросов к базе помогает постоянный object cache.

Redis для object cache

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

Redis делает object cache постоянным между запросами. Повторяющиеся данные можно получать из оперативной памяти, не обращаясь каждый раз к MySQL или MariaDB.

Наибольшую пользу Redis даёт:

• WooCommerce;
• Сайтам с авторизацией;
• Крупным каталогам;
• Новостным проектам;
• Мультиязычным сайтам;
• Проектам с частыми запросами к базе.

Для небольшого полностью кешируемого блога эффект может быть умеренным. В таком случае важнее сначала настроить page cache, OPcache и CDN.

Redis также расходует RAM, поэтому его нельзя включать без контроля лимитов и фактического процента попаданий в кеш. После подключения нужно убедиться, что WordPress действительно использует persistent object cache, а данные не вытесняют память, необходимую PHP и базе.

Когда базовый стек настроен, следующим уровнем оптимизации становится кеширование: готовых страниц, объектов, браузерных ресурсов и контента на CDN.

Кеширование WordPress

Page cache

Page cache сохраняет готовую HTML-версию страницы и отдаёт её без повторного запуска PHP и запросов к базе данных.

Для блога, корпоративного сайта и новостного проекта это один из самых эффективных способов снизить нагрузку на VPS. Чем больше страниц можно отдавать из полного кеша, тем меньше процессов PHP-FPM и запросов MySQL потребуется при всплеске посещаемости.

Кеш можно настраивать на уровне плагина, веб-сервера или внешнего CDN. Важно, чтобы он корректно очищался после публикации и обновления материалов, но не сбрасывался целиком без необходимости.

На динамических проектах полного кеша уже недостаточно, поэтому следующим уровнем становится object cache.

Object cache

Object cache хранит результаты повторяющихся запросов и вычислений. Это уменьшает количество обращений WordPress к MySQL или MariaDB.

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

При этом Redis не заменяет page cache. Первый ускоряет динамическую часть WordPress, а второй позволяет вообще не запускать PHP для готовых страниц.

После серверного кеша стоит настроить хранение ресурсов на стороне браузера и CDN.

Browser cache и CDN

Browser cache позволяет сохранять CSS, JavaScript, шрифты и изображения на устройстве пользователя. При повторном открытии страницы браузеру не приходится загружать все ресурсы заново.

CDN размещает копии статических файлов ближе к пользователям и снимает часть нагрузки с VPS. Для международного сайта это также помогает сократить задержку между посетителем и сервером.

Через CDN можно отдавать изображения, стили, скрипты и иногда полностью кешируемые HTML-страницы. Но правила нужно настраивать аккуратно, особенно если сайт содержит авторизацию, персональные данные или корзину.

Именно поэтому для WooCommerce нельзя применять единое кеширование ко всем URL.

Что нельзя кешировать в WooCommerce

В WooCommerce страницы с персональными данными должны формироваться отдельно для каждого пользователя. К ним относятся корзина, оформление заказа, личный кабинет и связанные AJAX-запросы.

Обычно из полного page cache исключают:

• /cart/;
• /checkout/;
• /my-account/;
• Запросы с cookies корзины и авторизации;
• Служебные WooCommerce endpoints.

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

Карточки товаров и категории, напротив, обычно можно кешировать, если система корректно обновляет данные после изменения цены, остатков и акций.

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

Следующий важный уровень надёжности — внешние бэкапы и staging-копия для безопасной проверки обновлений.

Бэкапы и staging-копия

Что включать в резервную копию

Для восстановления WordPress недостаточно сохранить только файлы сайта или только базу данных. Нужны обе части, а также конфигурация окружения.

В резервную копию обычно включают:

• Каталог WordPress;
• Пользовательские загрузки;
• Базу данных;
• wp-config.php;
• Конфигурацию веб-сервера;
• cron-задачи;
• Настройки PHP;
• Правила редиректов;
• Данные о DNS и внешних интеграциях.

Особенно важны каталог wp-content, база и конфигурационные файлы. Именно там находятся темы, плагины, медиа, пользователи, записи, заказы и настройки сайта.

Секреты и пароли не стоит хранить в открытом виде рядом с обычным архивом. Копии нужно шифровать или размещать в защищённом хранилище.

После определения состава бэкапа нужно выбрать частоту, которая соответствует скорости изменения сайта.

Как часто копировать файлы и базу

Частота зависит от типа проекта. Для небольшого блога ежедневного бэкапа обычно достаточно, а WooCommerce с постоянными заказами может требовать копирования базы несколько раз в день.

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

Ориентир может быть таким:

Бэкапы нужно хранить вне основного VPS. Иначе удаление сервера, отказ диска или компрометация системы уничтожат и сайт, и его копии.

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

Snapshot помогает быстрее откатить сервер, но решает другую задачу.

Почему snapshot не заменяет бэкап

Snapshot фиксирует состояние виртуальной машины или диска на конкретный момент. Он удобен перед обновлением системы, сменой PHP или крупным изменением конфигурации.

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

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

Лучше использовать оба инструмента:

• snapshot — для быстрого отката всего сервера;
• Внешний бэкап — для независимого восстановления данных.

Однако даже хороший бэкап не должен быть первым средством проверки обновлений. Для этого нужна staging-копия.

Для чего нужна staging-копия

Staging — это отдельная тестовая копия сайта, на которой можно безопасно проверять обновления WordPress, PHP, темы и плагинов.

Она особенно полезна перед:

• Сменой версии PHP;
• Обновлением WooCommerce;
• Установкой нового плагина;
• Изменением темы;
• Массовым импортом;
• Правками кеша и веб-сервера;
• Изменением структуры URL.

Staging не должен индексироваться и отправлять реальные письма, заказы или вебхуки. Его лучше закрыть авторизацией, ограничить по IP и дополнительно поставить noindex.

Копию также нельзя подключать к production-платежам, CRM и рассылкам без тестового режима. Иначе проверка может создать реальные операции.

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

Когда бэкапы и staging настроены, можно переходить к защите WordPress, файлов, панели входа и внешнего периметра.

Безопасность WordPress на VPS

Обновления WordPress, тем и плагинов

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

Обновлять нужно:

• Ядро WordPress;
• Активную тему;
• Установленные плагины;
• PHP и системные пакеты;
• Веб-сервер и базу данных.

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

Критические исправления не стоит откладывать, но крупные обновления безопаснее сначала проверять на staging-копии. Особенно это касается WooCommerce, конструкторов страниц, платёжных модулей и расширений, которые изменяют структуру базы.

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

Firewall, WAF и CDN

Обычный firewall ограничивает доступ к портам VPS. Снаружи должны быть открыты только действительно нужные сервисы: обычно SSH, HTTP и HTTPS.

Базу данных, Redis, административные панели и внутренние сервисы не следует выставлять в интернет без необходимости. Доступ к ним лучше разрешать только локально или из доверенной сети.

WAF работает выше и анализирует HTTP-запросы. Он может блокировать попытки SQL-инъекций, вредоносные запросы к плагинам, перебор форм входа и другой подозрительный трафик.

CDN, в свою очередь, снижает нагрузку на VPS, кеширует статические файлы и скрывает прямой IP origin-сервера. Многие CDN также предлагают базовые правила WAF и защиту от части DDoS-атак.

Однако WAF не исправляет уязвимый плагин и не заменяет обновления. Это дополнительный барьер, который снижает вероятность успешной атаки.

Следующим уровнем остаётся защита административного входа и интерфейсов WordPress.

Защита входа и ограничение XML-RPC

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

Также полезно:

• Не использовать имя пользователя admin;
• Удалить лишние административные учётные записи;
• Выдавать пользователям минимально необходимые роли;
• Ограничить доступ к панели по IP или VPN, если это возможно;
• Включить журнал входов и изменений.

Файл xmlrpc.php используется для удалённой публикации, некоторых мобильных приложений и интеграций. Если эти функции не нужны, XML-RPC можно отключить или ограничить на уровне веб-сервера, WAF либо плагина безопасности.

Оставленный без ограничений XML-RPC может использоваться для перебора учётных данных и злоупотребления pingback-запросами. При этом отключать его без проверки тоже не стоит: отдельные интеграции могут перестать работать.

Даже защищённая панель не поможет, если файлы сайта доступны для записи всем процессам.

Права на файлы и доступ к wp-config.php

Файлы WordPress не должны иметь права 777. Такая настройка иногда временно устраняет ошибку записи, но одновременно позволяет изменять сайт любому процессу с доступом к серверу.

Обычно для каталогов используют права 755, а для файлов — 644. Точные значения зависят от пользователя PHP-FPM, владельца проекта и способа обновления WordPress.

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

Особое внимание нужно уделить wp-config.php. В нём находятся данные подключения к базе, ключи и другие чувствительные параметры. Файл должен быть недоступен через браузер и иметь максимально ограниченные права, совместимые с работой сайта.

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

После настройки прав остаётся контролировать, не появились ли на сайте новые уязвимости или признаки компрометации.

Мониторинг и проверка уязвимостей

Без мониторинга взлом или ошибка могут оставаться незаметными неделями. Проверять нужно не только доступность главной страницы, но и состояние сервера, файлов и WordPress.

Минимальный контроль включает:

• Доступность сайта и HTTPS;
• Ошибки 4xx и 5xx;
• Загрузку CPU, RAM и диска;
• Изменения системных и WordPress-файлов;
• Подозрительные входы в панель;
• Появление новых администраторов;
• Устаревшие плагины и темы;
• Ошибки PHP и базы данных.

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

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

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

Настройка wp-cron на нагруженном сайте

Почему стандартный wp-cron создаёт лишнюю нагрузку

wp-cron — это встроенный механизм WordPress для запуска фоновых задач. Через него выполняются публикации по расписанию, очистка временных данных, отправка писем, проверки обновлений и задания плагинов.

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

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

Для нагруженного WordPress лучше отключить запуск cron через пользовательские запросы и передать его системному планировщику.

Перенос задач в системный cron

Сначала в файл wp-config.php добавляется параметр: define('DISABLE_WP_CRON', true);

Он отключает автоматический запуск wp-cron при открытии страниц, но не удаляет сами задания.

После этого на сервере создаётся системная cron-задача. Например, для запуска каждые пять минут: crontab -e

В расписание можно добавить вызов через WP-CLI: /usr/local/bin/wp cron event run --due-now --path=/var/www/example.com/public --quiet

WP-CLI лучше запускать от того системного пользователя, которому принадлежат файлы сайта. Это снижает риск появления файлов с неправильным владельцем и проблем с правами.

Если WP-CLI не используется, возможен вызов wp-cron.php через PHP CLI или HTTP-запрос. Однако серверный запуск через WP-CLI обычно удобнее контролировать и логировать.

Интервал зависит от проекта. Для обычного сайта часто достаточно 5–15 минут, а магазину с очередями заказов, письмами и интеграциями может потребоваться более частый запуск.

После изменения важно убедиться, что задачи действительно выполняются и не накапливаются в очереди.

Проверка выполнения фоновых задач

Сначала нужно посмотреть список запланированных событий: wp cron event list --path=/var/www/example.com/public

Команда показывает название hook, время следующего запуска и периодичность.

Просроченные задачи можно выполнить вручную: wp cron event run --due-now --path=/var/www/example.com/public

После запуска стоит проверить:

• Публикации по расписанию;
• Отправку писем;
• Обработку заказов;
• Очистку кеша;
• Синхронизацию с CRM и API;
• Задачи резервного копирования;
• Очереди WooCommerce и других плагинов.

Ошибки cron не должны исчезать в пустоту. Вывод задачи лучше направлять в отдельный лог, чтобы видеть сбои PHP, неправильные пути и проблемы с правами.

Также нужно проверить абсолютный путь к WP-CLI или PHP: окружение системного cron обычно отличается от интерактивной SSH-сессии и может не видеть те же команды через PATH.

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

Типовые ошибки при выборе и настройке VPS

Устанавливать тяжёлые плагины без кеша

Плагин может добавлять сложные SQL-запросы, обработку изображений, поиск, фильтры, статистику или фоновые задачи. Если при этом page cache и OPcache не настроены, каждый визит снова запускает PHP и обращается к базе.

Особенно быстро проблема проявляется на сайтах с конструкторами, каталогами и WooCommerce. Внешне всё может работать нормально при нескольких посетителях, а после роста трафика сервер начинает упираться в CPU и PHP-FPM.

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

Но даже хорошо настроенный кеш не устранит нагрузку от фоновых задач, если wp-cron продолжает запускаться через посещения.

Оставлять wp-cron по умолчанию

Стандартный wp-cron проверяет очередь задач при обращениях к сайту. На нагруженном проекте это создаёт лишние запуски PHP, а при низкой посещаемости задания, наоборот, могут выполняться с задержкой.

Для стабильной работы лучше отключить вызов через пользовательские запросы и запускать просроченные события системным cron по расписанию.

После переноса нужно проверить публикации, письма, очереди WooCommerce, импорты и интеграции. Сам факт наличия записи в crontab ещё не означает, что она работает без ошибок.

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

Не ограничивать XML-RPC

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

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

Перед блокировкой нужно проверить, не используют ли XML-RPC мобильное приложение, Jetpack или другие интеграции. Иначе защита может случайно нарушить рабочую функцию сайта.

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

Не обновлять плагины и темы

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

Обновления нужно устанавливать регулярно, а неиспользуемые расширения — удалять. Крупные изменения, особенно WooCommerce, конструкторы и платёжные модули, лучше сначала проверять на staging.

Перед обновлением нужен свежий бэкап. Автоматическая установка без возможности отката может привести к конфликту версий, но полный отказ от обновлений обычно создаёт ещё больший риск.

Даже актуальный и оптимизированный WordPress будет нестабилен, если установка плагинов происходит бесконтрольно.

Ставить все плагины подряд

 Частая история, когда владелец сайта на WordPress ставит очень много плагинов, экспериментируя. На тестовой среде это делать относительно безопасно, но на боевой чревато как поломкой из-за несовместимости, так и установкой "дырявого" плагина через который возможен взлом и существенного влияния на производительность сайта.

Поэтому плагины лучше ставить проверенные, точно нужные, и сначала на тестовой среде.

Но ограниченный список проверенных плагинов не спасёт, если тариф выбран без резерва.

Выбирать тариф без запаса по RAM

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

RAM одновременно используют PHP-FPM, база данных, Redis, OPcache, веб-сервер, операционная система и фоновые процессы. При её нехватке VPS переходит в swap или начинает завершать сервисы через OOM killer.

Для обычной нагрузки желательно сохранять запас хотя бы 25–30%. Если сайт использует WooCommerce, Elementor, WPBakery или получает резкие всплески трафика, резерв должен быть выше.

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

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

Чек-лист выбора VPS для WordPress 

Перед заказом VPS проверьте, что:

• Конфигурация соответствует не только посещаемости, но и типу сайта;
• Для обычного WordPress предусмотрено не менее 2 GB RAM;
• Для WooCommerce и тяжёлых конструкторов заложено от 4–8 GB RAM;
• Используется NVMe-диск;
• Есть запас по CPU и RAM минимум 25–30%;
• Выбран актуальный PHP с поддержкой темы и плагинов;
• Настроены PHP-FPM и OPcache;
• Используется MySQL или MariaDB с достаточным объёмом памяти;
• Для динамического сайта предусмотрен Redis object cache;
• Включён page cache и настроены исключения для WooCommerce;
• CDN и WAF используются там, где это оправдано;
• Бэкапы сохраняются вне VPS;
• Есть staging-копия для обновлений;
• wp-cron перенесён в системный cron при высокой нагрузке;
• XML-RPC ограничен, если он не нужен;
• Плагины, темы и WordPress регулярно обновляются;
• Настроен мониторинг CPU, RAM, диска, PHP и базы.

Если сайт уже работает, выбирать новый тариф лучше по фактическим метрикам. Постоянная загрузка CPU, активный swap, очередь PHP-FPM и ошибки 502 или 503 дают более точную картину, чем одна только посещаемость.

Заключение

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

Для небольшого сайта обычно достаточно 1–2 vCPU и 2 GB RAM. Корпоративным проектам, конструкторам и магазинам нужен больший запас, особенно по памяти. При этом быстрый NVMe, PHP-FPM, OPcache и page cache часто дают больше пользы, чем простой переход на тариф с дополнительными гигабайтами.

Redis особенно полезен там, где нельзя полностью кешировать HTML: в WooCommerce, личных кабинетах, каталогах и новостных проектах. Для публичных страниц главную роль по-прежнему играют page cache, CDN и правильная очистка кеша.

Надёжность зависит не только от ресурсов. Внешние бэкапы, staging, обновления, WAF, ограничение XML-RPC и системный cron помогают избежать ситуаций, когда сайт падает не из-за слабого VPS, а из-за неверной настройки.

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

FAQ

Сколько RAM нужно WordPress?

Для небольшого блога или корпоративного сайта разумным минимумом будут 2 GB RAM. Такой конфигурации обычно достаточно, если используется лёгкая тема, умеренное число плагинов и настроен page cache.

Для Elementor, WPBakery, мультиязычности и сложных интеграций лучше выбирать 4 GB. Небольшому WooCommerce обычно требуется 6–8 GB, особенно если на том же VPS работают MySQL, Redis, бэкапы и защитные инструменты.

Точный объём зависит не только от посещаемости. Важны число процессов PHP-FPM, доля динамических страниц, размер базы и потребление памяти плагинами.

Что лучше для WordPress — Nginx или Apache?

Оба веб-сервера подходят для WordPress.

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

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

Нужен ли Redis небольшому сайту?

Не всегда. Для небольшого блога с хорошим page cache больший эффект обычно дают OPcache, CDN и оптимизация изображений.

Redis полезнее на сайтах с большим количеством динамических запросов: WooCommerce, личных кабинетах, каталогах, мультиязычных проектах и новостниках. Он сохраняет объекты между запросами и уменьшает число повторных обращений к базе.

При этом Redis расходует RAM, поэтому на тесном VPS его не стоит включать без контроля памяти и фактического эффекта.

Какой PHP выбрать для WordPress в 2026 году?

Для нового production-сайта стоит ориентироваться на PHP 8.3 или более новую поддерживаемую ветку после проверки совместимости.

Актуальные версии WordPress поддерживают PHP 8.4 и 8.5, но тема, плагины и сторонние интеграции могут отставать от ядра. Поэтому переход лучше сначала проверить на staging-копии.

Использовать устаревшую ветку PHP только ради старого плагина нежелательно. Безопаснее обновить или заменить несовместимое расширение.

Когда WordPress пора переносить на более мощный VPS?

Апгрейд нужен, когда нехватка ресурсов становится регулярной, а не проявляется один раз во время обновления.

Основные признаки:

• CPU долго работает под высокой нагрузкой;
• RAM почти полностью занята;
• Постоянно используется swap;
• Появляются ошибки 502, 503 или OOM;
• PHP-FPM формирует очередь;
• База отвечает медленно;
• Админка тормозит;
• Бэкапы и импорт мешают работе сайта.

Перед сменой тарифа стоит проверить page cache, Redis, медленные SQL-запросы, тяжёлые плагины и настройки PHP-FPM. Если сайт уже оптимизирован, а нагрузка продолжает расти, ресурсы лучше увеличить заранее.

Список источников

1. WordPress.org — Requirements

2. Make WordPress Hosting — Server Environment

3. WordPress Advanced Administration Handbook — Web Servers

4. WordPress Advanced Administration Handbook — Cache

5. WordPress Plugin Handbook — Cron