5 критических ошибок при делегировании поддержки сайта на WordPress внешней компании

Средний простой сайта из-за некорректного обновления плагинов или ошибки в php.ini обходится бизнесу в потерю от 5% до 15% конверсии в сутки. Делегирование поддержки WordPress внешней компании без жесткого регламента превращает актив в «цифровую бомбу», которая детонирует в пик сезона.

Отсутствие стейджинга и обновление «на живую»

Критическая ошибка — позволить подрядчику обновлять ядро WordPress, тему или тяжелые плагины (типа WooCommerce или Elementor) сразу на рабочем домене. В 20% случаев обновление вызывает конфликт версий, что ведет к «белому экрану» (WSOD) и полной остановке продаж на период от 2 до 8 часов.

Профессиональный подход подразумевает наличие Staging-сервера (точной копии сайта). Сценарий: обновление ставится на стейджинг → проверка критических узлов (корзина, формы, API) → перенос на прод. Если подрядчик предлагает «просто нажать кнопку Обновить» и берет за это 5 000 – 10 000 рублей в месяц, вы платите за риск, а не за поддержку.

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

Слепое доверие «пакетным» тарифам поддержки

Многие компании выбирают тарифы вроде «Базовый» (10-15 тыс. руб./мес), где указано абстрактное «техническое сопровождение». В реальности такие пакеты часто включают только бэкапы и обновление плагинов, но исключают мониторинг доступности (Uptime) и оптимизацию скорости загрузки (LCP, CLS).

Кейс: клиент перешел на дешевый тариф, где бэкапы делались раз в неделю. При критическом сбое в четверг данные за 3 дня были потеряны безвозвратно, что стоило компании 120 заказов и около 400 000 рублей выручки. Профессиональное сопровождение подразумевает ежедневные бэкапы на внешнее хранилище (S3, Google Drive), а не на тот же сервер, где лежит сайт.

Вывод эксперта: Избегайте размытых формулировок. В договоре должны быть прописаны KPI для оценки эффективности компании по поддержке сайта на WordPress: метрики скорости, доступности и конверсии.

Передача всех доступов без системы контроля

Ошибка управления — передача главного пароля администратора и root-доступа к серверу без настройки логов действий. Когда через полгода вы решите сменить подрядчика, обнаружите, что созданы десятки скрытых пользователей с правами администратора или изменены DNS-записи, что делает перенос сайта к другому специалисту долгим и дорогим процессом (от 15 до 40 рабочих часов на аудит).

Правильная схема: создание отдельных учетных записей для каждого специалиста и использование менеджеров паролей (например, Bitwarden или LastPass). Это позволяет отозвать доступ за 10 секунд, не меняя пароли во всех сервисах разом.

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

Игнорирование технического долга и «заплаток»

Дешевые агентства часто решают проблемы «костылями»: вместо исправления ошибки в коде темы они ставят очередной плагин, который маскирует проблему. Это раздувает базу данных и замедляет ответ сервера (TTFB) с нормы в 200-400 мс до критических 1.2-2 секунд.

Пример: вместо оптимизации тяжелых изображений или настройки кэширования на стороне сервера (Redis/Memcached), подрядчик ставит три разных плагина для сжатия. Результат — конфликт скриптов и падение PageSpeed до 30-40 баллов. Исправление такого «наслоения» стоит в 3-4 раза дороже, чем правильная настройка с самого начала.

Вывод эксперта: Раз в квартал заказывайте независимый технический аудит. Если количество плагинов растет без расширения функционала сайта — ваш подрядчик плодит технический долг за ваш счет.

Отсутствие регламента реагирования на инциденты

Типичный промах — отсутствие SLA (Service Level Agreement). Когда сайт падает в пятницу вечером, ответ «мы посмотрим в понедельник» означает потерю прибыли за все выходные. В нише WordPress нормальное время реакции на критический сбой (сайт недоступен) — от 30 минут до 2 часов, на некритический (ошибка в верстке) — до 24 часов.

Сравнение: бюджетные фрилансеры работают в режиме «как освобожусь», профессиональные студии внедряют систему тикетов (Jira, YouTrack), где каждое задание имеет статус и дедлайн. Разница в стоимости может быть двукратной (15 000 против 30 000 руб./мес), но страховка от простоя окупает эту разницу за один час работы сайта.

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

Вывод

Делегирование поддержки WordPress — это не покупка «абонемента на правки», а страхование бизнес-процессов. Чтобы не потерять деньги, избегайте подрядчиков без стейджинга и четких SLA. Начинайте с глубокого аудита текущего состояния и фиксации KPI. Оптимальный выбор — агентство полного цикла, которое берет на себя ответственность за доступность 99.9% времени и чистоту кода, даже если это стоит на 30-50% дороже рыночного «минимума».