Managed-хостинг для WordPress

Что такое managed-хостинг и за что вы платите

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

Ключевое для понимания: вы платите не за железо, а за чужое время и ответственность. Сравнение по характеристикам здесь вводит в заблуждение. Managed-тариф за 500 ₽ может давать меньше памяти и слабее процессор, чем VPS за те же 500 ₽ — и это нормально, потому что в цену VPS не входит человек, который настроит стек, накатит обновления и поднимет сайт в три часа ночи.

Отсюда простой способ проверить, стоит ли переплата: посчитайте, сколько часов в месяц вы тратите (или собираетесь тратить) на обслуживание сайта, и умножьте на стоимость своего часа. Если получилось больше разницы в цене — managed выгоднее. Если вы не тратите на сервер ни часа, потому что и не собирались, — вопрос звучит иначе: кто будет обновлять систему и чинить сайт после падения? На виртуальном хостинге этим занимается провайдер в базовом объёме, на VPS — никто, кроме вас.

Что должно входить в настоящий managed

Слово «managed» никак не защищено, и его лепят на обычные shared-тарифы. Шесть пунктов, по которым отличается настоящее предложение:

1. Автоматические обновления ядра и плагинов с откатом. Не «мы иногда обновляем», а регламент: что именно обновляется, с какой периодичностью, что происходит при поломке. Обновления безопасности должны ставиться немедленно, мажорные версии — по расписанию с проверкой.

2. Staging-окружение. Копия сайта для тестов, в идеале с переносом изменений на прод в один клик. Без staging любое обновление плагина — это эксперимент на живых посетителях. Именно этого пункта чаще всего не хватает у тарифов, которые называют себя managed.

3. Преднастроенный объектный кэш. Redis или Memcached, уже подключённый к WordPress, а не «можно установить самому». Проверить легко: в «Инструменты → Здоровье сайта» должен быть виден постоянный объектный кэш. Если его нет, вы платите за managed, но получаете производительность обычного shared.

4. Ежедневные бэкапы с глубиной от 30 дней и самостоятельным откатом из панели. Глубина важнее частоты: порчу данных или взлом обнаруживают через неделю-две, и семидневного архива к этому моменту уже не хватает.

5. WAF и защита от брутфорса на уровне платформы, до запуска PHP. Разница принципиальная: плагин безопасности отбивает атаку, уже потратив на неё PHP-процесс и запрос к базе, платформенный фильтр отсекает её раньше и не тратит ваши ресурсы.

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

Правило проверки: если в описании тарифа нет хотя бы трёх пунктов из шести — перед вами обычный shared с наклейкой «для WordPress». Наклейка часто означает всего лишь автоустановщик и преднастроенный .htaccess, что само по себе неплохо, но за это не платят двойную цену.

Ещё два признака, по которым видно серьёзность предложения: публичный регламент обновлений (а не общие слова в поддержке) и SLA с указанием времени реакции. Если на вопрос «за сколько вы отвечаете на критичный тикет ночью» вам отвечают «мы стараемся быстро» — это не managed.

Managed, shared и VPS: чем отличаются на практике

Правило выбора в одну фразу: shared — когда сайт простой и бюджет главный; VPS — когда нужен контроль и есть кому администрировать; managed — когда нужна надёжность, а администрировать некому.

Ограничения, о которых не пишут на лендинге

Managed — это компромисс, и честно назвать его цену стоит до покупки.

Список запрещённых плагинов. Под запретом обычно всё, что дублирует платформу: кэширующие плагины, бэкап-плагины, агрессивные «оптимизаторы базы», плагины, меняющие конфигурацию сервера. Логика понятна — два слоя кэша поверх друг друга приводят к тому, что посетители видят чужие или устаревшие страницы. Но если ваш сайт годами собирался вокруг конкретного кэш-плагина с тонкими настройками, переезд потребует переделки.

Невозможность менять стек. Не поставить своё расширение PHP, не собрать Nginx с нужным модулем, не поднять рядом сервис на Node.js. Для 95% сайтов это не ограничение вовсе, но если у вас есть интеграция, требующая специфического софта, — уточняйте заранее.

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

Ограниченный доступ к базе. Где-то phpMyAdmin есть, где-то только через панель провайдера, где-то нужен запрос в поддержку. Для сайта с регулярными выгрузками это существенно.

Кого эти ограничения не заденут: типовой корпоративный сайт, блог, магазин на стандартном стеке WooCommerce, клиентские проекты агентства. Кого остановят: проекты с самописными интеграциями, нестандартным софтом и требованием полного контроля — им нужен VPS.

Автообновления: страховка и риск одновременно

Автообновления — главная ценность managed и одновременно источник самых неприятных сюрпризов.

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

Как это бывает у тех, кто просто написал «автообновления» в списке фич: раз в неделю запускается wp plugin update --all, и в понедельник утром вы узнаёте, что обновление конструктора страниц поехало по вёрстке на половине сайта.

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

Что уточнить у провайдера до переезда:

• обновления идут сразу на прод или сначала на staging;
• есть ли автоматическая проверка после обновления и какая;
• сколько времени занимает откат и делаете ли вы его сами из панели;
• можно ли исключить конкретные плагины из автообновления — на кастомных сайтах это самая нужная опция;
• обновляется ли только ядро или ядро и плагины.

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

Чего managed не делает

Ожидания от managed-хостинга часто завышены, и разочарование потом переносят на провайдера. Полезно заранее очертить границу.

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

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

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

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

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

Кому managed окупается

Считаем в деньгах. Разница между приличным shared за 150–200 ₽ и managed за 400–500 ₽ — около 3 000–4 000 ₽ в год. Это примерно один час работы приходящего администратора. То есть managed окупается, если обслуживание отнимает больше часа в год — а оно отнимает больше в любом сценарии, где сайт живой.

Окупается точно:

• Интернет-магазин. Каждый час простоя — потерянные заказы, и сумма потерь обычно превышает годовую разницу в тарифах.
• Сайт клиента, который не хочет вникать. Заказчику не нужен доступ к панели и разговоры про версии PHP — ему нужно, чтобы работало.
• Агентство с десятком проектов. Обновлять двадцать сайтов вручную — это отдельная штатная задача, а раз в год кто-нибудь обязательно забудет.
• Сайт, приносящий деньги напрямую — заявки, бронирования, подписки.

Не окупается:

• Личный блог с редким обновлением и трафиком из закладок.
• Сайт-визитка, который не меняется годами.
• Проект, где уже есть свой разработчик и админ-часы всё равно оплачены.
• Сайт с нестандартным стеком, который в managed просто не заработает.

Два расчёта для наглядности. Агентство с 10 клиентскими сайтами: переплата за managed — около 35 000 ₽ в год на весь портфель. Ручное обслуживание десяти сайтов — это проверка обновлений раз в две недели, примерно 30 минут на сайт, то есть 130 часов в год. При ставке даже 800 ₽/час получается 104 000 ₽ — разница в три раза не в пользу ручного режима, и это без учёта одного забытого обновления, которое закончится взломом.

Магазин с оборотом 500 000 ₽ в месяц: час простоя в рабочее время стоит примерно 2 000–3 000 ₽ упущенной выручки, не считая брошенных корзин и рекламного бюджета, слитого на недоступный сайт. Годовая переплата за managed окупается двумя часами простоя, которых не случилось.

Managed в рунете: что предлагают провайдеры

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

Сразу оговорка: полноценного managed в западном понимании — с автообновлениями по регламенту, staging в один клик и скриншот-тестами — в рунете почти нет. Ближе всего к нему подходят старшие тарифы обычных провайдеров, где к хостингу добавляется сопровождение.

Beget — тестовый период 30 дней, самый длинный в каталоге, изоляция сайтов на всех тарифах, безлимит баз и доменов, бесплатный перенос силами поддержки. Для managed это важно: за месяц видно и качество поддержки, и поведение сайта под реальной нагрузкой. Стартовая цена самая высокая — 420 ₽/мес за тариф на пять сайтов.

NetAngels — единственный в каталоге, кто прямо заявляет Redis и Memcached на виртуальных тарифах, плюс контейнерную изоляцию и хранение бэкапов в отдельных дата-центрах. Это ровно те пункты, ради которых берут managed. Минус — тестового периода нет, а дата-центр в Екатеринбурге.

Timeweb — собственные ЦОД в Москве и Петербурге, бесплатный перенос, три домена в комплекте, заявленный аптайм 99,98% и обещание решать 80% обращений за первые 10 минут. Тестовый период 10 дней — вдвое короче, чем у SpaceWeb, и втрое короче, чем у Beget.

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

Сравнение по TTFB, аптайму, цене второго года и скорости поддержки — в рейтинге хостингов, общие критерии выбора — в чек-листе.

Как переехать на managed

Порядок, при котором переезд проходит без сюрпризов:

1. Сверьте плагины со списком запрещённых у нового провайдера. Обычно вылетают кэширующие и бэкап-плагины — их надо просто деактивировать, платформа делает то же самое.
2. Закажите бесплатный перенос или сделайте сами. Поддержка Beget, Timeweb, NetAngels и Джино переносит бесплатно, срок обычно 1–2 рабочих дня. Если делаете сами — держите под рукой пошаговый порядок переноса, там же про переключение DNS без простоя.
3. Разверните копию на staging и проверьте её до переключения домена. Прописать новый IP в файле hosts на своём компьютере — самый простой способ увидеть сайт на новом сервере, пока DNS ещё смотрит на старый.
4. Проверьте формы и платежи на копии: отправка заявки, письмо администратору, тестовая оплата, вебхук платёжного шлюза.
5. Понизьте TTL DNS-записи до 300 секунд за сутки до переезда — тогда переключение займёт минуты, а не часы.
6. Переключите A-запись и следите за логами первые пару часов.

Что обязательно проверить после переезда, потому что ломается именно это:

• Письма с сайта. Новый сервер — новый IP, и почтовые провайдеры относятся к нему настороженно. Настройте отправку через SMTP с аутентификацией, пропишите SPF и DKIM.
• Cron-задачи. Системный cron на старом хостинге не переезжает вместе с файлами. Проверьте, что запланированные задачи выполняются, а не копятся.
• Пути к загрузкам. После переноса ссылки на файлы иногда остаются с абсолютным путём старого сервера — проверьте медиатеку и картинки в старых записях.
• SSL и редиректы. Сертификат должен выпуститься на новом сервере, а редиректы с www и с http — сохраниться.
• robots.txt и индексация. На staging-копии обычно стоит запрет индексации — убедитесь, что он не переехал в прод вместе с сайтом.

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