WordPress-сайт после запуска остаётся работающей программой на вашем сервере, а не памятником, который один раз поставили и забыли: у неё есть версии, зависимости, обновления безопасности и точки отказа. Через полгода после запуска у 8 из 10 проектов, которые приходят к нам «на посмотреть», обнаруживается один и тот же набор проблем: ядро не обновлялось, половина плагинов устарела, резервных копий нет либо они лежат на том же сервере, что и сам сайт, а форма заявки тихо перестала отправлять письма два месяца назад — и никто этого не заметил.
Разберём по пунктам, что такое техподдержка сайта WordPress на практике, какие работы должны быть в договоре, где проходит граница между поддержкой и доработками, и из чего в реальности складывается стоимость поддержки сайта.
Почему WordPress требует регулярного обслуживания
WordPress — самая распространённая CMS в мире, и именно поэтому она под постоянным вниманием тех, кто ищет уязвимости. Атакуют не конкретно ваш сайт: боты перебирают тысячи адресов и проверяют известные дыры в популярных плагинах. Если плагин не обновлён с прошлого года, а публичное описание уязвимости уже опубликовано, взлом становится вопросом статистики, а не мотивации злоумышленника.
Вторая причина — сама архитектура. Типовой корпоративный сайт на WordPress состоит из ядра, темы (часто с дочерней темой и кастомным кодом) и 15-30 плагинов от разных разработчиков. Каждый из них обновляется по своему графику. Обновление одного плагина может конфликтовать с другим, а обновление PHP на хостинге — сломать сразу оба. Это не недостаток WordPress, это плата за модульность: система собирается из независимых частей, и кто-то должен следить, чтобы части оставались совместимыми.
Третья причина — окружение. Официальные требования WordPress рекомендуют PHP версии 8.3 или выше и MariaDB 10.11+ либо MySQL 8.0+, а HTTPS указан как обязательный для каждой установки. Более старые версии (PHP 7.4+, MySQL 5.5.5+) формально ещё запускают WordPress, но они достигли конца жизненного цикла и не получают исправлений безопасности. Хостинг-провайдеры периодически поднимают версии PHP на своей стороне — иногда с уведомлением, иногда по факту. Если тема или плагин написаны под старый PHP, сайт встречает посетителей белым экраном.
Что входит в техподдержку сайта на WordPress
Формулировка «поддержка сайта» в коммерческих предложениях часто означает совершенно разные вещи — от «ответим на письмо в течение недели» до полноценного сопровождения с мониторингом и SLA. Ниже — состав работ, который мы считаем минимально осмысленным.
Обновления ядра, плагинов и темы
WordPress сам решает часть этих задач, остальное остаётся на человеке. По умолчанию на уже существующих установках автоматически применяются только минорные обновления ядра и файлы переводов; на новых установках, начиная с версии 5.6, автообновления охватывают и минорные, и мажорные релизы. Плагины и темы система обновляет автоматически лишь в особых случаях — при критических уязвимостях, по решению API WordPress.org. Поведение ядра управляется константой WP_AUTO_UPDATE_CORE (значения true, false или 'minor'), а полностью отключить автообновления можно константой AUTOMATIC_UPDATER_DISABLED — правда, документация прямо не рекомендует так делать.
С версии WordPress 5.5 в админке появились переключатели автообновлений для каждого плагина и темы по отдельности. Соблазн включить всё и забыть велик, но на боевом сайте это плохая идея: автообновление мажорной версии плагина корзины в пятницу вечером — сценарий, после которого понедельник начинается с восстановления из бэкапа. Разумная схема выглядит так: критические обновления безопасности применяются сразу, остальные — пакетом по расписанию, сначала на тестовой копии, потом на бою, с проверкой ключевых сценариев после каждого пакета.
Резервное копирование и проверка восстановления
Полная резервная копия WordPress состоит из двух частей, и это принципиально. Первая — файлы: ядро, темы, плагины, загрузки, wp-config.php, .htaccess. Вторая — база данных MySQL/MariaDB, где хранятся все записи, страницы, настройки и комментарии. Копирование файлов само по себе базу не сохраняет. Документация рекомендует бэкапить сначала базу, затем файлы, а восстанавливать в обратном порядке: сначала файлы, потом импорт базы.
Отдельный пункт, который выпадает почти у всех: копии нужно периодически проверять разворачиванием. Резервная копия, которую ни разу не восстанавливали, — это не резервная копия, а предположение. И хранить её на том же сервере, где живёт сайт, бессмысленно: при потере доступа к серверу вы потеряете и то, и другое.
Мониторинг доступности и производительности
Задача мониторинга — узнать о падении раньше клиента. Минимум: проверка доступности главной и одной-двух ключевых страниц с интервалом в несколько минут, контроль срока действия SSL-сертификата и домена, отслеживание времени ответа сервера. Более зрелый уровень — контроль работоспособности форм (тестовая отправка), проверка отдачи писем, слежение за размером базы и логами ошибок PHP.
Отдельная невидимая проблема — планировщик задач. WP-Cron в WordPress по умолчанию запускается при загрузке страниц, а не по системному расписанию. На сайте с низкой посещаемостью это означает, что отложенные публикации, рассылки и фоновые задачи могут не выполниться вовремя. Правильное решение — отключить встроенный механизм константой DISABLE_WP_CRON в wp-config.php и вызывать wp-cron.php реальным системным планировщиком с нужной частотой.
Безопасность
Базовая гигиена: HTTPS на всём сайте, ограничение попыток входа, двухфакторная аутентификация для администраторов, разделение ролей (редактор не должен иметь прав администратора), удаление неиспользуемых плагинов и тем — не отключение, а именно удаление, потому что уязвимый код в отключённом плагине всё равно лежит на сервере. Плюс регулярный аудит: кто имеет доступ, откуда заходят, не появились ли лишние учётные записи.
Контентные и мелкие правки
Практическая часть, ради которой поддержку чаще всего и покупают: поменять текст на странице, добавить сотрудника в раздел «Команда», заменить баннер, поправить вёрстку карточки, добавить страницу услуги, настроить редирект после удаления старого раздела. По отдельности это мелочи, но у бизнеса без своего разработчика они копятся неделями.
Тестовая среда
Отдельная копия сайта, на которой обновления и правки проверяются до боевого применения. Это не роскошь: разница между «обновили, проверили на копии, выкатили» и «обновили на бою и смотрим, что будет» — это и есть разница между поддержкой и рулеткой.
Что в техподдержку обычно не входит
Здесь возникает большинство конфликтов между заказчиком и подрядчиком, поэтому границу лучше зафиксировать письменно на старте. Как правило, за рамками абонентской поддержки остаются:
- Редизайн и новые разделы. Поправить существующий блок — поддержка. Спроектировать и сверстать новую посадочную страницу — проект, который считается отдельно.
- Новая функциональность. Интеграция с 1С, личный кабинет, калькулятор стоимости, подключение эквайринга — это разработка. Такие задачи мы выносим в отдельную смету, а сам сайт при необходимости берём в разработку сайтов под ключ, если текущая реализация уже не тянет требования бизнеса.
- SEO-продвижение и контент. Техподдержка отвечает за то, чтобы сайт был доступен, быстр и корректно индексировался технически. Написание статей, работа с семантикой и ссылочным профилем — другая услуга.
- Реклама и аналитика. Установить счётчик — обычно входит. Настраивать цели, вести кампании и разбирать отчёты — нет.
- Оплата сторонних сервисов. Хостинг, домен, платные лицензии плагинов, SMS-шлюзы — расходы клиента, а не подрядчика, если в договоре явно не написано обратное.
Признаки, что сайту нужна поддержка прямо сейчас
Быстрый чек-лист для самопроверки. Если хотя бы два пункта совпали, откладывать не стоит.
- В админке висит уведомление об обновлениях, и вы не помните, когда его последний раз закрывали осознанно.
- Вы не можете назвать дату последней резервной копии и место, где она лежит.
- Заявки с форм приходят реже, чем раньше, но объяснения этому нет — а проверить отправку никто не пробовал.
- Сайт стал заметно медленнее открываться, особенно с телефона.
- В списке пользователей есть учётные записи людей, которые давно не работают в компании.
- Хостинг присылает письма про версию PHP, и они уходят в папку «прочитаю позже».
Каждый из этих пунктов сам по себе не катастрофа. Проблема в том, что они накапливаются одновременно и обычно проявляются разом — в момент, когда на сайт идёт трафик из рекламы или начинается сезон.
Из чего складывается стоимость поддержки сайта
Универсального ценника нет — и любой, кто называет его до знакомства с сайтом, называет цену за что-то другое. Стоимость определяется несколькими факторами.
Сложность технического стека. Сайт-визитка на популярной теме с десятком плагинов и интернет-магазин на WooCommerce с несколькими тысячами товаров, синхронизацией остатков и настроенной доставкой — это разный объём регулярной работы. Магазин требует внимания к каждому обновлению, потому что цена ошибки — остановленные продажи.
Количество и происхождение кастомного кода. Если сайт собран из стандартных компонентов, обновления проходят предсказуемо. Если предыдущий подрядчик правил файлы ядра или родительской темы напрямую (а такое встречается регулярно), каждое обновление рискует стереть эти правки — и поддержка начинается с приведения проекта в поддерживаемое состояние.
Требуемое время реакции. Реакция в течение рабочего дня и реакция в течение часа, включая выходные, стоят по-разному, потому что второе требует дежурства. Это, пожалуй, самый недооценённый пункт: заказчик часто платит за «быструю поддержку», не проверив, зафиксирована ли скорость в договоре хоть каким-то числом.
Объём часов на правки. Основная переменная в абонентской модели. Бизнес, который обновляет сайт раз в квартал, и компания, которая еженедельно выкладывает акции и меняет цены, потребляют принципиально разное количество часов.
Ответственность за инфраструктуру. Одно дело — поддерживать сайт на хостинге, где всё уже настроено. Другое — отвечать ещё и за сервер: обновления ОС, веб-сервера, PHP, настройку кэширования и почты.
Три модели оплаты
Абонентская плата с пакетом часов. Самая распространённая схема: фиксированная сумма в месяц включает обслуживание (обновления, бэкапы, мониторинг) плюс определённое количество часов на задачи. Предсказуемо для обеих сторон. Важные детали, которые надо уточнить до подписания: переносятся ли неизрасходованные часы на следующий месяц, по какой ставке считаются часы сверх пакета и входят ли аварийные работы в общий счётчик.
Почасовая оплата. Подходит проектам, где задачи возникают редко и непредсказуемо. Минус — при почасовой модели никто не выполняет профилактику: за неё никто не платит, и о проблеме узнают, когда она уже случилась.
Инцидентная модель. Оплата за факт решения проблемы. Выглядит экономно, но экономика обманчива: восстановление взломанного сайта почти всегда дороже, чем год профилактики, а часть последствий (потерянные заявки, просевшие позиции, письма клиентам от имени вашего домена) деньгами не отыгрывается.
Как посчитать бюджет: разбор на примере
Возьмём условный, но типичный для Алматы кейс — производственная компания с корпоративным сайтом на WordPress. Пример иллюстративный, но пропорции взяты из реальной практики.
Исходные данные: сайт сделан три года назад, около 60 страниц, каталог продукции без корзины, четыре формы заявки, интеграция с CRM через вебхук, 24 плагина, дочерняя тема с правками. Обновления не делались полтора года. Сайт работает.
Что обнаруживается на аудите: ядро отстаёт на несколько версий, 11 плагинов имеют доступные обновления, два из них давно не поддерживаются разработчиком, PHP на хостинге — версия, снятая с поддержки, бэкапов нет вообще, а одна из форм не доходит до CRM примерно с весны, потому что на стороне CRM поменялся адрес вебхука.
Работы делятся на два блока. Первый — стартовый, разовый: развернуть тестовую копию, обновить всё пошагово с проверкой, заменить два заброшенных плагина аналогами, поднять PHP, настроить бэкапы на внешнее хранилище, починить интеграцию, подключить мониторинг. Это проект на несколько десятков часов, и он считается отдельно от абонентки — по факту состояния сайта, которое до аудита никто не знает.
Второй блок — ежемесячный: пакет обновлений с проверкой на копии, контроль бэкапов, мониторинг, разбор логов, плюс часы на контентные правки. Здесь месяц на месяц не приходится: в один уходит два часа, в другой — восемь, поэтому пакетная модель удобнее почасовой обеим сторонам.
Практический вывод из этого примера простой: корректную цену поддержки нельзя назвать до аудита. Подрядчик, который называет сумму по описанию «у нас сайт на Вордпрессе», либо заложил риск с запасом, либо позже придёт с дополнительным счётом.
Как выбрать подрядчика и что проверить в договоре
Несколько вопросов, ответы на которые стоит получить до оплаты первого месяца.
Где хранятся резервные копии и как часто они делаются? Ответ «на хостинге, там есть бэкапы» — недостаточный. Нужны отдельное хранилище, понятная глубина хранения и подтверждённая процедура восстановления.
Кто владеет доступами? Домен, хостинг и админка должны быть оформлены на вашу компанию, а подрядчик — иметь свои учётные записи. Ситуация, когда домен зарегистрирован на личную почту бывшего фрилансера, встречается чаще, чем хотелось бы, и решается тяжело.
Как фиксируются задачи? Переписка в мессенджере не является системой учёта. Должен быть трекер или хотя бы общая таблица, где видно постановку, статус и потраченное время. Иначе в конце месяца обе стороны будут по-разному помнить, что было сделано.
Есть ли отчётность? Ежемесячный отчёт с перечнем работ, потраченными часами и состоянием сайта — норма, а не одолжение.
Что происходит при расставании? В договоре стоит прописать передачу доступов, актуальной резервной копии и документации. Это дешёвая страховка, которая экономит недели, если сотрудничество не сложится.
Что можно закрыть своими силами
Часть работ владелец сайта или системный администратор в штате вполне может вести самостоятельно. Включить автообновления для некритичных плагинов и переводов. Настроить плагин резервного копирования с выгрузкой во внешнее облако. Поставить бесплатный аптайм-мониторинг. Завести регламент: кто и когда меняет пароли, кому создаются учётные записи и кто их отзывает при увольнении сотрудника.
Границу разумного самостоятельного вмешательства провести несложно. Всё, что делается через админку и обратимо, — можно. Всё, что требует правки wp-config.php, работы с базой напрямую, изменения версии PHP или редактирования файлов темы, — стоит делать либо на тестовой копии, либо руками того, кто потом отвечает за результат. Самая дорогая категория аварий в нашей практике — не взломы, а правки «по инструкции из интернета», сделанные сразу на боевом сайте без резервной копии.
Техподдержка сайта на WordPress в итоге сводится к простому обмену: вы платите за предсказуемость вместо аварий. Сайт, за которым следят, живёт годами на одной и той же теме, обновляясь по расписанию и почти не требуя внимания руководителя. Сайт без обслуживания рано или поздно приходит к точке, где дешевле сделать новый, чем чинить старый, — и почти всегда это выясняется в неподходящий момент. Если вы сейчас не можете ответить, когда в последний раз обновлялось ядро вашего сайта и где лежит его свежая резервная копия, разумно начать с технического аудита: он покажет реальный объём работ и стоимость поддержки без гаданий.
Частые вопросы
Можно ли обойтись без техподдержки, если сайт простой и редко меняется?
Редкие изменения контента не отменяют обновлений безопасности. Боты сканируют сайты независимо от того, обновляли вы страницу «О компании» или нет. Для простого сайта поддержка может быть минимальной по объёму — обновления, бэкапы, мониторинг, — но полностью отказываться от неё рискованно.
Почему нельзя просто включить все автообновления и не платить за поддержку?
Автообновления решают часть задачи, но не всю. WordPress по умолчанию сам обновляет ядро в минорных версиях и переводы, а плагины и темы — только в особых случаях. Кроме того, автообновление может сломать сайт при конфликте версий, и без резервной копии и мониторинга вы узнаете об этом от клиента, а не от системы.
Что делать, если сайт уже взломали?
Первым делом ограничить доступ к сайту и сохранить текущее состояние вместе с логами — они понадобятся, чтобы понять точку входа. Дальше восстанавливают из заведомо чистой резервной копии, обновляют всё окружение, меняют все пароли и ключи, закрывают уязвимость, через которую пришли. Восстановление без поиска причины приводит к повторному взлому.
Сколько часов в месяц закладывать на поддержку корпоративного сайта?
Зависит от активности бизнеса на сайте. Ориентир такой: обслуживающая часть (обновления, бэкапы, мониторинг, проверки) для типового корпоративного сайта занимает несколько часов в месяц, а всё сверх этого — контентные правки и мелкие доработки, объём которых определяется вашими планами. Точную цифру даёт первый-второй месяц работы.
Нужна ли тестовая копия сайта, если проект небольшой?
Тестовая среда особенно оправдана там, где сайт приносит заявки или продажи, — то есть почти везде. Разворачивание копии сегодня недорого, а стоимость одного часа простоя на боевом сайте с рекламным трафиком легко перекрывает эти расходы.