Hostingi.net.uaОбзоры украинских хостинговых компаний
Хостинг для сайтов на WordPress
Автор: Сергей Коваленко
Опубликовано: 15.01.2020
Обновлено: 28.07.2026
Ниже мы рассмотрим основные требования и характеристики, которым должен отвечать хостинг для WordPress, а также приведем несколько хостинг-провайдеров, у которых есть специальные тарифные планы для сайтов на WordPress.
Для тех, кто только начал заниматься созданием сайтов и уже планирует делать сайт на WordPress, рекомендуем почитать наш материал о том, что такое WordPress.– Вкратце скажем, что WordPress — это самая популярная, простая и гибкая во всех планах система управления контентом (CMS), на которой очень просто и быстро можно создавать даже очень сложные порталы, не говоря уже о элементарных сайтах-визитках.
Следует отметить, что все, приведенные в нашем рейтинге хостинги, соответствуют требованиям хостинга для Вордпресс сайта и имеют в своем арсенале автоустановщики наиболее популярных CMS-систем, среди которых есть и WordPress. Тем не менее, некоторые компании выделили специальные тарифные планы с уже настроенными параметрами (хостинг с установленным WordPress).
Ниже приведены провайдеры и тарифные планы, специально подготовленные для работы с CMS WordPress — вы найдёте для себя как дешевый хостинг wordpress (для одного сайта), так и более дорогие тарифы, на которых можно разместить несколько сайтов. Выбрав любой хостинг для Вордпресс сайта, из предложенного в таблице, вы получите уже установленную CMS-систему последней версии, квалифицированную техническую поддержку и можете быть уверены, что ваш сайт будет нормально работать.
WordPress – самая распространённая CMS в мире, и одновременно самая требовательная к качеству площадки, на которой она живёт. Парадокс простой: поставить движок можно за пять минут почти куда угодно, а вот заставить его быстро работать под реальной нагрузкой – задача совсем другого класса. Именно здесь начинается разговор о хостинге.
Ниже – подробный разбор темы с точки зрения человека, который смотрит не на маркетинговые лендинги провайдеров, а на конфиги, логи и графики нагрузки.
Почему WordPress – особенный «жилец» на сервере
Чтобы понимать требования к хостингу, нужно представлять, что происходит при каждом обращении к сайту.
Статический HTML-файл сервер просто отдаёт с диска. Одна операция чтения, миллисекунды, никакой нагрузки. С WordPress всё иначе. При запросе без кэша сервер:
Принимает соединение (веб-сервер: Apache, Nginx или LiteSpeed);
Передаёт запрос интерпретатору PHP – как правило, PHP-FPM4
PHP загружает ядро WordPress, подключает активную тему и все активные плагины;
Выполняется серия запросов к базе данных MySQL/MariaDB – от 20–30 на простом блоге до 300–600 на нагруженном магазине;
Формируется HTML, отдаётся браузеру, процесс освобождается.
Каждый такой цикл занимает оперативную память (обычно 40–150 МБ на процесс) и процессорное время. И вот здесь кроется главный конфликт: WordPress по своей архитектуре – это не «сайт», а полноценное приложение, которое пересобирает страницу заново при каждом запросе. Плюс экосистема из 60 000 плагинов, среди которых встречаются как ювелирно написанные, так и откровенно чудовищные по качеству.
Отсюда простой вывод. Хостинг для WordPress – это не «место, куда положить файлы». Это среда исполнения PHP-приложения, и оценивать её нужно соответствующим образом.
Типы хостинга: чем они реально отличаются
Виртуальный (shared) хостинг
Сотни аккаунтов на одном физическом сервере. Ресурсы делятся между всеми. Это самый дешёвый и самый непредсказуемый вариант.
Хороший shared-хостинг сегодня – это почти всегда CloudLinux с технологией LVE, которая жёстко изолирует аккаунты друг от друга по CPU, памяти и числу процессов. Плохой shared – это «общий котёл», где сосед с кривым парсером может уронить производительность всей машины. Разница между этими двумя вариантами при одинаковой цене – колоссальная, но в прайс-листе она никак не отражена.
Кому подходит: визитки, блоги, портфолио, небольшие корпоративные сайты, магазины на старте.
VPS (виртуальный выделенный сервер)
Вам выделяют гарантированную долю ресурсов: конкретные ядра, конкретный объём RAM, конкретный диск. Как правило, на виртуальном сервере вы получаете root-доступ и полную свободу – вместе с полной ответственностью.
Ключевое разделение здесь – managed и unmanaged. В первом случае провайдер настраивает стек, обновляет систему, следит за безопасностью. Во втором вы остаётесь один на один с сервером. Разница в цене – примерно вдвое, разница в требуемой квалификации – на порядок.
Кому подходит: интернет-магазины, сайты с посещаемостью от нескольких тысяч человек в сутки, проекты с нестандартными требованиями (собственные демоны, специфические версии ПО, отдельная очередь задач).
Managed WordPress-хостинг
Отдельная категория: инфраструктура, заточенная именно под этот движок. Обычно включает серверное кэширование, автообновления, стейджинг, встроенный CDN, ежедневные бэкапы и поддержку, которая понимает, что такое wp_options.
Платите вы за то, что вам не нужно ничего настраивать. Цена ощутимо выше среднерыночной, и почти всегда есть ограничения: чёрный список плагинов (кэширующие обычно запрещены как избыточные), лимит на количество визитов, иногда – запрет на нестандартные PHP-расширения.
Выделенный сервер и облако
Актуально для крупных проектов, медиа, агрегаторов, порталов с сотнями тысяч посетителей. Здесь разговор идёт уже не о хостинге, а об архитектуре: балансировщики, отдельный сервер БД, реплики, объектное хранилище для медиафайлов.
Технические параметры, которые действительно важны
Провайдеры любят мерить дисковым пространством и «безлимитным трафиком». На практике сайт падает совсем не поэтому.
Количество PHP-процессов (воркеров)
Это главный ограничитель, о котором молчит 90% тарифных таблиц. PHP-воркер – это один процесс, обрабатывающий один запрос в один момент времени. Если у вас 5 воркеров, а средняя генерация страницы занимает 500 мс, теоретический потолок – 10 некэшированных запросов в секунду. Одиннадцатый посетитель встанет в очередь.
Когда очередь переполняется, пользователь видит 503, 504 или знаменитую ошибку 508 «Resource Limit Is Reached» на CloudLinux-хостингах. Причём сайт при этом «работает» – просто не успевает.
Спрашивайте у поддержки прямо: сколько entry processes и PHP-воркеров даёт тариф. Ответ «безлимитно» означает, что вам не хотят отвечать.
Оперативная память: два разных числа
Здесь регулярная путаница, которая дорого обходится.
memory_limit в PHP – это потолок памяти на один процесс. Стандартные 128 МБ хватает большинству сайтов; WooCommerce с тяжёлым импортом требует 256–512 МБ.
Реальная выделенная память аккаунта (PMEM в терминах CloudLinux) – совсем другая величина. Она ограничивает суммарное потребление всех ваших процессов. Тариф может обещать memory_limit 512M и при этом иметь общий лимит в 1 ГБ – то есть два тяжёлых запроса одновременно уже упрутся в потолок.
Процессор
Указание «2 ядра» на shared-хостинге почти всегда означает не два физических ядра, а долю в 200% от одного. Важнее другое: какое поколение процессора стоит в ноде. Разница между старым Xeon E5 и современным EPYC на однопоточной PHP-нагрузке – двукратная. WordPress масштабируется в первую очередь по частоте одного ядра, а не по их количеству.
Диски и IOPS
NVMe против SATA SSD – разница в задержках примерно в 5–10 раз. Для базы данных это критично: MySQL постоянно пишет и читает мелкими блоками. Но не менее важен лимит IOPS: провайдер может поставить NVMe и ограничить вас 1024 операциями в секунду, что убивает все преимущества.
Иноды
Часто забываемый параметр. Инода – это одна запись в файловой системе: файл или каталог. Чистая установка WordPress – это уже около 2 000 файлов, с десятком плагинов и темой – 15 000–30 000. Магазин с тысячей товаров и тремя вариантами превью для каждого изображения легко выходит за 100 000.
Когда лимит инод исчерпан, сайт перестаёт писать файлы: не загружаются картинки, не сохраняются логи, ломаются обновления. При этом дискового пространства может оставаться половина.
Версия PHP
Не косметика, а производительность. Переход с PHP 7.4 на 8.1+ даёт прирост скорости выполнения кода на 15–30% без единой правки в коде сайта. Плюс безопасность: устаревшие ветки не получают патчей. Хороший хостинг позволяет переключать версию PHP из панели и делать это для каждого домена отдельно.
Веб-сервер и кэширование: где рождается скорость
Apache, Nginx, LiteSpeed
Apache гибок и понимает .htaccess, но прожорлив. Nginx быстрее и экономнее на статике, но не читает .htaccess – правила пишутся в конфиге сервера. Частая связка – Nginx как фронтенд-прокси перед Apache: он забирает на себя статику и SSL, а PHP уходит дальше. Подробнее — тут.
LiteSpeed Enterprise (и его бесплатный брат OpenLiteSpeed) – отдельная история. Главное преимущество для WordPress – плагин LSCache, который кэширует страницы на уровне сервера, а не в PHP. Это принципиально: обычный кэширующий плагин всё равно запускает PHP, пусть и коротко. LSCache отдаёт готовую страницу, вообще не будя интерпретатор. На реальных замерах TTFB падает с 400–600 мс до 30–80 мс.
Три уровня кэша, которые нужно понимать
Кэш страниц (page cache) – готовый HTML хранится и отдаётся без обращения к PHP и базе. Даёт самый большой эффект. Реализуется LSCache, Nginx FastCGI Cache, Varnish или плагинами (WP Rocket, W3 Total Cache, Hummingbird).
OPcache – кэш скомпилированного байткода PHP. Должен быть включён всегда, без исключений. Если провайдер его не включил, это красный флаг.
Объектный кэш (Redis или Memcached) – хранит результаты запросов к базе в оперативной памяти. Критичен для динамических сайтов, где страничный кэш работать не может: личные кабинеты, корзины, фильтры каталога, форумы. На нагруженном WooCommerce Redis снимает с базы 60–80% запросов.
Обратите внимание: страничный кэш прекрасно ускоряет анонимных посетителей, но никак не помогает залогиненным пользователям и админке. Если вы работаете с большим каталогом, скорость админ-панели определяется исключительно «сырой» производительностью сервера и базы.
CDN
Сеть доставки контента раздаёт статику (картинки, скрипты, стили) с узлов, ближайших к посетителю. Обязательна для международной аудитории, полезна для снижения нагрузки на основной сервер. Но CDN не лечит медленный бэкенд: если генерация HTML занимает две секунды, никакой Cloudflare это не исправит.
База данных: тихий убийца производительности
Большинство «медленных сайтов на хорошем сервере» упираются именно сюда.
Раздутая таблица wp_options. Каждая запись с флагом autoload = yes загружается в память при любом обращении к сайту. Норма – до 800 КБ автозагружаемых данных. Встречаются проекты с 15–20 МБ, накопленными за годы установки и удаления плагинов, которые не подчищают за собой. Результат – сотни лишних миллисекунд на каждый запрос.
Проверить можно одним SQL-запросом, отсортировав опции по размеру и autoload-статусу.
Просроченные транзиенты. WordPress сам их не удаляет надёжно. Десятки тысяч мёртвых записей – обычное дело.
Мусор в wp_postmeta. Особенно на магазинах: удалённые товары, старые заказы, сессии, метаданные от давно снесённых плагинов.
MyISAM вместо InnoDB. Древние сайты, мигрировавшие с хостинга на хостинг, до сих пор встречаются с таблицами MyISAM, которые блокируются целиком при записи. Перевод на InnoDB – обязательная процедура.
Ревизии записей. По умолчанию WordPress хранит их бесконечно. У статьи, которую редактировали 40 раз, будет 40 копий в базе.
Хороший провайдер даёт доступ к медленному логу запросов (slow query log) и не ставит жёсткий лимит на одновременные подключения к MySQL, о который спотыкаются магазины в часы пик.
wp-cron: маленькая деталь с большими последствиями
Планировщик WordPress по умолчанию – псевдо-cron. Он не работает по расписанию, а запускается при посещении сайта. Отсюда два симптома, зеркально противоположных.
На сайте с нулевой посещаемостью задачи не выполняются вовсе: не уходят письма, не публикуются отложенные записи, не делаются бэкапы.
На посещаемом сайте, наоборот, wp-cron.php дёргается слишком часто и создаёт паразитную нагрузку, особенно если какой-нибудь плагин повесил на него тяжёлую задачу.
Правильное решение стандартно: отключить внутренний планировщик через define('DISABLE_WP_CRON', true); в wp-config.php и настроить системный cron на вызов файла раз в 5–15 минут. Возможность создавать cron-задания из панели управления – обязательный пункт при выборе хостинга.
Локация сервера, TTFB и здравый смысл
Физика неумолима: свет по оптоволокну идёт быстро, но не мгновенно. Разница между дата-центром в 30 км от аудитории и в 8 000 км – это 100–200 мс на каждом обращении.
Для проекта, ориентированного на украинскую или европейскую аудиторию, сервер во Франкфурте, Амстердаме, Варшаве или Киеве даст ощутимо лучший отклик, чем площадка в Далласе. Проверяется элементарно – обычным ping и трассировкой.
Отдельный нюанс – качество пиринга. Дата-центр может стоять близко географически, но иметь скверные каналы к вашим провайдерам. Поэтому тестировать нужно не карту, а реальную задержку с нескольких точек.
Ориентиры по отклику сервера — TTFB: до 200 мс на кэшированной странице – хорошо, 200–500 мс – приемлемо, свыше 800 мс – проблема, которую нужно диагностировать.
Безопасность: чего ждать от провайдера
WordPress атакуют постоянно и автоматически. Боты перебирают пароли на /wp-login.php, ищут уязвимые версии плагинов, пробуют залить веб-шелл через дыры в загрузчиках файлов. Это фоновый шум интернета, и он касается сайта с десятью посетителями в день ровно так же, как крупного портала.
Что должен обеспечивать хостинг:
Изоляцию аккаунтов. На дешёвом shared без изоляции взлом одного сайта означает заражение всех соседей на сервере. Это классическая cross-site contamination, и она до сих пор массово встречается.
WAF и ModSecurity с актуальными правилами – отсекает основную массу автоматических атак ещё до PHP.
Бесплатный SSL (Let’s Encrypt) с автопродлением. В 2020-х это гигиена, а не опция.
Антивирусное сканирование файлов – Imunify360 или аналог.
Свежие версии ПО. Если провайдер до сих пор предлагает PHP 7.2 как «рекомендуемую» – делайте выводы.
И честно: даже идеальный хостинг не спасёт от заброшенного плагина, не обновлявшегося три года. Ответственность здесь всегда делится.
Где они хранятся? Если на том же диске того же сервера – это не бэкап, а иллюзия. Отказ дисковой подсистемы уносит и сайт, и копии.
Сколько хранятся? Семь дней – минимум. Проблема в том, что заражение или тихая поломка часто обнаруживаются через две-три недели.
Можете ли вы восстановиться сами? Кнопка «восстановить» в панели против заявки в поддержку с ожиданием 12 часов – разница между неприятностью и катастрофой.
Можно ли скачать копию себе? Если нет – вы привязаны к провайдеру намертво.
Среди администраторов ходит присказка, точность которой подтверждается регулярно: бэкап, который ни разу не восстанавливали, – это не бэкап, а надежда. Проверяйте развёртывание копии хотя бы раз в полгода, желательно на стейджинге.
Работающая схема – правило 3-2-1: три копии данных, на двух разных носителях, одна из них – вне площадки хостинга. Плагины вроде UpdraftPlus с выгрузкой в S3 или Google Drive закрывают этот пункт за копейки.
Uptime и SLA: считайте в минутах
Красивая цифра «99,9%» звучит внушительно, пока не переведёшь её в реальное время недоступности:
99,9% – около 43 минут простоя в месяц;
99,5% – примерно 3,5 часа в месяц;
99,0% – более 7 часов в месяц.
Для магазина три часа простоя в декабре – это конкретные потерянные деньги. Кроме того, важно, что именно провайдер считает простоем. Если сервер отвечает, но с задержкой в 20 секунд, формально он «доступен».
Не полагайтесь на цифры из рекламы – поставьте собственный внешний мониторинг (UptimeRobot, Better Stack и подобные) и смотрите на факты хотя бы месяц.
Как понять, что виноват именно хостинг
Частая ошибка – переезжать на дорогой тариф, когда проблема в коде.
Практическая диагностика:
Замерьте TTFB на кэшированной и некэшированной странице. Если кэшированная отдаётся за 100 мс, а некэшированная за 2 секунды – проблема в приложении, а не в канале.
Поставьте Query Monitor. Он покажет количество запросов к базе, время их выполнения, самые медленные хуки и то, какой именно плагин съедает время.
Отключите плагины по одному на стейджинге. Скучно, но работает безотказно.
Посмотрите нагрузку в панели хостинга. Упирается ли аккаунт в лимиты CPU, памяти, entry processes? Если графики регулярно бьются в потолок – тариф исчерпан.
Проверьте сайт на «пустой» установке. Стандартная тема, нулевые плагины. Если и так медленно – вопросы к серверу.
Правило простое: если сайт медленный при 50 запросах к базе и лёгкой теме – виноват хостинг. Если он медленный при 600 запросах и трёх конструкторах страниц одновременно – хостинг тут ни при чём.
Когда пора переезжать
Признаки, что тариф вы переросли:
регулярные ошибки 503/508 в часы пик;
админка «думает» по 5–10 секунд при нормальной скорости фронтенда;
графики нагрузки постоянно упираются в лимиты;
база выросла настолько, что бэкап не успевает завершиться;
вам нужны Redis, WP-CLI, Git-деплой, отдельная очередь задач или свои cron-скрипты.
Переезд с shared на VPS обычно окупается уже на этапе, когда сайт стабильно приносит деньги: разница в 15–30 долларов в месяц несопоставима с потерями от простоя магазина.
Чек-лист для выбора
Перед оплатой стоит получить ответы на следующие вопросы – желательно письменно от поддержки, чтобы заодно оценить её адекватность и скорость реакции.
Какие версии PHP доступны и как они переключаются?
Сколько PHP-воркеров и entry processes в тарифе?
Какой веб-сервер: LiteSpeed, Nginx, Apache?
Есть ли Redis или Memcached?
Какой лимит инод?
Тип дисков и есть ли лимит IOPS?
Где физически стоит сервер?
Как устроены бэкапы: частота, срок хранения, место, самостоятельное восстановление?
Есть ли стейджинг?
Даётся ли SSH и WP-CLI?
Есть ли тестовый период или гарантия возврата денег?
Отдельно – потратьте вечер на чтение отзывов, но с поправкой на выборку: люди чаще пишут в момент раздражения. Ищите не эмоции, а повторяющиеся технические претензии: «постоянные 508», «поддержка отвечает сутки», «неделю не могли восстановить бэкап».
Мифы, которые стоит оставить позади
«Безлимитный хостинг». Безлимитных ресурсов не существует. Лимиты просто спрятаны в пользовательское соглашение, в раздел о «неприемлемо высоком потреблении».
«SSD-диски» как аргумент. В 2026 году это как «есть электричество». Смотрите уже на NVMe и IOPS.
«Оптимизирован под WordPress». Формулировка без содержания, пока не расшифрована конкретикой: серверный кэш, объектный кэш, версия PHP, лимиты.
«Хостинг влияет на SEO». Влияет, но косвенно – через скорость загрузки и доступность. Волшебного «SEO-хостинга» не бывает.
«Дороже – значит лучше». Корреляция есть, но слабая. Есть отличные площадки за 5 долларов и посредственные за 40.
Выбор хостинга для WordPress сводится к трём честным вопросам: какая у сайта реальная нагрузка, какая у вас квалификация и сколько стоит час простоя.
Блогу и визитке хватит качественного shared-хостинга с LiteSpeed, свежим PHP и вменяемой поддержкой. Растущему магазину нужен VPS или managed-решение с Redis и нормальным запасом по памяти. Крупному проекту – уже отдельная инфраструктура и человек, который её ведёт.
И последнее. Быстрый сервер не сделает медленный сайт быстрым. Но медленный сервер гарантированно испортит даже идеально оптимизированный. Хостинг – это фундамент: его не видно, пока он держит, и его видно очень отчётливо, когда он перестаёт.
FAQ по хостингу для сайтов на CMS WordPress
Конкретные ответы по выбору тарифа: сколько ресурсов нужно под ваш трафик, чем тарифы различаются и на что смотреть, чтобы не переплатить и не упереться в лимиты.
Подбор ресурсов: трафик и тип сайта
Как понять, сколько ресурсов нужно именно моему сайту?
Нагрузка на хостинг определяется двумя вещами, а не «количеством посетителей» само по себе:
Тип сайта. Информационный сайт или блог отдаёт в основном закэшированные страницы — это дёшево по ресурсам. Магазин на WooCommerce, личный кабинет, форум генерируют много некэшируемых страниц (корзина, оформление, поиск) — это в разы тяжелее при том же трафике.
Пиковый трафик. Важны не «посетители в месяц», а сколько запросов приходит в час пик. Грубо: пиковый час ≈ 10–15% дневного трафика.
Практическое правило: сначала определите тип (лёгкий / тяжёлый сайт), затем дневной трафик, затем убедитесь, что включено кэширование. Кэш меняет требования к тарифу в разы — без него даже лёгкий сайт нагружает сервер как тяжёлый.
Сколько ресурсов нужно тарифу при трафике до 5 000 посетителей в сутки?
Ориентир при настроенном полностраничном кэше (LiteSpeed Cache, WP Super Cache и т.п.):
Магазин / динамический сайт (WooCommerce): 2 ядра CPU, 4 ГБ выделенной памяти, PHP memory_limit 256–512 МБ, 15–20 ГБ NVMe, обязательно объектный кэш (Redis). Лучше сразу VPS — страницы корзины и оформления заказа не кэшируются и каждый раз грузят PHP и базу.
Эти цифры предполагают, что кэш реально работает и установлена современная версия PHP. Без полностраничного кэша требования вырастают в 5–10 раз — тогда даже блог с таким трафиком стоит держать на VPS.
Сколько ресурсов нужно тарифу при трафике более 5 000 посетителей в сутки?
На этом уровне shared-тариф почти всегда становится узким местом — ориентируйтесь на VPS:
Магазин / динамический сайт (от 5 000 в сутки): 4 ядра CPU, 6–8 ГБ выделенной памяти, PHP memory_limit 512 МБ, 30–50 ГБ NVMe, Redis обязателен. При активных распродажах и пиках — выделенный сервер.
От 20 000 в сутки: 4+ ядер, 8+ ГБ памяти, выделенный сервер или масштабируемое облако, CDN перед сайтом.
Главный ограничитель при высоком трафике — не «место на диске», а число одновременных PHP-процессов и объём памяти. Поэтому при росте в первую очередь добавляют RAM и CPU, а не диск.
Чем «лёгкий» сайт отличается от «тяжёлого» по нагрузке?
Дело не в дизайне, а в доле некэшируемых запросов:
Лёгкий сайт — блог, лендинг, обзоры, новости. Почти весь контент одинаков для всех посетителей, поэтому его отдаёт кэш напрямую, минуя PHP и базу. Десятки тысяч просмотров в день держит даже скромный тариф.
Тяжёлый сайт — интернет-магазин, личные кабинеты, форум, LMS-курсы, бронирование. Много страниц индивидуальны (корзина, профиль, оформление) и кэшироваться не могут — каждый такой запрос запускает PHP и обращается к базе. При том же трафике это в несколько раз больше нагрузки.
Поэтому для магазина берут тариф с запасом по памяти и CPU и обязательно объектный кэш (Redis), который ускоряет именно динамические запросы.
Сколько одновременных посетителей выдержит тариф и что это ограничивает?
Сам по себе хостинг не считает «посетителей» — он ограничен числом одновременных PHP-процессов (в PHP-FPM это параметр max_children) и доступной памятью. Логика такая:
Посетители, которым отдаётся закэшированная страница, почти не нагружают сервер — их одновременно могут быть тысячи.
Каждый некэшируемый запрос занимает один PHP-процесс на доли секунды. Сколько их поместится одновременно — зависит от памяти: при memory_limit 256 МБ и 2 ГБ свободной RAM это примерно 6–8 параллельных тяжёлых процессов.
Вывод: «выдержит ли тариф трафик» — это в основном вопрос о доле динамики и о памяти. Хорошее кэширование увеличивает потолок в разы без смены тарифа.
Ресурсы тарифа: что есть что
PHP memory_limit и оперативная память тарифа — это одно и то же?
Нет, это два разных параметра, и их часто путают:
PHP memory_limit — лимит памяти на одну генерацию страницы (один PHP-процесс). Измеряется в мегабайтах. Для WordPress рекомендуется 256 МБ, для WooCommerce и тяжёлых плагинов — 256–512 МБ. Если лимит мал, вы увидите ошибку «Allowed memory size exhausted».
Оперативная память тарифа (RAM) — сколько памяти доступно всему аккаунту или серверу. Измеряется в гигабайтах. Из неё одновременно работает несколько PHP-процессов, плюс база данных и веб-сервер.
Проще говоря: memory_limit определяет, потянет ли тариф одну тяжёлую операцию (импорт, конструктор страниц), а общий объём RAM — сколько посетителей одновременно. На дешёвых shared-тарифах в характеристиках иногда указывают именно memory_limit, а не реальную выделенную RAM — это стоит уточнять.
Что важнее для скорости — диск, RAM или процессор?
По степени влияния на типичном WordPress-сайте:
Тип диска (важнее всего). NVMe или SSD дают в разы более быстрый отклик базы данных и файлов, чем устаревшие HDD. Если в тарифе диск HDD — это сразу мимо.
Оперативная память. Определяет, сколько посетителей и фоновых задач сервер тянет одновременно без замедления.
Процессор. Отвечает за скорость генерации динамических страниц; критичен для магазинов и сайтов с тяжёлыми плагинами.
При этом самый большой прирост скорости часто дают не «железо», а кэширование (LiteSpeed Cache, Redis), современная версия PHP и CDN. Нередко они эффективнее, чем переход на более дорогой тариф.
Сколько места на диске нужно и что его «съедает»?
Сама установка WordPress — меньше 100 МБ. Реальный объём занимают:
Изображения и медиа — основной потребитель, особенно если фото не сжимаются.
Резервные копии — если бэкапы хранятся на том же диске, они легко удваивают занятое место.
Кэш и логи — обычно немного, но растут.
Ориентиры: блог или визитка — 5–10 ГБ; контентный сайт с большим архивом — 10–20 ГБ; магазин с каталогом и фото товаров — от 20 ГБ. Берите с запасом и по возможности храните бэкапы отдельно от рабочего диска.
Что на самом деле значит «безлимитный» трафик или диск?
Почти всегда это маркетинг. «Безлимит» ограничен правилами честного использования (fair use): пока сайт потребляет ресурсов «как обычный сайт» — всё хорошо, но при заметном росте провайдер вправе попросить перейти на старший тариф. Поэтому смотрите не на слово «безлимит», а на реальные лимиты: объём RAM, число ядер CPU, число одновременных процессов (entry processes / max_children) и количество inode (файлов). Именно в них вы упрётесь первыми, а не в «гигабайты трафика».
Типы хостинга и когда что выбирать
В чём разница между shared-хостингом, VPS и выделенным сервером?
Это три уровня по мощности, изоляции и контролю:
Shared (виртуальный) хостинг. Сайт делит сервер с другими, ресурсы общие. Дёшево и просто, ставится без навыков администрирования. Подходит для блога, визитки, небольшого магазина и старта проекта.
VPS. Вам выделена гарантированная часть сервера (своя RAM, CPU, диск), соседи на вас не влияют. Дороже и требует чуть больше настройки (или берите managed-VPS). Нужен при росте трафика, для магазинов и нескольких проектов.
Выделенный сервер. Вся машина ваша. Для крупных проектов, высокой и неравномерной нагрузки.
Для первого сайта почти всегда правильный старт — shared, с возможностью апгрейда. На VPS переходят по конкретным признакам (см. вопрос ниже), а не «на всякий случай».
Когда пора переходить с shared-хостинга на VPS?
Переходите, если совпадает хотя бы одно:
Стабильно больше ~5 000 посетителей в сутки на информационном сайте либо заметный трафик на магазине.
Сайт тяжёлый: WooCommerce с активными заказами, форум, личные кабинеты, LMS.
Провайдер уже присылает предупреждения о превышении лимитов CPU или числа процессов, сайт периодически отдаёт ошибки 503/508.
Нужны свои настройки сервера (версии ПО, Redis, специфические модули), которых нет на shared.
Несколько проектов с трафиком, которым тесно делить общие ресурсы.
Если же сайт просто «иногда подтормаживает», сначала проверьте кэш, версию PHP и тяжёлые плагины — часто проблема в них, а не в тарифе.
Что такое «управляемый» (managed) WordPress-хостинг?
Это тариф, где провайдер берёт на себя техническую рутину: обновления ядра и плагинов, безопасность, кэширование, бэкапы, мониторинг, иногда персональную поддержку по WordPress. Вы платите больше, но почти не занимаетесь администрированием. Хороший выбор, если не хотите вникать в технику или цените время дороже денег. На обычном тарифе всё то же возможно, но настраивать и следить нужно самому.
Технические требования
Какая версия PHP нужна для WordPress?
WordPress формально работает с PHP 7.4, но рекомендуется PHP 8.1 и новее — это заметно быстрее и безопаснее, разница в скорости относительно PHP 7.x хорошо заметна. Хороший хостинг позволяет переключать версию PHP в панели в один клик. Перед сменой проверьте совместимость тем и плагинов (удобно на копии сайта / staging).
Какая база данных нужна и сколько баз?
WordPress хранит контент в базе MySQL (от 5.7) или MariaDB (от 10.4) — это есть на любом современном хостинге по умолчанию. Одному сайту нужна одна база. Если планируете несколько сайтов, проверьте, не ограничено ли число баз на тарифе.
Можно ли разместить несколько сайтов на одном тарифе?
Часто да, но смотрите ограничения плана: бывает лимит на число сайтов, баз данных, доменов или поддоменов. Важный момент: все сайты делят общие ресурсы тарифа, поэтому если каждый с трафиком — лучше старший тариф или отдельные планы, иначе они будут «тормозить» друг друга в часы пик.
Как установить WordPress — это сложно?
Нет. Почти везде есть автоустановщик (Softaculous и аналоги): WordPress ставится в несколько кликов прямо из панели, без ручной работы с файлами и базой, логин и пароль задаются в процессе. Ручная установка тоже возможна, но новичку не нужна.
Скорость и работа на украинскую аудиторию
Что реально ускоряет WordPress, кроме мощного тарифа?
Чаще всего наибольший прирост дают четыре вещи:
Полностраничное кэширование (LiteSpeed Cache на серверах LiteSpeed, либо WP Super Cache / W3 Total Cache). Готовая страница отдаётся без запуска PHP.
Объектный кэш Redis — ускоряет динамику и админку, особенно важен для магазинов.
CDN — раздаёт изображения и статику с серверов ближе к посетителю.
Современный PHP 8.x и оптимизация изображений (WebP, сжатие).
Нередко связка «кэш + CDN + PHP 8» даёт больше, чем переход на вдвое более дорогой тариф.
Важно ли, где физически находится сервер (дата-центр)?
Да, по двум причинам. Скорость: чем ближе сервер к аудитории, тем ниже задержка и быстрее отклик (TTFB). Если посетители из Украины — сервер в Украине или ближней Европе ощутимо лучше, чем, например, в США. Локальные сервисы и данные: близкое расположение упрощает работу с украинскими платёжными и другими сервисами. Удалённую географию частично сглаживает CDN для статики, но динамические запросы (корзина, вход) всё равно идут на основной сервер — поэтому его локация важна.
Нужны ли серверы в Украине и защита от DDoS?
Для проекта с украинской аудиторией это не маркетинг, а практическая потребность. Сервер в Украине даёт лучший отклик для местных посетителей. DDoS-защита снижает риск простоя при атаках, которые для украинских сайтов в последние годы стали обыденностью. Если аудитория локальная и важна стабильная доступность — выбирайте тариф с украинской (или близкой европейской) локацией и встроенной защитой от DDoS, уточняя, входит ли она в стоимость.
Безопасность и надёжность
Делает ли хостинг резервные копии и можно ли восстановить сайт?
Это самый важный пункт — уточняйте его до покупки. Хорошие провайдеры делают автоматические бэкапы (в идеале ежедневные) и хранят их несколько дней или недель, а восстановление доступно вам самому из панели в один клик. Не полагайтесь только на хостинг: настройте и собственные копии (плагином или вручную) и храните их отдельно — так данные будут как минимум в двух местах. Заранее проверьте, что восстановление реально работает, а не только «бэкап создаётся».
Защитит ли хостинг мой сайт от взлома?
Хостинг отвечает за инфраструктуру: сетевой экран, защита от DDoS, антивирусное сканирование файлов, изоляция аккаунтов. Но значительная часть безопасности WordPress — на вашей стороне: своевременные обновления ядра и плагинов, надёжные пароли и двухфакторная аутентификация, плагины только из проверенных источников, плагин безопасности и ограничение попыток входа. Хостинг создаёт условия, но «неубиваемых» сайтов не бывает — защита всегда совместная.
Что такое SSL-сертификат и нужно ли за него платить?
SSL включает шифрование: адрес становится https:// с замком в браузере. Сегодня он обязателен — без него браузеры помечают сайт «небезопасным», что отпугивает посетителей и вредит позициям в поиске. Большинство хостингов выдают бесплатный сертификат Let's Encrypt, и для обычного сайта его полностью достаточно. Платные сертификаты (с расширенной проверкой) нужны в основном крупному бизнесу и банкам.
Что такое uptime и какая гарантия считается нормальной?
Uptime — доля времени, когда сайт доступен. Адекватный ориентир — 99.9%, это около 8–9 часов простоя в год; 99.99% — около 52 минут в год. Серьёзные провайдеры фиксируют гарантию в SLA. На цифру из рекламы смотрите вместе с независимыми отзывами и историей аптайма — реальная стабильность важнее обещанной.
Перенос и управление
Можно ли перенести существующий сайт и не потерять его в процессе?
Да, и при правильном порядке сайт не «падает». Три способа:
Бесплатный перенос силами поддержки — многие провайдеры делают это за вас; лучший вариант для новичка. Уточните, входит ли в тариф и сколько сайтов покрывает.
Плагином миграции — почти без ручной работы, подходит для большинства сайтов.
Вручную — копирование файлов и перенос базы, для уверенных пользователей.
Правильный порядок: сначала разворачивают и проверяют копию на новом хостинге, и только потом переключают домен (DNS). Старый хостинг стоит подержать активным ещё несколько дней, пока обновятся DNS у всех посетителей.
Какая панель управления используется и нужно ли уметь работать в командной строке?
Чаще всего это cPanel или аналог — графический интерфейс для управления файлами, базами, почтой, доменами, SSL и бэкапами. Командная строка для базовых задач не нужна: всё делается мышкой. Это особенно важно для новичка — порог входа минимальный.
Есть ли тестовая (staging) среда и зачем она нужна?
На части тарифов — да. Staging — это копия сайта, где можно безопасно обновлять плагины, менять тему и тестировать правки, не трогая «живой» сайт; после проверки изменения переносятся в рабочую версию. Если планируете активно дорабатывать сайт, наличие staging заметно снижает риск что-то сломать на виду у посетителей.
Входит ли в тариф почта на моём домене?
Часто да — ящики вида name@вашсайт.com обычно доступны на хостинге; смотрите лимиты по числу ящиков и объёму. Для бизнеса с большим потоком писем (рассылки, уведомления магазина) иногда надёжнее отдельный почтовый сервис, чтобы письма не попадали в спам и не зависели от ресурсов хостинга.
Домен, стоимость и масштабирование
Домен входит в стоимость хостинга?
Иногда домен дают бесплатно на первый год, иногда его нужно оплачивать отдельно — это разные услуги: хостинг это «место» для сайта, домен это его адрес. Если домен уже есть у другого регистратора, его легко привязать к новому хостингу, менять регистратора не обязательно.
Почему цена продления выше стартовой цены?
Это распространённая практика: низкая цена действует на первый период (часто за счёт большой скидки), а продление идёт по обычному тарифу. Перед покупкой всегда смотрите цену продления, а не только стартовую, и считайте стоимость владения хотя бы на 2 года — так не будет неприятного сюрприза через год.
Есть ли гарантия возврата денег или пробный период?
У многих провайдеров есть период возврата средств (часто 14–30 дней), если хостинг не подошёл. Уточните условия: на что распространяется гарантия и что обычно не возвращается (например, стоимость уже зарегистрированного домена). Это снижает риск при выборе.
Что делать, если сайт перерастёт тариф?
Переходить на старший план. Нормальный хостинг позволяет апгрейд без переноса и без простоя — вы просто получаете больше ресурсов на том же аккаунте. Поэтому разумно стартовать с тарифа под текущие задачи и повышать его по мере роста, а не переплачивать «на будущее» заранее.
Альтернативы
Чем хостинг для WordPress отличается от конструктора сайтов?
Конструктор («собери сайт мышкой») — закрытая платформа: проще на старте, но вы ограничены её возможностями и привязаны к ней, перенести проект некуда. WordPress на хостинге даёт полную свободу: тысячи тем и плагинов, доступ к файлам и базе, возможность сменить хостинг или подрядчика в любой момент. Порог входа чуть выше, зато сайт полностью ваш и масштабируется без потолка. Для бизнеса, который планирует расти, это обычно выгоднее в долгую.
Нужен ли вообще отдельный «WordPress-хостинг»?
Не обязательно. WordPress работает на любом хостинге с PHP и MySQL/MariaDB. Но тарифы с пометкой «для WordPress» обычно уже настроены под него: подходящая версия PHP, кэширование (часто LiteSpeed), иногда автообновления и преднастроенная защита. Новичку с таким тарифом проще — меньше нужно настраивать руками и меньше шансов на ошибку.
