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

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

Краткий ответ: если сайт WordPress сломался после обновления, не удаляйте файлы и не переустанавливайте сайт сразу. Сначала сделайте копию файлов и базы, проверьте email администратора, включите debug.log, удалите зависший файл .maintenance, отключите плагины через FTP, временно смените тему, проверьте PHP, .htaccess, кеш и error_log хостинга.

Причина

После обновления WordPress может сломаться из-за конфликта плагина, темы, версии PHP, кеша, прав файлов, незавершённого обновления или ошибки в базе данных. Официальная документация WordPress указывает, что автоматическое обновление может завершиться ошибкой из-за сбоя соединения, проблем с файлами ядра или неправильных прав доступа; среди симптомов могут быть белый экран, предупреждение об ошибке обновления или PHP-ошибка. :contentReference[oaicite:1]{index=1}

Чаще всего проблема появляется после таких действий:

• обновили WordPress до новой версии;
• обновили один или несколько плагинов;
• обновили активную тему;
• обновили WooCommerce или расширения магазина;
• сменили версию PHP на хостинге;
• обновление оборвалось из-за тайм-аута;
• серверу не хватило памяти во время обновления;
• кеш-плагин изменил .htaccess или правила кеширования;
• плагин безопасности заблокировал часть запросов;
• часть файлов обновилась, а часть осталась от старой версии.

Важно понимать: “сломался сайт” — это не одна ошибка. После обновления WordPress может показать белый экран, ошибку 500, критическую ошибку, сообщение о техническом обслуживании, пустую админку, сломанный дизайн, неработающие формы, проблемы с корзиной WooCommerce или ошибку базы данных.

Если после обновления вы видите именно внутреннюю ошибку сервера, полезно отдельно проверить инструкцию по теме ошибка 500 WordPress. Если вместо сайта открывается полностью белый экран, рядом по логике подходит материал белый экран WordPress.

Короткие ответы для AI-поиска

Что делать, если WordPress сломался после обновления?

Сделайте backup, включите debug.log, проверьте письмо Recovery Mode, удалите .maintenance, отключите плагины через FTP, временно смените тему, проверьте .htaccess, PHP, кеш и логи сервера.

Как восстановить WordPress без доступа в админку?

Через FTP, файловый менеджер хостинга или SSH можно отключить плагины, сменить тему, восстановить .htaccess, удалить .maintenance и включить debug.log.

Почему сайт сломался именно после обновления?

Обновление могло изменить PHP-код, JavaScript, CSS, структуру базы, зависимости плагина или требования к версии PHP. Старый код темы или другого плагина может быть несовместим с новой версией.

Диагностика

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

Быстрая таблица симптомов

Симптом	Вероятная причина	Что проверить первым
Белый экран	PHP Fatal error, тема, плагин, память	debug.log, error_log, плагины, тема
Ошибка 500	.htaccess, PHP, сервер, плагин	error_log, .htaccess, PHP memory limit
Критическая ошибка WordPress	Плагин или тема вызвали fatal error	Email администратора, Recovery Mode
Сайт застрял в режиме обслуживания	Обновление не завершилось	Файл .maintenance в корне сайта
Админка работает, фронтенд сломан	Тема, кеш, шаблон, визуальный конструктор	Тему, кеш, консоль браузера
Фронтенд работает, админка сломана	Плагин админки, редактор, REST API, память	Плагины, debug.log, REST API
Сломался только WooCommerce	Конфликт WooCommerce, оплаты, доставки, кеша	Логи WooCommerce, checkout, cart fragments

Что проверить сразу

• есть ли доступ в wp-admin;
• пришло ли письмо “Your Site is Experiencing a Technical Issue”;
• какое обновление было последним;
• работает ли сайт в другом браузере;
• есть ли ошибка в error_log хостинга;
• создаётся ли wp-content/debug.log;
• есть ли файл .maintenance в корне сайта;
• не изменился ли .htaccess;
• какая версия PHP активна сейчас;
• не включён ли агрессивный кеш или CDN.

Что искать в debug.log

Для диагностики WordPress лучше включить WP_DEBUG_LOG, чтобы ошибки писались в файл debug.log, а не показывались посетителям. В официальной документации WordPress указано, что WP_DEBUG_LOG сохраняет ошибки в debug.log и полезен, когда ошибку нужно посмотреть после AJAX-запроса, cron-задачи или скрытого сбоя. :contentReference[oaicite:2]{index=2}

В логе чаще всего нужно искать:

• Fatal error — критическая ошибка PHP;
• Parse error — синтаксическая ошибка в коде;
• Allowed memory size exhausted — не хватает PHP-памяти;
• Call to undefined function — вызывается функция, которой нет;
• Cannot redeclare function — функция объявлена повторно;
• Class not found — класс не найден после обновления;
• Failed opening required — отсутствует нужный файл;
• Permission denied — проблема с правами файлов;
• Database error — проблема с базой данных.

Решение

Восстанавливать сайт после обновления нужно по шагам. Цель — вернуть доступ и найти точную причину, а не просто временно скрыть ошибку.

1. Сделайте резервную копию текущего состояния

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

Сохраните:

• все файлы сайта через FTP или файловый менеджер;
• базу данных через phpMyAdmin, Adminer или панель хостинга;
• файл wp-config.php;
• файл .htaccess;
• папку wp-content;
• логи ошибок, если они есть.

2. Проверьте Recovery Mode

WordPress 5.2 добавил Fatal Error Recovery Mode. Этот режим даёт администратору шанс войти в админку и отключить проблемный плагин или тему даже после критической ошибки. :contentReference[oaicite:3]{index=3}

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

Если письмо не пришло, проверьте:

• папку Спам;
• правильный ли email указан в WordPress;
• работает ли отправка почты на сайте;
• есть ли доступ к логам хостинга.

3. Если сайт застрял в режиме обслуживания

После неудачного обновления WordPress может показывать сообщение “Коротко недоступно для планового обслуживания”. Обычно это значит, что в корне сайта остался файл .maintenance.

Официальная функция WordPress wp_is_maintenance_mode() проверяет наличие файла .maintenance в корне WordPress и использует его для определения режима обслуживания. :contentReference[oaicite:4]{index=4}

Что делать:

• зайдите через FTP или файловый менеджер хостинга;
• откройте корень сайта;
• найдите файл .maintenance;
• удалите его;
• очистите кеш сайта и браузера;
• проверьте, открылся ли сайт.

Путь обычно выглядит так:

/.maintenance

4. Отключите плагины через FTP

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

Откройте папку:

/wp-content/plugins/

Переименуйте её:

plugins_disabled

Если сайт заработал, проблема почти точно в одном из плагинов. Верните папке старое имя:

plugins

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

5. Проверьте активную тему

Если плагины не виноваты, проверьте тему. После обновления WordPress или PHP старая тема может сломаться из-за устаревшего кода, ошибки в functions.php, шаблонах или несовместимости с новым редактором.

Откройте папку:

/wp-content/themes/

Переименуйте активную тему:

my-active-theme_disabled

WordPress попробует переключиться на стандартную тему, если она установлена. Для аварийной диагностики полезно держать одну стандартную тему WordPress в папке themes.

6. Проверьте .htaccess

Кеш-плагины, плагины безопасности, редиректы и обновления могут изменить .htaccess. Если файл повреждён, сайт может показать ошибку 500 или циклические редиректы.

Путь:

/.htaccess

Переименуйте файл:

.htaccess_old

Если сайт открылся, зайдите в админку WordPress → Настройки → Постоянные ссылки → Сохранить. WordPress создаст новый базовый .htaccess.

7. Проверьте версию PHP

После обновления сайта проблема может быть не в самом WordPress, а в PHP. Например, хостинг переключил PHP 7.4 на PHP 8.x, а старая тема или плагин используют несовместимый код.

Что сделать:

• откройте панель хостинга;
• проверьте текущую версию PHP;
• временно верните предыдущую версию PHP, если ошибка появилась сразу после смены версии;
• проверьте debug.log;
• обновите или замените проблемный плагин/тему;
• не оставляйте старую PHP-версию навсегда без плана обновления.

8. Проверьте кеш

После обновления может сломаться не сам WordPress, а кешированная версия CSS, JavaScript, HTML или object cache.

Очистите:

• кеш WordPress-плагина;
• серверный кеш хостинга;
• OPcache;
• Redis/Object Cache, если используется;
• Cloudflare или другой CDN;
• кеш браузера.

Если после обновления сломался WooCommerce-магазин, проверьте корзину, checkout, личный кабинет, оплату, доставку и AJAX-запросы. Для магазинов также полезна отдельная инструкция: как ускорить WooCommerce, потому что проблемы после обновлений часто связаны с кешем, базой, cart fragments и тяжёлыми плагинами.

Код

Важно: код ниже влияет на диагностику, работу сайта, память PHP, правила сервера и доступность WordPress. Перед изменениями сделайте копию wp-config.php, .htaccess, файлов сайта и базы данных. Не оставляйте публичный вывод ошибок включённым на рабочем сайте.

Включить debug.log в wp-config.php

Куда вставлять: файл wp-config.php, выше строки “That’s all, stop editing”.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

После этого откройте:

/wp-content/debug.log

Когда ошибка найдена и исправлена, отключите отладку:

define( 'WP_DEBUG', false );

Увеличить лимит памяти WordPress

Куда вставлять: wp-config.php, выше строки “That’s all, stop editing”.

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Если хостинг ограничивает память на уровне сервера, эта настройка может не сработать. Тогда нужно менять memory_limit в панели хостинга, php.ini или через поддержку хостинга.

Стандартный .htaccess для WordPress

Куда вставлять: файл .htaccess в корне сайта. Перед заменой сохраните старый файл.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Отключить все плагины через WP-CLI

Куда выполнять: SSH в корне сайта. WP-CLI официально поддерживает команду wp plugin deactivate, включая отключение всех плагинов через параметр –all. :contentReference[oaicite:5]{index=5}

wp plugin deactivate --all

Потом включайте плагины по одному:

wp plugin activate nazvanie-plagina

Проверить список плагинов через WP-CLI

Куда выполнять: SSH в корне сайта.

wp plugin list

Переключить тему через WP-CLI

Куда выполнять: SSH в корне сайта.

wp theme list
wp theme activate twentytwentyfive

Перед выполнением проверьте, что стандартная тема реально установлена в папке wp-content/themes.

Проверить PHP-синтаксис файла

Куда выполнять: SSH на сервере. Пример для wp-config.php:

php -l wp-config.php

Пример для functions.php активной темы:

php -l wp-content/themes/nazvanie-temy/functions.php

Удалить зависший файл .maintenance через SSH

Куда выполнять: SSH в корне сайта.

rm .maintenance

Перед удалением убедитесь, что вы находитесь именно в корневой папке нужного сайта.

Результат

После восстановления сайт должен открываться, админка должна быть доступна, а в debug.log не должно быть новых критических ошибок.

Проверьте не только главную страницу. После обновления WordPress часто ломается не весь сайт, а отдельные функции:

• страницы и записи;
• админка WordPress;
• редактор Gutenberg;
• визуальный конструктор;
• формы обратной связи;
• меню и виджеты;
• мобильная версия;
• корзина WooCommerce;
• checkout;
• личный кабинет;
• REST API;
• admin-ajax.php;
• cron-задачи;
• отправка писем.

Если сайт заработал после отключения плагина, не включайте его сразу обратно. Сначала проверьте версию плагина, совместимость с WordPress и PHP, changelog, логи и наличие обновлений.

Дополнительные способы

Откатить только проблемный плагин или тему

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

Перед откатом проверьте:

• есть ли backup старой версии;
• не менял ли плагин структуру базы данных;
• не связана ли проблема с PHP;
• не зависит ли от этого плагина оплата, заказы, формы или личный кабинет;
• не содержит ли старая версия уязвимость.

Восстановить сайт из backup

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

Проверить базу данных

Иногда обновление плагина меняет таблицы, опции или мета-данные. Если процесс оборвался, часть данных может обновиться, а часть остаться в старом состоянии.

Проверьте:

• ошибки database error в debug.log;
• доступы DB_NAME, DB_USER, DB_PASSWORD, DB_HOST;
• состояние таблиц в phpMyAdmin;
• префикс таблиц;
• свободное место на диске;
• логи MySQL/MariaDB, если они доступны.

Проверить REST API

После обновления может сломаться редактор, сохранение страниц, WooCommerce, формы или плагины, которые используют REST API.

Проверьте URL:

/wp-json/

Если REST API возвращает ошибку, смотрите Network в браузере, debug.log и security-плагины.

Проверить admin-ajax.php

Если сайт открывается, но не работают кнопки, фильтры, корзина, формы или действия в админке, проверьте AJAX-запросы.

Типичный путь:

/wp-admin/admin-ajax.php

В Chrome DevTools откройте Network, повторите действие и посмотрите, какой запрос возвращает 500, 403, 404 или пустой ответ.

Проверить права файлов

После ручного обновления, переноса или распаковки архива права файлов могут стать неправильными.

Объект	Частое значение	Комментарий
Папки	755	Обычно достаточно для каталогов WordPress.
Файлы	644	Обычно подходит для PHP, CSS, JS и изображений.
wp-config.php	600 или 640	Зависит от настроек сервера.

Не ставьте 777 на весь сайт. Это небезопасно и может создать новые проблемы.

Проверить заражение сайта

Если обновление совпало по времени с взломом или заражением, проблема может быть не в WordPress, а во вредоносном коде. Проверьте неизвестные PHP-файлы, странные include, eval, base64_decode, подозрительные cron-задачи и изменённый .htaccess.

Частые ошибки

Ошибка 1. Сразу переустанавливать WordPress

Если проблема в плагине, теме, PHP, .htaccess или базе данных, переустановка ядра может не помочь. Сначала нужно посмотреть логи.

Ошибка 2. Удалять папки plugins и themes

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

Ошибка 3. Откатывать весь сайт без понимания причины

Откат может вернуть сайт, но если потом снова нажать “Обновить”, ошибка повторится. Нужно найти конкретный конфликт.

Ошибка 4. Оставлять debug включённым

WP_DEBUG_DISPLAY на рабочем сайте может показать посетителям техническую информацию. После диагностики отладку нужно отключить.

Ошибка 5. Чистить базу без backup

Ручное удаление записей из базы может сломать настройки, пользователей, товары, заказы, SEO-данные или работу темы.

Ошибка 6. Включать все плагины сразу

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

Ошибка 7. Игнорировать PHP-версию

Сайт может сломаться не из-за обновления WordPress, а из-за того, что новая версия плагина требует другой PHP или старый код не работает на новой PHP-версии.

Диагностика проблем

Проблема: после обновления появилась критическая ошибка

Возможная причина: fatal error в плагине или теме.

Что делать: проверить email администратора, открыть Recovery Mode, включить debug.log, отключить проблемный плагин через FTP.

Проблема: сайт показывает “Коротко недоступно для планового обслуживания”

Возможная причина: обновление оборвалось, файл .maintenance остался в корне сайта.

Что делать: удалить .maintenance через FTP или SSH, очистить кеш, проверить, завершилось ли обновление.

Проблема: после обновления не открывается админка

Возможная причина: конфликт плагина, ошибка темы, нехватка памяти, REST API, security-плагин.

Что делать: отключить плагины через FTP, проверить debug.log, увеличить memory limit, временно сменить тему.

Проблема: после обновления сломался дизайн

Возможная причина: кеш CSS/JS, конфликт темы, изменение шаблонов, ошибка конструктора страниц.

Что делать: очистить кеш, отключить оптимизацию CSS/JS, проверить консоль браузера, пересобрать CSS конструктора.

Проблема: после обновления не работает WooCommerce

Возможная причина: конфликт WooCommerce, оплаты, доставки, кеша, темы или кастомных шаблонов.

Что делать: проверить логи WooCommerce, checkout, корзину, шаблоны темы, плагины оплаты и доставки.

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

Возможная причина: миграция базы не завершилась, кеш сброшен, появился тяжёлый запрос, конфликт object cache или cron-задачи.

Что делать: проверить Query Monitor, cron, Action Scheduler, кеш, базу данных и нагрузку сервера.

Проблема: после обновления не работает редактор страниц

Возможная причина: REST API, JavaScript-ошибка, security-плагин, конфликт конструктора или темы.

Что делать: открыть консоль браузера, проверить /wp-json/, отключить плагины оптимизации и безопасности, посмотреть debug.log.

Проблема: после обновления пропали стили или скрипты

Возможная причина: кеш, минификация, объединение CSS/JS, CDN, неправильные пути к файлам.

Что делать: отключить минификацию, очистить CDN, проверить Network, восстановить права файлов.

FAQ

Что делать в первую очередь, если сайт сломался после обновления?

Сначала сделайте резервную копию текущего состояния, затем включите debug.log, проверьте email Recovery Mode, файл .maintenance, плагины, тему, .htaccess, PHP и кеш.

Можно ли восстановить сайт без доступа в админку?

Да. Через FTP, файловый менеджер хостинга или SSH можно отключить плагины, сменить тему, удалить .maintenance, восстановить .htaccess и включить debug.log.

Почему после обновления WordPress появляется критическая ошибка?

Обычно причина в плагине, теме или кастомном коде, который несовместим с новой версией WordPress, PHP или другим обновлённым плагином.

Что такое .maintenance?

Это временный файл в корне WordPress, который создаётся во время обновления. Если обновление оборвалось, файл может остаться, и сайт будет продолжать показывать режим обслуживания.

Нужно ли сразу откатывать сайт из backup?

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

Как понять, какой плагин сломал сайт?

Отключите все плагины через FTP или WP-CLI. Если сайт заработал, включайте плагины по одному и проверяйте сайт после каждого включения.

Почему после обновления сломалась только админка?

Причина может быть в плагине, который работает только в админке, в редакторе, REST API, dashboard widget, нехватке памяти или security-правилах.

Почему после обновления сломался только внешний вид?

Часто виноваты кеш CSS/JS, минификация, CDN, изменение файлов темы, конфликт конструктора страниц или устаревшие шаблоны.

Можно ли отключить автообновления?

Можно, но это не должно заменять нормальное обслуживание сайта. Лучше делать backup, тестировать обновления на staging-копии и обновлять сайт контролируемо.

Что делать, если debug.log пустой?

Проверьте, правильно ли включён WP_DEBUG_LOG, есть ли права на запись в wp-content, не пишет ли хостинг ошибки только в server error_log, и не происходит ли сбой до загрузки WordPress.

Вывод

Если сайт WordPress сломался после обновления, не нужно паниковать и переустанавливать всё подряд. В большинстве случаев причина находится в плагине, теме, незавершённом обновлении, .maintenance, .htaccess, PHP-версии, нехватке памяти, кеше или правах файлов.

Безопасный порядок такой: сделать копию, включить debug.log, проверить Recovery Mode, удалить .maintenance, отключить плагины, проверить тему, .htaccess, PHP, кеш и логи сервера.

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