Год назад ко мне пришёл сайт на поддержку. WordPress, WooCommerce, трафик небольшой — около 200 посетителей в день. Предыдущий разработчик «всё настроил и передал». Через месяц после передачи сайт лёг. Причина: 47 активных плагинов, из которых 12 не обновлялись больше года, три конфликтовали друг с другом, а резервная копия оказалась битой — хостинг честно делал бэкапы, но никто ни разу не проверил, можно ли из них восстановиться.
Ситуация не уникальная. За несколько лет работы с сайтами на поддержке я накопил коллекцию повторяющихся ошибок, которые встречаются с пугающей регулярностью. Вот пять антипаттернов, которые съедают бюджет, нервы и репутацию — причём заказчик часто даже не подозревает, что живёт на пороховой бочке.
1. «Починим, когда сломается»
Самый частый и самый дорогой антипаттерн. Логика простая: зачем платить за поддержку каждый месяц, если сайт работает? Всё меняется в момент, когда сайт падает в пятницу вечером. Срочный вызов разработчика стоит в 2-3 раза дороже плановых работ. А если сайт — единственный канал продаж, каждый час простоя обходится в реальные деньги.
Плановая поддержка — это не «платить за воздух». Это регулярные обновления ядра и плагинов, мониторинг аптайма, проверка форм и интеграций с CRM. Раз в месяц зайти в админку на 15 минут и убедиться, что контактная форма отправляет заявки — дешевле, чем через три месяца обнаружить, что клиенты уходят к конкурентам, потому что заявки просто не доходят.
Конкретный пример: интернет-магазин на WooCommerce, форма заказа перестала отправлять письма после обновления почтового плагина. Обнаружили через две недели. Потеряли около 15 заказов. Стоимость регулярной проверки: 2000 рублей в месяц. Стоимость потерянных заказов и экстренного ремонта: раз в 10 больше.
Отдельная боль — обновления ядра WordPress, которые ломают кастомные решения в теме. Разработчик пять лет назад написал функцию для корзины через хук, который в новой версии ядра поменял сигнатуру. Если сайт на поддержке — проблема ловится на стейджинге до релиза. Если «починим когда сломается» — ловится в продакшене, в понедельник утром, когда клиенты не могут оформить заказ.
2. «Плагины решают всё»
Нужен слайдер — ставим плагин. Галерея — ещё один. Форма обратной связи, попап, SEO, кеширование, редиректы — под каждую задачу свой плагин. В итоге админка превращается в зоопарк из 40-50 плагинов, где треть дублируют функциональность друг друга, а ещё треть не обновлялись с позапрошлого года.
Каждый плагин — это дополнительный код, который выполняется при каждом запросе. Добавляет запросы к базе данных, подгружает свои стили и скрипты, регистрирует хуки. На сайте с 50 плагинами WordPress может делать 200-300 запросов к базе на одной странице. Без кеширования такая страница грузится 3-5 секунд.
Разумный подход: перед установкой плагина спросить себя — можно ли это сделать без него? Чекбокс «я согласен с условиями» не требует отдельного плагина, это пять строк кода в functions.php. Редирект со старого URL на новый — одна строчка в .htaccess. Я не против плагинов как класса. Я против идеи, что любая задача требует нового плагина, даже если решение занимает десять минут руками.
3. «Бэкапы делаются, значит всё в порядке»
Хостинг показывает зелёную галочку «резервное копирование активно». Клиент спокоен. Разработчик спокоен. А потом оказывается, что бэкап делается раз в неделю, хранится на том же сервере, что и сайт, и ни разу не проверялся на восстановимость с момента запуска.
Настоящая проверка бэкапа — это не наличие файла с датой. Это восстановление сайта из этого бэкапа на тестовом окружении и проверка, что всё работает: открывается главная, работают формы, не сломана вёрстка, целы товары и заказы. Без этого бэкап — просто файл, который, возможно, бесполезен.
У меня было два случая, когда бэкап «был», но при восстановлении оказывалось, что база данных повреждена, или не хватает файлов из wp-content/uploads, или версия PHP на сервере поменялась и сайт падает с fatal error. Оба раза проблема обнаружилась не во время плановой проверки, а в момент реальной аварии. С тех пор я включаю тестовое восстановление в регламент минимум раз в квартал.
4. «Я тут сам немного поправил»
Клиент заходит в админку, видит поле «Дополнительные стили CSS» и решает подправить цвет кнопки. Или меняет текст на странице прямо в визуальном редакторе, случайно удаляя шорткод, который отвечал за вывод формы. Или устанавливает «какой-то плагин для SEO, коллега посоветовал» — и ломает структуру заголовков на всём сайте.
Результат: разработчик тратит время не на работу по задачам, а на разбор того, что и где поменялось без его ведома. В одном проекте клиент за месяц самостоятельных правок умудрился сломать мобильную вёрстку, удалить интеграцию с CRM и добавить два конфликтующих плагина кеширования. Разбор последствий занял три полных рабочих дня.
Решение не в том, чтобы закрыть клиенту доступ к админке. Решение — в разделении зон ответственности. У клиента есть доступ к контенту: страницы, товары, записи блога. Технические настройки, плагины, темы — только у разработчика. И короткая инструкция: «Если хотите что-то поменять в функциональности — сначала напишите, обсудим». Это не ограничение свободы, это страховка от незапланированных расходов.
5. «Обновим как-нибудь потом»
WordPress выпускает мажорное обновление. Плагины тоже обновляются. Но владелец сайта рассуждает: «Сайт работает, зачем трогать?» — и откладывает обновления на месяцы, иногда на год. За это время накапливается от 5 до 20 непропущенных версий плагинов и ядра.
Проблема не только в безопасности, хотя уязвимости в старых версиях — главный риск. Проблема в том, что когда обновление всё-таки случается (обычно после взлома или поломки), разработчик вынужден прыгать через 5-10 версий сразу. Совместимость между версиями никто не тестировал, конфликты неизбежны, а откатиться некуда — бэкап трёхмесячной давности потеряет весь новый контент.
Я видел сайт, который не обновляли полтора года. WordPress 5.8, двадцать плагинов с версиями годичной давности. После вынужденного обновления до 6.4 отвалилась тема, сломалась форма заказа и перестал работать импорт товаров из 1С. Восстановление заняло неделю. Регулярные обновления раз в месяц заняли бы суммарно около 4 часов за тот же период.
Что со всем этим делать
Все пять антипаттернов объединяет одно: они кажутся безобидными по отдельности. Один лишний плагин, один пропущенный месяц обновлений, одно «я сам поправлю» — ничего страшного. Но вместе они накапливаются, как снежный ком, и в какой-то момент сайт перестаёт быть управляемым.
Мой подход: регламент поддержки, который покрывает всё перечисленное. Минимум плагинов, регулярные обновления с проверкой на стейджинге, тестовое восстановление из бэкапа раз в квартал, мониторинг форм и интеграций, и чёткое разделение — что может делать клиент, а что только разработчик. Это не про паранойю. Это про то, чтобы не просыпаться в субботу утром от звонка «сайт не работает».
Какие антипаттерны встречаются в вашей практике чаще всего? Делитесь в комментариях — интересно, совпадают ли наши списки.
