После обновления WordPress перестал работать сайт: что делать

Если после обновления сайт перестал работать, я советую сначала остановить дальнейшие изменения. Зафиксируйте ошибку и последние действия, проверьте, открываются ли сам сайт и админка, и выясните, есть ли подходящая резервная копия. Восстанавливать весь сайт на старую дату сразу не стоит: вместе с неисправностью можно потерять новые заказы и обращения.

Сначала нужно понять, что именно сломалось и какие данные важно сохранить. Ниже — порядок действий для владельца сайта, которому не обязательно разбираться в коде. Он поможет собрать вводные и выбрать следующий шаг без лишних экспериментов на рабочем проекте.

Что именно перестало работать

Фраза «сайт не работает» может описывать разные ситуации. Если не открывается ни одна страница, задача отличается от сломанной формы на работающем сайте. А недоступная админка ещё не означает, что посетители не могут читать страницы или оформлять заказы.

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

Запишите отдельно, что продолжает работать. Например: главная открывается, карточки товаров доступны, но переход к оформлению заказа заканчивается ошибкой. Такое описание полезнее, чем несколько снимков главной без пояснений.

Что можно проверить без изменения сайта

До отключения плагинов и восстановления копий можно собрать достаточно сведений. Я предлагаю короткий список:

• Скопируйте точный адрес проблемной страницы. Если ошибка появляется после нажатия кнопки, запишите и само действие.
• Откройте этот адрес в другом браузере или приватном окне. Это помогает сравнить условия, но не доказывает исправность всех функций сайта.
• Сохраните текст сообщения и снимок экрана без личных данных, ключей и приватных ссылок.
• Отметьте время, когда заметили проблему, и когда сайт в последний раз точно выполнял нужное действие.
• Соберите перечень последних обновлений: WordPress, тема, плагины, а также изменения настроек или версии PHP на хостинге, если о них известно.
• Проверьте сообщения хостинга и доступность его панели. Посмотрите, какие копии доступны и к какому времени они относятся, пока ничего не восстанавливая.

Если известно только, что «ночью что-то обновилось», так и укажите. Не нужно угадывать название плагина или повторять обновление ради проверки. Ошибка, замеченная после обновления, ещё не доказывает, что причина именно в нём: в то же время могли измениться другие условия.

Пока собираете сведения, остановите новые правки со своей стороны и предупредите людей, которые тоже редактируют сайт. Для магазина отдельно определите, можно ли принимать заказы в текущем состоянии. Проверять оплату реальной покупкой без согласованного сценария не нужно.

Письмо WordPress и режим восстановления

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

Режим восстановления помогает попасть в панель и увидеть сведения о проблемном компоненте. Он может приостановить этот компонент для вашей сессии, но не возвращает WordPress, тему или плагины к прежней версии автоматически. Доступная вам админка также не гарантирует, что сайт исправлен для всех посетителей.

Я использую такие сведения как часть диагностики, а не как подтверждение готового ремонта. Приватную ссылку восстановления не публикуйте в комментариях, открытой форме или общем чате. Порядок передачи необходимых доступов лучше согласовать отдельно.

Почему не стоит менять всё подряд

Если одновременно сменить тему, отключить несколько плагинов и очистить все настройки, станет труднее понять, какое действие повлияло на результат. Даже если главная откроется, часть функций может исчезнуть вместе с отключёнными компонентами.

Последовательное отключение компонентов — диагностическая процедура с последствиями. На магазине оно может затронуть оформление заказа, оплату, доставку и обмен данными. До такой проверки нужно знать, что обеспечивает компонент, как вернуть его в работу и какие действия посетителей окажутся под риском. При необходимости я переношу проверку на отдельную копию.

Сообщение о техническом обслуживании тоже не повод сразу удалять служебные файлы. Сначала требуется подтвердить, что обновление уже не выполняется. Только после этого имеет смысл проверять, не осталось ли зависшее состояние, связанное с файлом .maintenance. Если процесс ещё идёт или его состояние неизвестно, вмешательство лучше согласовать с поддержкой хостинга или специалистом.

Не стоит по универсальному совету удалять все плагины, менять базу данных, включать показ технических ошибок посетителям или снова и снова запускать обновление. Для разбора нужны сведения об ошибке; способ их получения должен учитывать доступы и защиту данных.

Когда помогает исправление, а когда нужен откат

Я выбираю способ восстановления после проверки причины, состояния данных и совместимости компонентов. Обычно обсуждаются три варианта.

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

Временное отключение проблемного компонента. Может помочь вернуть доступность, если сайт способен работать без этой функции. Нужно заранее обозначить, что временно перестанет работать и как сообщить об этом тем, кого это затрагивает. Такой обход не равен окончательному устранению причины.

Восстановление из подходящей копии. Имеет смысл, когда возврат известного рабочего состояния обоснован, копия пригодна и понятны последствия для свежих данных. Важны дата, состав и совместимость файлов с базой. Сам факт наличия архива ещё не подтверждает, что из него получится нужный результат.

Если рассматривается восстановление сайта из резервной копии, я сначала оцениваю архив и изменения после его создания. Иногда достаточно вернуть отдельный компонент; иногда потребуется более широкий откат. Возможность выборочного возврата определяется по конкретному сайту, а не обещается заранее.

Что будет с новыми заказами и обращениями

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

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

Нужно выяснить, где хранятся обращения, какие заказы появились после копии и успели ли они попасть во внешние системы. Не каждая форма сохраняет сообщение в базе сайта: иногда оно уходит только письмом или в CRM. Выгружать всё подряд и объединять базы наугад не стоит — сначала определяют нужные данные и способ проверки.

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

Как проверить, что работа восстановлена

Открытия главной страницы недостаточно. До исправления я фиксирую проверяемое действие, а после — повторяю его в согласованных условиях и проверяю ближайшие зависимости.

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

Работу формы оценивают по всему нужному пути: заполнение, обработка, сохранение и получение сообщения. Проверки писем, платежей и других внешних действий проводят отдельно, в безопасном тестовом режиме или по заранее согласованному сценарию. На тестовой копии должны быть отключены реальные письма, платежи, отправки в CRM и другие внешние действия — иначе диагностическая проверка может затронуть настоящих клиентов.

После временного обхода стоит записать, какая функция отключена и что предстоит исправить окончательно. Для периодической ошибки один удачный просмотр — только один результат проверки, а не доказательство, что она больше не появится.

Как снизить риск следующего сбоя

Навсегда отказаться от обновлений — плохой выход: сайт останется со старыми компонентами и известными проблемами. Полезнее сделать обновления управляемой работой.

До них нужны подходящие копии файлов и базы и понимание, как ими воспользоваться. Полезно проверить требования новой версии и совместимость важных плагинов, темы и серверного окружения. Для сложного сайта или существенного изменения может понадобиться отдельная среда, где можно проверить обновление без вмешательства в рабочие процессы.

Я заранее определяю порядок изменений и список действий для проверки после каждого значимого шага. Тогда проще заметить, на каком этапе возникла проблема, и выбрать ограниченный способ возврата. Время обновлений стоит согласовывать с теми, кто принимает заказы и обращения.

Отдельно проверьте хранение архивов: одна копия рядом с сайтом не защищает от всех причин потери данных. В статье про правило 3–2–1 для резервных копий сайта я объясняю, зачем нужны разные места хранения и проверка восстановления. Если обновления и проверки требуются регулярно, этот порядок можно включить в поддержку сайта на WordPress.

Когда обратиться за помощью

Помощь особенно нужна, если недоступны сайт и админка, сбой мешает заказам, неизвестно состояние копий или уже выполнено несколько изменений и непонятно, как вернуться назад. При неисправности сервера полезно сначала уточнить у хостинга статус площадки; при ошибке внутри сайта — передать специалисту собранные сведения.

Для первого сообщения достаточно адреса сайта, симптома, времени появления, перечня последних изменений и сведений о доступной копии. Если чего-то не знаете, это нормально. Пароли, ключи, выгрузки с данными клиентов и приватные ссылки восстановления через открытую форму присылать не нужно.

Если нужна помощь, я разберусь в ситуации, согласую объём исправления ошибок на сайте и проверю затронутые действия после работы.