Сайт перестал работать после обновления: что делать в первую очередь

Сайт лёг сразу после обновления CMS, плагина или темы — знакомая ситуация: вчера всё работало, сегодня белый экран, ошибка 500 или «поехавший» каталог. Прежде чем звонить в студию и заказывать срочное исправление ошибок на сайте, есть пять-семь шагов, которые владелец сайта или штатный менеджер может пройти сам за 15–20 минут — они либо решают проблему на месте, либо в разы ускоряют работу подрядчика, потому что вы приходите не с «сайт сломался», а с «после обновления плагина X ошибка 500, в логе такая-то строка».

Шаг 0: зафиксируйте масштаб проблемы

Прежде чем что-либо трогать, за одну минуту ответьте на три вопроса — они определяют, куда бежать в первую очередь.

• Сайт не открывается совсем (белый экран, ошибка 500/503) или работает частично (не грузится один блок, не отправляется форма, съехала вёрстка)?
• Проблема у всех посетителей или только у вас — проверьте с телефона на мобильном интернете, а не только со своего рабочего компьютера в офисе.
• Что именно обновлялось последним: CMS (WordPress, Битрикс, MODX), плагин/модуль, тема, версия PHP на хостинге, SSL-сертификат?

Если сайт открывается у вас, но не у клиентов — дело не в обновлении, а в кэше браузера или DNS, и откатывать ничего не нужно. Если ошибка у всех и совпадает по времени с последним обновлением — переходите к шагу 1.

Шаг 1: откатите последнее изменение

Самый быстрый способ вернуть сайт в рабочее состояние — не чинить, а откатить. Почти всегда ошибка после обновления — это конфликт новой версии с чем-то старым, а не фундаментальная проблема сайта.

• WordPress. Зайдите в админку (если она открывается) → «Плагины» и деактивируйте последний обновлённый или установленный плагин. Если админка не грузится — переименуйте его папку через FTP или файловый менеджер хостинга: wp-content/plugins/имя-плагина в имя-плагина-off. WordPress автоматически отключает плагин, если не находит его папку по прежнему имени.
• Тема. Тем же способом переименуйте папку темы в wp-content/themes — CMS откатится на стандартную тему, и вы увидите, была ли причина в шаблоне.
• 1С-Битрикс, MODX, OpenCart, Joomla. Если обновление проходило через встроенный менеджер — проверьте, доступна ли в нём точка восстановления. Если нет — понадобится резервная копия файлов и базы (см. следующий пункт).
• Есть бэкап — используйте его. Резервная копия, сделанная хостингом или плагином за 1–2 дня до сбоя, — самый надёжный путь: восстановление занимает 5–15 минут и возвращает сайт в заведомо рабочее состояние, пока вы разбираетесь с причиной без давления «сайт лежит прямо сейчас».

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

Шаг 2: посмотрите логи и консоль — не гадайте

«Сайт не работает» — это симптом, а не диагноз. Причину почти всегда видно в логах за 2–3 минуты, если знать, куда смотреть.

• Белый экран или ошибка 500. Откройте панель хостинга → раздел «Логи ошибок» (error log) или файл error_log в корне сайта. Последние строки обычно называют файл и номер строки, где упал скрипт, и это уже наводка для разработчика.
• Сайт открывается, но что-то не работает (форма, слайдер, кнопка, меню). Откройте страницу в браузере, нажмите F12 → вкладка Console. Красные строки с текстом ошибки JavaScript покажут, какой скрипт конфликтует — часто это старая версия jQuery или плагина, несовместимая с новым кодом темы.
• Ошибки базы данных ("Error establishing a database connection" и подобные) чаще всего означают, что при обновлении не пересохранились настройки подключения — файл конфигурации (wp-config.php, .env, bitrix/.settings.php) стоит проверить в первую очередь.
• Сфотографируйте или скопируйте текст ошибки. Даже если вы не понимаете, что он значит, — это главная информация для того, кто будет чинить сайт дальше. Не закрывайте вкладку с ошибкой, пока не сохранили текст.

Шаг 3: проверьте инфраструктуру, а не только код

Иногда «сайт сломался после обновления» — это совпадение по времени, а причина в другом месте. Быстрая проверка исключает ложный след.

1. Версия PHP на хостинге. В панели управления хостингом посмотрите текущую версию PHP. Хостинг-провайдеры периодически отключают старые версии автоматически — если это совпало с обновлением CMS, ошибка может быть именно в несовместимости PHP, а не в самом обновлении.
2. SSL-сертификат. Если браузер пишет «соединение не защищено» — проверьте срок действия сертификата в панели хостинга; истёкший SSL иногда путают с последствиями обновления сайта.
3. Домен и DNS. Если сайт не открывается ни у кого, но хостинг сообщает, что всё работает, — проверьте, не истёк ли домен и не менялись ли настройки DNS в последние сутки.
4. Место на диске и лимиты хостинга. Многие тарифы отключают сайт при превышении квоты после установки обновлений — панель хостинга обычно показывает это отдельным уведомлением.

Шаг 4: если ничего не помогло — соберите досье перед звонком

Если откат не устранил проблему или откатывать нечего (например, слетело обновление PHP на стороне хостинга), не тратьте время на хаотичные попытки — соберите информацию, с которой разработчик начнёт работу за минуты, а не часы.

• Точное время появления ошибки и что обновлялось непосредственно перед этим.
• Текст ошибки из error log хостинга и/или консоли браузера (скриншот или копия текста).
• Есть ли актуальный бэкап и когда он был сделан — от этого зависит, можно ли откатиться мгновенно или придётся чинить «на месте».
• Доступы к админке сайта и к хостингу — без них диагностика займёт лишний день на переписку с провайдером.
• Список, что уже пробовали сами (деактивация плагина, откат темы), чтобы подрядчик не повторял те же шаги.

С таким набором данных диагностика обычно занимает от 15 минут до часа, а не «сутки на разбирательство» — потому что не нужно тратить время на то, чтобы просто понять, что произошло.

Когда пора звонить в студию, а не разбираться самому

Разумно останавливаться и передавать проблему специалистам в трёх случаях: если через 15–20 минут откат и отключение плагинов не вернули сайт в рабочее состояние; если ошибка связана с базой данных или файлами конфигурации, где неверное действие может стереть данные; и если сайт критичен для приёма заявок или оплат прямо сейчас — каждый час простоя здесь стоит дороже, чем стоимость профессионального исправления. В этих случаях самостоятельные эксперименты с кодом или базой данных без резервной копии повышают риск, а не снижают его: неудачная правка файла ядра CMS иногда превращает решаемую проблему в необходимость восстанавливать сайт с нуля.

Практический вывод

Порядок действий при поломке сайта после обновления укладывается в одну последовательность: оценить масштаб → откатить последнее изменение (плагин, тему, обновление, из бэкапа) → проверить логи и консоль браузера → исключить инфраструктурные причины (PHP, SSL, домен, лимиты хостинга) → если не помогло, собрать досье с текстом ошибок, доступами и данными о бэкапе и передать разработчику. В большинстве случаев первые два шага возвращают сайт в рабочее состояние за 10–15 минут без привлечения подрядчика. Если нет — правильно подготовленная информация превращает вызов «специалиста по ремонту сайтов» из долгого разбирательства в понятную задачу с точным диагнозом на входе.