Белый экран и ошибка 500 в WordPress: как исправить

Пустая страница, ошибка 500, сообщение "На сайте произошла критическая ошибка" и "Ошибка при установке соединения с базой данных" выглядят как четыре разные проблемы, но в основном это две: PHP упал во время выполнения вашего кода или PHP не смог подключиться к MySQL. Чтобы понять, какая именно, перестаньте гадать и прочитайте ошибку. Включите WP_DEBUG_LOG в wp-config.php, один раз перезагрузите сломанную страницу и прочитайте wp-content/debug.log и журнал ошибок PHP. В девяти случаях из десяти последняя строка называет файл плагина или темы и причину. Если нет, пройдите по порядку шаги из этой статьи: переименуйте папку plugins, переключитесь на стандартную тему, увеличьте лимит памяти, пересоздайте правила перезаписи, проверьте данные для подключения к базе и только потом чините саму базу.

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

Что на самом деле означает каждая ошибка#

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

Классический "белый экран смерти" - самая старая из этих ошибок. До WordPress 5.2 любая фатальная ошибка в плагине давала страницу, на которой ничего нет. Теперь WordPress оборачивает большинство фатальных ошибок, показывает сообщение о критической ошибке и отправляет администратору письмо. Действительно пустая страница сегодня обычно означает одно из трёх: ошибка случилась раньше, чем WordPress смог её перехватить (синтаксическая ошибка в wp-config.php или в файле, который загружается рано), фатальная ошибка произошла в самом обработчике ошибок либо PHP исчерпал память настолько, что ничего не смог вывести.

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

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

Сначала включите логирование: WP_DEBUG и debug.log#

Любое исправление из этой статьи идёт быстрее, когда вы видите настоящую ошибку. В WordPress для этого есть три константы, и все они задаются в 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_DEBUG включает собственный вывод ошибок WordPress. По умолчанию значение false.
• WP_DEBUG_LOG записывает ошибки в wp-content/debug.log. Вместо true можно указать путь, если вы хотите хранить лог в другом месте.
• WP_DEBUG_DISPLAY определяет, выводятся ли ошибки прямо на страницу. По умолчанию значение true, поэтому отладка на работающем сайте может показать пути к файлам каждому посетителю. Поставьте false и читайте лог.

Строка @ini_set( 'display_errors', 0 ) - это страховка: иначе режим отладки WordPress может включить вывод ошибок на хостингах, где собственная настройка PHP его разрешает.

Теперь один раз откройте сломанную страницу, а затем откройте wp-content/debug.log в файловом менеджере. Нужные вам строки выглядят так:

[16-Oct-2026 09:12:41 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function  gutenberg_get_block_template() in /wp-content/plugins/old-slider/slider.php:88[16-Oct-2026 09:12:41 UTC] PHP Fatal error:  Allowed memory size of 134217728 bytes  exhausted (tried to allocate 20480 bytes) in /wp-includes/class-wp-hook.php on line 324

Читайте путь, а не сообщение. /wp-content/plugins/old-slider/ называет плагин. /wp-content/themes/mytheme/functions.php называет тему. Путь внутри /wp-includes/ или /wp-admin/ вместе с сообщением о памяти обычно указывает на жертву, а не на виновника: память израсходовало что-то раньше в этом же запросе, а ядро оказалось тем кодом, который выполнялся в момент, когда память закончилась.

Если debug.log так и не появился, обычно причины такие: wp-config.php отредактирован ниже строки "stop editing" (константы должны идти до загрузки wp-settings.php), у пользователя PHP нет прав на запись в wp-content, либо ошибка происходит ещё до запуска WordPress. В последнем случае единственная запись об ошибке - журнал ошибок PHP.

Как читать журнал ошибок PHP#

debug.log содержит только то, что увидел обработчик WordPress. Журнал самого PHP шире: в него попадают ошибки разбора, фатальные ошибки до запуска WordPress и предупреждения от расширений. Где он лежит, зависит от директивы error_log в php.ini; если она не задана, ошибки уходят в журнал веб-сервера или в стандартный поток ошибок процесса.

Проверьте это скриптом, потому что ответ различается от конфигурации к конфигурации. Положите его в файл, один раз откройте и сразу удалите:

<?phpecho ini_get( 'error_log' ) ?: 'not set - using the server or stderr';echo "\n", ini_get( 'log_errors' ) ? 'log_errors on' : 'log_errors off';echo "\n", php_ini_loaded_file();

Если у вас есть оболочка, следите за логом, пока перезагружаете страницу:

$ tail -f /path/to/php_errors.log

На сервере с панелью управления вывод веб-сервера и PHP появляется в консоли, а любой лог-файл, в который пишет PHP, лежит в файловом менеджере. Сама по себе разница между 500 с фатальной ошибкой PHP в логе и 500 с пустым логом PHP полезна. Фатальная ошибка в логе значит: исправляйте код, который в ней назван. Пустой лог PHP и 500 значат, что запрос вообще не дошёл до PHP, а это указывает на настройки веб-сервера, .htaccess или на убитый процесс. Общий подход к логам описан в статье разбор логов игрового сервера: она про игровые серверы, но привычка читать с конца и сопоставлять время с вашим собственным запросом та же самая. Подробно о настройках журналирования PHP - в статье настройки php.ini, которые важны.

Отключаем плагины без панели управления#

В большинстве случаев белого экрана виноват плагин, и для его отключения не нужна админка. WordPress загружает плагины только из wp-content/plugins. Переименуйте эту папку, и все плагины перестанут загружаться.

1. Откройте файловый менеджер или подключитесь по SFTP (параметры подключения описаны в статье SFTP и файловый менеджер).
2. Переименуйте wp-content/plugins в wp-content/plugins.off.
3. Перезагрузите сайт. Если ошибка исчезла, причина в плагине.
4. Верните папке имя plugins. WordPress покажет все плагины как отключённые, потому что не смог их найти.
5. Переименовывайте папки внутри plugins по одной или половинами, чтобы найти виновника. Остальные включите из панели управления.

Переименование папки одного плагина работает так же и быстрее, если debug.log уже назвал его. Добавьте -disabled в конец имени папки, а не символ в начало, чтобы потом видеть, что вы меняли.

С WP-CLI, если он установлен там, где есть оболочка, та же работа делается двумя командами и не трогает файлы:

$ wp plugin list --status=active$ wp plugin deactivate --all$ wp plugin activate woocommerce

Если WP-CLI отказывается запускаться, потому что сломанный плагин роняет WordPress при загрузке, добавьте --skip-plugins к любой команде: wp plugin deactivate --all --skip-plugins. Есть и парный параметр --skip-themes. Мы не проверяли, что консоль на каждом тарифе даёт оболочку с WP-CLI, поэтому считайте путь через файловый менеджер тем, который работает всегда.

Две оговорки. Во-первых, mu-plugins - это отдельная папка, так называемые must-use плагины, и они загружаются независимо от того, что включено. Некоторые хостинги и плагины кеширования кладут туда файл. Если переименование plugins ничего не изменило, загляните в wp-content/mu-plugins и переименуйте и эту папку. Во-вторых, wp-content/advanced-cache.php и wp-content/object-cache.php - это drop-in файлы, которые оставляют плагины кеширования. Они загружаются раньше плагинов, и файл, ссылающийся на удалённый плагин, роняет всё. Если лог называет любой из этих файлов, переименуйте его.

Переключитесь на стандартную тему#

Если дело не в плагинах, следующей на очереди идёт тема. functions.php темы выполняется при каждом запросе, и одна ошибка в нём роняет весь сайт, включая wp-admin. Обычная причина - правка в редакторе тем, обновление темы, которому нужна более новая версия PHP, или дочерняя тема, у которой переименовали папку родительской.

Уберите папку активной темы с дороги. В wp-content/themes переименуйте сломанную тему, например mytheme в mytheme-off. Когда WordPress не находит активную тему, он переключается на любую стандартную тему, которую найдёт, так что одна из них должна быть на месте: twentytwentyfive или любая другая свежая стандартная тема. Если ни одной нет, загрузите тему с wordpress.org, распаковав zip-архив в wp-content/themes; файловый менеджер распаковывает архивы на месте.

С оболочкой и WP-CLI:

$ wp theme list$ wp theme activate twentytwentyfive

Подставьте имя стандартной темы, которая действительно установлена. Если после переключения сайт заработал, значит, ошибка была в теме. Тема, которая ломается только на одном типе страниц, например на отдельных записях или в магазине, указывает на файл шаблона для этого типа; путь в debug.log назовёт его.

Память PHP: memory_limit и WP_MEMORY_LIMIT#

Сообщение Allowed memory size of 134217728 bytes exhausted - единственная ошибка, которая сама называет способ исправления, хотя не всегда правильный. 134217728 байт - это 128 МБ, обычное значение memory_limit в PHP по умолчанию. Число в "tried to allocate" - это последняя капля, а не общий объём. Взаимодействуют четыре величины:

WP_MEMORY_LIMIT - это объём, который WordPress просит у PHP для запроса к публичной части сайта. Он может поднять лимит только до того, что разрешает сервер, поэтому значение выше memory_limit может молча не сработать, если хостинг закрепил memory_limit настройкой на уровне пула. WP_MAX_MEMORY_LIMIT - более высокий потолок, который WordPress использует для задач администратора, таких как изменение размера изображений и обновления.

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

Если это ничего не меняет, поднимите сам memory_limit в php.ini или в файле .user.ini в корне сайта, если PHP работает через FPM или CGI:

memory_limit = 256M

.user.ini кешируется на несколько минут, так что подождите, прежде чем решать, что это не помогло. Подробный разбор, в том числе почему строки php_value в .htaccess вызывают 500 при PHP-FPM, есть в статье настройки php.ini, которые важны.

Увеличение лимита - это пластырь, а не лечение, если где-то идёт утечка. Одна страница, которой нужно больше 256 МБ, - это почти всегда плагин, загружающий огромный результат запроса, сбойный импорт или бесконечный цикл. Если память заканчивается на тех же 128 МБ или 256 МБ, как бы высоко вы ни ставили лимит, путь к файлу в строке лога подскажет, кто за это отвечает.

Есть и потолок выше PHP. На тарифе с контейнером процесс не может использовать больше памяти, чем выделено тарифом, что бы ни говорил memory_limit. memory_limit в 1 ГБ на тарифе с 1 ГБ при нескольких одновременных запросах заканчивается убитым процессом, а не аккуратным сообщением PHP, и посетитель получает 500 или оборванное соединение, а в логе PHP ничего нет. На RE:NODE сервер, который достиг лимита памяти, останавливается ядром и перезапускается начисто, а не уходит в своп, а графики в консоли показывают память относительно лимита, так что пила, которая доходит до линии и падает, - верный признак. В статье сколько RAM нужно WordPress разобран расчёт по числу рабочих процессов PHP: это правильный способ решить, поднимать лимит или покупать тариф побольше.

Ошибка 500, .htaccess и постоянные ссылки#

500 без ошибки PHP почти всегда означает конфигурацию веб-сервера. Что делать дальше, зависит от того, какой веб-сервер использует ваш тариф, а у разных хостингов это по-разному. Для веб-тарифов RE:NODE мы это не указываем, поэтому оба случая описаны отдельно.

Если ваш тариф работает на Apache или на любом сервере, который читает .htaccess, главный подозреваемый - этот файл. Неверная директива в нём, например строка php_value при PHP-FPM, вставленное правило для незагруженного модуля или лишний символ, даёт 500 на каждый запрос. Пересоздайте файл:

1. Переименуйте .htaccess в корне сайта в .htaccess.bak. Для скрытых файлов в файловом менеджере может понадобиться переключатель "показывать скрытые файлы".
2. Перезагрузите сайт. Главная страница может заработать, а записи будут отдавать 404.
3. В панели управления откройте Settings, затем Permalinks и нажмите Save, ничего не меняя. WordPress запишет новый файл.

Если до панели управления не добраться, создайте файл вручную со стандартным блоком WordPress:

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

С WP-CLI файл перезаписывает команда wp rewrite flush --hard, если он доступен для записи.

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

У 500, который появляется только при одном действии, бывают и менее очевидные причины:

• Тайм-ауты. Страница, которая выполняется дольше max_execution_time (по умолчанию 30 секунд), падает с фатальной ошибкой PHP. Более долгое ожидание на обратном прокси даёт 502 или 504. С этим сталкиваются задачи импорта и плагины резервного копирования.
• Права доступа. WordPress должен читать всё и писать в wp-content. В контейнере, где всем владеет один пользователь, это редко мешает, но файл, загруженный другим пользователем по SFTP, может получить права, при которых PHP его не прочитает. Это разобрано в статье SFTP не может редактировать файлы: permission denied.
• Версия PHP. Плагин, написанный для PHP 7, может упасть на 8.3 и новее. Если в логе стоит "Unsupported operand types" или "Call to undefined function" для чего-то старого, сначала проверьте, какие версии поддерживает плагин.

Файлы ядра WordPress и сообщение о критической ошибке#

"На сайте произошла критическая ошибка" - это WordPress, перехвативший фатальную ошибку и заменивший белый экран сообщением. Важно, что он ещё и отправляет письмо.

Режим восстановления

WordPress отправляет письмо администратору сайта на адрес из Settings, затем General, с темой вроде "Your Site is Experiencing a Technical Issue". В письме названы плагин или тема, вызвавшие сбой, и есть специальная ссылка для входа. Эта ссылка открывает панель управления в режиме восстановления, где сломанный плагин или тема приостановлены только для вашего сеанса. После этого вы можете нормально отключить его на экране Plugins и выйти из режима восстановления.

Три практических замечания:

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

Чтобы письмо уходило на другой адрес, задайте RECOVERY_MODE_EMAIL в wp-config.php:

define( 'RECOVERY_MODE_EMAIL', 'you@example.com' );

Повреждённые файлы ядра

Если лог называет файл в wp-includes или wp-admin либо сообщает об отсутствующем классе, который должно определять ядро, возможно, повреждены сами файлы WordPress - из-за неудачного обновления, прерванной загрузки или вредоносного ПО. Решение - вернуть файлы ядра на место, не затрагивая ваш контент.

С WP-CLI:

$ wp core verify-checksums$ wp core download --force --skip-content

verify-checksums сравнивает ваши файлы ядра с официальными. --force перезаписывает ядро, а --skip-content не трогает wp-content. Без WP-CLI скачайте ту же версию с wordpress.org, распакуйте и загрузите wp-admin и wp-includes поверх существующих, а также отдельные файлы из корня, кроме wp-config.php. Никогда не загружайте ничего поверх wp-content и не удаляйте её: в этой папке ваши загрузки, темы и плагины. Если проверка контрольных сумм не проходит и в папках ядра есть необъяснимые лишние файлы, то проблема в другом, и дальше стоит читать статью что делать, если ваш сервер взломали. Защита от повторения описана в статье защита WordPress.

Ошибка при установке соединения с базой данных#

Эта ошибка исходит от WordPress, а не от PHP, и означает одно: попытка подключиться к MySQL не удалась. У неё четыре причины, и проверять их стоит в порядке от быстрых к медленным.

1. Неверные данные в `wp-config.php`. Чаще всего после переноса, смены пароля или восстановления.
2. Сервер базы данных не работает или недоступен.
3. У базы закончились соединения или ресурсы.
4. Повреждены таблицы.

Начните с файла. Подключение определяют четыре константы:

define( 'DB_NAME', 'wp_site' );define( 'DB_USER', 'wp_user' );define( 'DB_PASSWORD', 'the-generated-password' );define( 'DB_HOST', 'localhost' );

Сверьте каждую с реальными значениями. На веб-тарифе RE:NODE слот базы данных создаётся в панели со сгенерированными хостом, пользователем, именем базы и паролем, а линейка WordPress записывает wp-config.php для собственной базы MySQL, так что файл уже должен совпадать. Если нет, источник истины - раздел баз данных в панели: копируйте оттуда, а не по памяти. Пробела в конце или потерянной при вставке кавычки достаточно, чтобы подключение не удалось. DB_HOST не всегда localhost: для базы на другом хосте нужно имя этого хоста, а нестандартный порт записывается как host:3307.

Кнопка "Open in phpMyAdmin" в панели - самый быстрый способ проверить, жива ли база. Она выполняет вход по одноразовому токену, который истекает через 60 секунд. Если phpMyAdmin открылся и показал ваши таблицы, сервер работает, а ошибка в данных для подключения или в значении хоста в wp-config.php. Если он не открывается, проблема в слоте базы данных, и следующий шаг - обращение в поддержку из панели.

Из оболочки с клиентом MySQL те же данные можно проверить напрямую:

$ mysql -h HOST -u USER -p DATABASE -e "SELECT 1;"

Если это работает, а WordPress всё равно не подключается, значит, что-то отличается на уровне PHP, например отсутствует расширение mysqli, что покажет php -m. В статье mysqli и PDO объясняется, как PHP общается с MySQL и какие драйверы важны. Если сбой нерегулярный и сайт то работает, то падает под нагрузкой, у базы заканчиваются соединения, и этот случай разобран в статье лимиты соединений MySQL и пулинг.

Один вариант стоит выделить. Если на публичной части сайта видна ошибка базы данных, а /wp-admin показывает "One or more database tables are unavailable. The database may need to be repaired", то данные для входа верны, а таблицы повреждены.

Восстановление базы данных#

В WordPress есть встроенное средство восстановления, по умолчанию отключённое, потому что для него не нужен вход. Чтобы включить его, добавьте в wp-config.php одну строку:

define( 'WP_ALLOW_REPAIR', true );

Затем откройте на своём сайте /wp-admin/maint/repair.php. Там две кнопки: Repair Database и Repair and Optimise Database. Нажмите первую. Когда она закончит, сразу удалите эту строку.

Альтернативы:

$ wp db check$ wp db repair

или в phpMyAdmin: отметьте повреждённые таблицы и выберите Repair table в выпадающем списке под перечнем. Учтите, что REPAIR TABLE работает для таблиц MyISAM; для InnoDB, которая используется по умолчанию в современном WordPress, восстановление почти ничего не даёт, и настоящее лекарство - восстановление из backup. В статье резервное копирование и восстановление через mysqldump показано, как сделать экспорт, прежде чем что-либо трогать, а резервные копии баз данных и восстановление описывает общий порядок действий.

Перед восстановлением страховочная сетка - backup из панели. Backup на RE:NODE можно создать по требованию, он хранится вне машины, которую защищает, и восстанавливается кнопкой. Сделайте его перед переименованием папок, правкой wp-config.php или восстановлением базы, и вы всегда сможете вернуться к исходной точке. Backup, который никто не восстанавливал, - это только гипотеза, поэтому прочитайте проверка восстановления до того, как оно понадобится.

Безопасная последовательность действий#

Когда сайт лежит и хочется поменять сразу пять вещей, меняйте по одной и проверяйте после каждой. Этот порядок стоит меньше всего и рискует меньше всего:

1. Откройте /readme.html, чтобы узнать, отвечает ли сервер вообще.
2. Включите WP_DEBUG_LOG при выключенном WP_DEBUG_DISPLAY, перезагрузите страницу и прочитайте debug.log и журнал ошибок PHP.
3. Сделайте backup, если собираетесь менять файлы или базу данных.
4. Переименуйте wp-content/plugins (и mu-plugins, если нужно).
5. Переименуйте папку активной темы.
6. Увеличьте WP_MEMORY_LIMIT, затем memory_limit.
7. Переименуйте .htaccess и пересохраните постоянные ссылки, если ваш тариф работает на Apache.
8. Сверьте DB_NAME, DB_USER, DB_PASSWORD и DB_HOST с данными в панели.
9. Проверьте или замените файлы ядра.
10. Восстановите базу данных как крайнюю меру.

Когда что-то заработает, возвращайте всё на место по одному. Верните папку плагинов, затем включайте плагины половинами. Соблазн оставить сайт работать на стандартной теме и без плагинов велик, и именно так сайты месяцами тихо теряют функции. В конце отключите отладку и удалите debug.log.

Профилактика обходится дёшево. Сначала обновляйте тестовую копию (привычка описана в статье тестовый сервер рядом с боевым), держите свежий backup перед каждым обновлением плагина и не правьте файлы темы в редакторе админки. В нём нет отмены, а в старых установках и проверки синтаксиса, и одна пропущенная точка с запятой - это белый экран.

FAQ#

Почему сайт показывает белый экран без ошибки?

Потому что вывод ошибок выключен, а для работающего сайта это правильно. Ошибка есть, но она в логе. Задайте WP_DEBUG и WP_DEBUG_LOG значение true, а WP_DEBUG_DISPLAY значение false, один раз перезагрузите страницу и прочитайте wp-content/debug.log. Если лог остаётся пустым, проверьте журнал ошибок PHP: сбой мог произойти до запуска WordPress.

Ошибка 500 - это вина хостинга?

Иногда, но редко. Большинство ошибок 500 в WordPress - это плагин, тема, неверное правило в .htaccess или лимит памяти. Сначала попробуйте переименовать плагины и прочитать лог. Если лог PHP пуст, /readme.html тоже не открывается и ничто из сделанного вами не совпадает по времени со сбоем, обращение к хостингу оправдано. Тикеты RE:NODE из панели получают все сотрудники.

На сколько увеличивать лимит памяти?

Сначала до 256M. Если ошибка остаётся и на 256M, выясните, что расходует память, а не увеличивайте лимит снова. Нехватка памяти при любом лимите означает цикл или слишком большой запрос, а не маленький лимит. Лимит выше RAM тарифа лишь меняет аккуратное сообщение PHP на убитый процесс.

Письмо режима восстановления не пришло. Что делать?

Проверьте адрес администратора в Settings, затем General, и загляните в спам. Сайт, который не умеет отправлять почту, не отправит и это письмо. Вместо этого переименуйте папку plugins: она делает ту же работу. Задайте RECOVERY_MODE_EMAIL в wp-config.php, чтобы следующее письмо пришло туда, где вы его прочитаете.

Удалит ли переименование папки plugins мои настройки?

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

Нужен ли WP-CLI, чтобы всё это исправить?

Нет. Для каждого шага есть путь через файловый менеджер или SFTP, а кнопка phpMyAdmin в панели покрывает базу данных. WP-CLI быстрее, если у вас есть оболочка с ним, а --skip-plugins позволяет ему работать, даже когда плагин ломает WordPress при загрузке.