# WordPress не работает после обновления: что проверить > WordPress сломался после обновления? Что проверить, как сохранить новые заказы, выбрать способ восстановления и подготовить данные для специалиста. - Canonical: https://asgru.com/ru/wordpress-ne-rabotaet-posle-obnovleniya/ - Language: ru - Author: writer - Published: 2026-09-24T04:37:26+02:00 - Updated: 2026-09-24T15:45:12+02:00 Если WordPress перестал работать после обновления, сначала зафиксируйте ошибку и последнее изменение. Проверьте, затронут ли весь сайт или отдельная функция, и найдите резервную копию. Затем можно выбирать способ восстановления: устранить конфликт, вернуть совместимую версию компонента или восстановить согласованный комплект файлов и базы данных. Не запускайте новые обновления наугад. Несколько последовательных изменений затруднят поиск причины. Для магазина особенно важно сохранить заказы и платежи, которые появились после создания резервной копии. ## 1. Зафиксируйте, что произошло Составьте короткую хронологию. Формулировка «после обновления всё сломалось» полезна как отправная точка, но для диагностики нужны конкретные сведения: - Адрес страницы и действие, после которого возникает ошибка: открытие сайта, вход, отправка формы или оформление заказа. - Точный текст сообщения либо снимок экрана без персональных данных. Если виден код 500, 502 или 504, запишите его. - Время сбоя и часовой пояс. По ним специалист найдёт соответствующие записи в журнале сервера. - Что обновлялось: ядро WordPress, тема, конкретный плагин или версия PHP. Укажите старую и новую версии, если они известны. - Работает ли админка, повторяется ли проблема у посетителя без входа и на других страницах. Совпадение по времени ещё не доказывает причину. Например, тайм-аут может совпасть с обновлением, но быть связан с нагрузкой или неполадкой на стороне хостинга. ## 2. Выполните проверки, которые не меняют сайт - Откройте проблемную страницу в приватном окне браузера. Это поможет отделить сбой для всех посетителей от проблемы текущей сессии. - Проверьте главную страницу, одну внутреннюю страницу и вход в админку. Запишите, где именно воспроизводится ошибка. - Посмотрите уведомления хостинга об авариях и состояние последней резервной копии. Уточните её дату и состав: файлы, база данных или оба компонента. - Если админка доступна, посмотрите список недавно обновлённых компонентов и сообщения на экране обновлений. Не запускайте повторное обновление только ради проверки. Перед любыми исправлениями сохраните текущее состояние сайта отдельно от последней рабочей копии. Даже в сломанной версии могут находиться новые заявки, записи или заказы, которые понадобятся при восстановлении. ## 3. Определите направление диагностики по симптому ### Критическая ошибка или белая страница Разработчику нужны журнал ошибок PHP и сведения о последних изменениях. Одинаковый экран может возникнуть по разным причинам, поэтому отключение первого попавшегося плагина не подтверждает диагноз. Конфликт лучше воспроизвести на тестовой копии и проверять компоненты по одному. Если для диагностики включается отладка, сообщения не должны выводиться посетителям, а журнал не должен быть общедоступным. Настройку и последующее отключение отладки следует выполнять по [документации WordPress по отладке](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/). ### Сайт остался в режиме обслуживания Сообщение о временной недоступности может появиться во время обновления. Если оно не исчезает, нужно выяснить, завершился ли процесс и все ли файлы обновлены. В [справке WordPress по устранению неполадок](https://wordpress.org/documentation/article/faq-troubleshooting/) описан файл .maintenance, связанный с этим режимом. Его удаление снимает сообщение, но само по себе не исправляет прерванное обновление. Перед вмешательством специалист должен проверить состояние процесса и файлов. ### Съехала вёрстка или не работают кнопки Укажите конкретные элементы и страницы. Проверьте, одинаков ли результат в приватном окне и после входа в админку. Возможные направления проверки — стили, скрипты, изменения темы и кеш. Очистка кеша может помочь при устаревших файлах, но не устраняет ошибку в коде. Если на сайте есть CDN, его кеш проверяют отдельно. ### Не проходит оформление заказа или отправка формы Запишите шаг, на котором возникает сбой. Для магазина нужно проверить, создался ли заказ и не прошёл ли платёж, прежде чем повторять операцию. Не отправляйте специалисту данные банковской карты. Для диагностики обычно достаточно времени, номера заказа и обезличенного описания ошибки. ## 4. Выберите способ восстановления с учётом данных Если причина подтверждена в одном компоненте, точечное исправление может сохранить актуальные данные сайта. Возврат предыдущей версии плагина или темы допустим только после проверки совместимости с текущей базой данных и остальными компонентами. Старую версию с известной уязвимостью нельзя оставлять постоянным решением. Полное восстановление из резервной копии имеет смысл, когда выбранная копия действительно рабочая и понятны последствия отката. Например, копия магазина сделана в 09:00, а сбой произошёл в 14:00. Возврат базы к состоянию на 09:00 может убрать заказы за эти пять часов. Сначала нужно сохранить новые данные и согласовать, как они будут перенесены. Файлы и база данных должны соответствовать друг другу. Наличие архива ещё не означает, что восстановление пройдёт успешно: проверка копии на тестовом окружении снижает неопределённость. Общие требования к резервному копированию перед обновлением приведены в [официальной инструкции по обновлению WordPress](https://wordpress.org/documentation/article/updating-wordpress/). ## 5. Проверьте результат после исправления Открывшаяся главная страница — только первый признак восстановления. Пройдите те действия, ради которых люди пользуются сайтом: - Проверьте затронутую страницу и повторите действие, которое вызывало ошибку. - Откройте сайт на телефоне и компьютере, в том числе без входа в админку. - Проверьте формы и получение уведомлений. Тестовую заявку явно пометьте как тест. - Для магазина проверьте корзину, доставку, оплату и изменение статуса заказа в согласованном тестовом режиме. - Проверьте основные языковые версии, изображения и переходы между важными страницами. - Попросите специалиста проверить журнал на повторение ошибки и записать, что именно исправлено. ## Что передать специалисту Подготовьте адрес сайта, хронологию сбоя, текст ошибки, список обновлений и сведения о резервных копиях. Отдельно укажите, принимает ли сайт заказы или заявки сейчас. Пароли, полный дамп базы и необработанные журналы не стоит прикладывать к первому обращению: способ передачи доступа лучше согласовать отдельно. Нужна помощь с восстановлением? [Опишите сбой и пришлите адрес сайта](https://asgru.com/ru/tehnicheskaya-podderzhka-sajta/), чтобы определить следующие шаги диагностики. ## Как подготовиться к следующему обновлению Сохраните рабочую резервную копию, проверьте обновление на тестовом окружении и заранее составьте список функций для проверки. Выбирайте время, когда можно наблюдать за сайтом после изменений. Порядок планового обновления разобран отдельно в материале [«Обновление сайта на WordPress: пошаговый мануал»](https://asgru.com/ru/obnovlenie-sajta-na-wordpress-poshagovyj-manual/). ## Частые вопросы ### Нужно ли сразу переустанавливать WordPress? Сначала нужно установить причину. Переустановка ядра не исправит автоматически конфликт темы, плагина или окружения сервера. Выбор действия должен опираться на ошибку и результаты проверки. ### Можно ли просто восстановить вчерашнюю копию? Это зависит от того, какие данные изменились с момента её создания. Для сайта-визитки и магазина с новыми заказами последствия будут разными. До отката сохраните текущее состояние и определите, какие новые данные нельзя потерять. ### Что делать, если админка тоже недоступна? Сохраните текст ошибки и обратитесь к хостингу или разработчику. Проверку журналов и файлов можно выполнять через панель хостинга или отдельный технический доступ. Не редактируйте базу данных по случайной инструкции без понимания последствий и возможности восстановления.