Обновили WordPress, плагин или тему — и сайт внезапно лег? Белый экран, кривой дизайн, не работает корзина, админка не пускает. Да, ситуация мерзкая. Но паниковать не надо — в большинстве случаев это чинится, причем без полного переделывания сайта.
Самая частая ошибка тут не само обновление, а резкие движения после него. Люди начинают тыкать все подряд, удалять плагины, править файлы на хостинге вслепую. В итоге проблема становится только хуже. Так что давайте спокойно — по шагам.
Сначала — не ломайте еще сильнее
Если сайт уже ведет себя странно, ваша первая задача — ничего не добить окончательно. Особенно если это интернет-магазин и там идут заказы. Один неудачный клик — и можно потерять чекаут, данные клиента или вообще доступ в админку.
Вот что стоит сделать сразу:
- зайти на сайт в режиме инкогнито и проверить, что именно сломалось
- попросить коллегу или знакомого открыть сайт с другого устройства
- не обновлять остальные плагины «заодно»
- не удалять тему или плагин если не понимаете последствия
- сделать бэкап прямо сейчас, даже если сайт уже поломан
И да — если у вас магазин, временно проверьте самые важные точки: карточку товара, корзину, чекаут, письмо о заказе. Иногда главная выглядит норм, а деньги вы уже теряете.
Что обычно ломается после обновления
Честно говоря, виноват не всегда сам WordPress. Чаще всего проблема в конфликте версий. Один плагин обновился, другой — нет. Тема старая. PHP на хостинге древний. Или сайт когда-то собрали на кастомных костылях, и теперь любой апдейт цепляет этот самописный кусок.
Самые частые симптомы такие:
- белый экран смерти
- ошибка 500
- разъехался дизайн
- не открывается админка
- не работают формы, фильтры, корзина
- сайт стал очень медленным
Знакомо? Ну вот. Обычно это одна из трех вещей: конфликт плагинов, конфликт темы, или хостинг/версия PHP не тянут новое обновление.
План действий на первые 30 минут
Смотрите, тут не нужен героизм. Нужна нормальная диагностика. Если есть доступ в админку — отлично. Если нет, работаем через хостинг и файловый менеджер.
- Проверьте, есть ли свежий бэкап. Если он есть и сайту критично быстро вернуться в работу — иногда проще откатить сайт за 10-20 минут.
- Откройте журнал ошибок. На хостинге часто есть error log. Там может быть видно, какой плагин упал.
- Отключите последний обновленный плагин. Если нет админки, можно переименовать папку плагина через файловый менеджер.
- Переключитесь на стандартную тему. Например, временно на Twenty Twenty-Four — чисто для проверки.
- Проверьте версию PHP. Некоторые обновления просто не дружат со старой версией.
Если после отключения одного плагина все ожило — уже хорошо. Но не спешите радоваться. Надо понять, это сам плагин битый или он конфликтует с чем-то еще.
Когда лучше откатить сайт, а когда чинить на месте
Тут все зависит от ситуации. Если у вас сайт-визитка без ежедневных заявок, откат на вчерашний бэкап — нормальный вариант. Потеряете минимум. Если это интернет-магазин и за день уже пришли заказы, откат может снести новые покупки, письма и изменения по товарам.
Я бы ориентировался так:
- Откат делать стоит — если есть свежий бэкап, мало новых данных и сайт надо срочно вернуть
- Чинить на месте лучше — если есть заказы, бронирования, новые заявки или правки контента после последнего бэкапа
Кстати, если у вас бэкапы хранятся «где-то вроде есть», это не система. Это надежда. А надежда, как правило, плохо работает в 9 утра когда сайт уже лежит. На тему резервных копий советую почитать эту статью про бэкапы — там без занудства, по делу.
Если сломался интернет-магазин
С магазином все жестче. Тут проблема не только в том, что «некрасиво отображается». Тут у вас может не проходить оплата, не считаться доставка, не уходить письма клиенту. А это уже прямые потери денег.
Вот что проверяйте в первую очередь:
- добавляется ли товар в корзину
- обновляется ли количество товара
- работает ли купон или скидка
- открывается ли страница оформления заказа
- проходит ли тестовая оплата
- приходит ли письмо о заказе
Если что-то из этого сломалось — не тяните. Один день с битым чекаутом легко съедает больше денег, чем месяц нормальной техподдержки. Если магазин у вас на WooCommerce и надо быстро привести его в чувство или нормально собрать с нуля, посмотрите разработку интернет-магазина — особенно если сайт уже давно держится на честном слове и старых плагинах.
Почему это вообще происходит
На самом деле обновление — это просто момент, когда накопленные проблемы вылезают наружу. Само по себе оно не «злое». Просто сайт годами не обслуживали, плагины ставили без системы, тему купили на маркетплейсе пять лет назад, хостинг дешевый, PHP старый — и вот в какой-то момент все это сыпется.
Типичный сценарий малого бизнеса выглядит так:
- сайт сделали быстро и недорого
- после запуска его почти не трогали
- добавляли плагины по принципу «о, прикольная фишка»
- апдейты копились месяцами
- потом кто-то нажал «обновить все»
Ну и все. Бум. Особенно весело, если там 25 плагинов, из которых половина уже давно не поддерживается.
Как чинить проблему без угадайки
Если хотите нормальный результат, проблему лучше разбирать в тестовой копии сайта. То есть не на живом сайте, а на staging-версии. Там можно спокойно включать плагины по одному, менять версию PHP, проверять тему и смотреть логи без риска уронить продажи.
Обычно на такую диагностику уходит:
- 30-60 минут — если проблема в одном плагине
- 1-2 часа — если конфликт между темой и плагином
- полдня и больше — если сайт старый, кастомный и никто не помнит как он собран
Если вы вообще не хотите этим заниматься сами — и это, кстати, нормально — есть поддержка и управление сайтами. Туда как раз входят бэкапы, обновления, фиксы багов и проверки после апдейтов. Для малого бизнеса это часто дешевле, чем каждый раз тушить пожар отдельно.
Как не попасть в ту же историю через месяц
Вот тут самое важное. Проблема не в одном неудачном обновлении. Проблема в том, что у сайта нет рутины обслуживания. А без нее такие истории будут повторяться.
Минимальный рабочий набор такой:
- делать автоматические бэкапы каждый день или хотя бы перед каждым апдейтом
- обновлять сайт регулярно, а не раз в полгода
- перед крупными обновлениями тестировать все на staging
- держать список лишних плагинов и удалять мусор
- проверять после апдейта ключевые страницы и формы
И да, если сайт старый, иногда выгоднее не латать его бесконечно, а пересобрать нормально. Особенно если он тормозит, выглядит устало и маркетинг на нем уже еле дышит. Кстати, если думаете сколько вообще должен занимать такой проект, вот полезный разбор: сколько на самом деле занимает разработка сайта.
Когда уже пора звать специалиста
Есть ситуации где лучше не ковыряться самому, чо уж. Например, если сайт приносит заявки каждый день, если на нем магазин, если вы не понимаете логи ошибок, если после «быстрой правки» стало только хуже. Или если сайт уже взламывали раньше — после неудачного обновления иногда всплывают и проблемы безопасности.
Хороший ориентир простой:
- если простой сайта стоит вам денег — не тяните
- если нет свежего бэкапа — не тяните
- если сломалась оплата или формы — не тяните
- если вы не уверены что именно обновилось — тоже не тяните
Короче, обновление сломало сайт — это неприятно, но не конец света. Главное — не дергаться, быстро понять масштаб проблемы и либо откатить, либо нормально диагностировать конфликт. А дальше уже выстроить обслуживание так, чтобы следующий апдейт не превращался в мини-инфарктт.
Если хотите, можно пойти простым путем: сначала вернуть сайт в рабочее состояние, потом настроить бэкапы, безопасные обновления и понятную поддержку. Для малого бизнеса это самый здравый сценарий — без лишней драмы и без сюрпризов посреди недели.