Секунду тому сайт працював, ви дописували статтю або налаштовували WooCommerce, і раптом порожнеча. Білий аркуш замість адмінки. Або головна сторінка зникла, хоча панель керування відкривається. Знайомо? Ласкаво просимо до клубу, ви зустрілися з White Screen of Death, він же WSOD, він же «білий екран смерті» WordPress.

Паніка тут, перший ворог. WSOD майже ніколи не означає, що сайт помер безповоротно. Найчастіше причина банальна: конфлікт плагінів після оновлення, криво вставлений код у functions.php або банальна нестача пам’яті для PHP-процесу. У цьому посібнику, чотири перевірені способи повернути сайт до життя і п’ятий, вбудований у ядро WordPress, про який забувають навіть досвідчені користувачі.

💡 Швидкий огляд:

• Вимкнути проблемний плагін через FTP (перейменувати папку) або масово, перейменуванням директорії plugins
• Вимкнути конфліктну тему тим самим методом: папка themes → перейменувати директорію активної теми
• Підняти ліміт пам’яті PHP рядком WP_MEMORY_LIMIT у wp-config.php до 128M або 256M
• Увімкнути WP_DEBUG і WP_DEBUG_LOG для діагностики, дізнатися точну причину помилки з файлу debug.log
• Використати Recovery Mode (WordPress 5.2+), вбудований механізм, який надсилає посилання на вхід в адмінку навіть при фатальній помилці
• Відновити сайт із бекапу, якщо інші методи не дали результату

1. Вимкнення проблемного плагіна

Плагіни, найчастіша причина WSOD. Щойно оновили улюблений кешувальний плагін, екран згас. Встановили новий слайдер, сайт перестав відкриватися. Механіка проста: PHP-код плагіна викликає фатальну помилку, і WordPress зупиняє завантаження сторінки повністю.

Біда в тому, що зайти в адмінку й натиснути «Деактивувати» не можна, адмінка так само йде в білий аркуш. Рішення: вимкнути плагін напряму через файлову систему.

Як вимкнути один плагін через FTP:

• Підключіться до сервера через FTP (FileZilla, WinSCP) або через файловий менеджер хостингу (cPanel → File Manager).
• Перейдіть у кореневий каталог WordPress.
• Відкрийте wp-content/plugins.
• Знайдіть папку проблемного плагіна, ім’я збігається з назвою (наприклад, akismet, woocommerce або elementor).
• Перейменуйте папку: додайте символ підкреслення або суфікс, _akismet або akismet_disabled. WordPress сприйме перейменування як відсутність плагіна й деактивує його.

Одразу після перейменування відкрийте сайт у браузері. Заробив, винуватця знайдено. Тепер можна повернути папці вихідне ім’я і, зайшовши в адмінку, або оновити плагін до сумісної версії, або видалити й підібрати альтернативу.

Масове вимкнення всіх плагінів разом. Якщо незрозуміло, який саме плагін спричинив збій, вимкніть усе гуртом. Перейменуйте саму папку wp-content/plugins на plugins_old і створіть поруч нову порожню директорію plugins. Усі плагіни деактивовано. Далі повертайте їх по одному: перенесіть папку плагіна з plugins_old назад у plugins, зайдіть в адмінку, активуйте й перевірте сайт. Повторюйте, поки не знайдете винного.

Альтернатива для тих, у кого є WP-CLI. Одна команда в терміналі замінює FTP-танці з бубном:

1
wp plugin deactivate --all

А потім активуйте по одному: wp plugin activate <slug>. Швидко, чисто, без файлового менеджера.

2. Вимкнення конфліктної теми

Другий за частотою винуватець, тема. Сценарії ті самі: оновили тему до нової мажорної версії, встановили тему з погано написаним functions.php, або плагін вступив у конфлікт із поточною темою після оновлення WordPress.

Механізм виправлення майже ідентичний плагінному:

• Зайдіть через FTP у wp-content/themes.
• Знайдіть папку активної теми (та, що встановлена на сайті прямо зараз).
• Перейменуйте її, наприклад, додайте _disabled у кінець імені.

WordPress, не знайшовши активну тему, автоматично перемкнеться на стандартну тему Twenty Twenty-Five (або Twenty Twenty-Four, залежить від версії WP). Сайт завантажиться з дефолтним дизайном, але весь ваш контент залишиться на місці. Важливо: не видаляйте стандартну тему, інакше перемкнутися буде ні на що, і ви отримаєте ще один виток WSOD.

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

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

3. Перевищення ліміту пам’яті PHP

Сайт ріс, плагінів ставало більше, трафік пішов угору, і раптом WSOD. Класичний симптом того, що PHP-процесу перестало вистачати оперативної пам’яті. Особливо актуально на дешевих хостингах, де один сервер обслуговує сотні сайтів, а ліміт на кожного клієнта урізаний до мінімуму.

WordPress офіційно рекомендує мінімум 64 МБ пам’яті, але ця рекомендація родом з епохи PHP 5.6 і п’яти плагінів на сайт. У 2026 році реалістичний мінімум для працюючого сайту, 128 МБ, а для збірок з Elementor, WooCommerce і кількома десятками плагінів, 256 МБ.

Як збільшити ліміт пам’яті:

Відкрийте файл wp-config.php (лежить у корені встановлення WordPress) і додайте рядок перед коментарем /* That's all, stop editing! */:

1
define('WP_MEMORY_LIMIT', '256M');

Якщо провайдер жорстко обмежує PHP-пам’ять на рівні сервера, ця директива не спрацює, тоді вихід один: змінити тариф або хостинг. Керований WordPress-хостинг (SiteGround, WP Engine, Kinsta) налаштовує ліміти адекватно з коробки, і проблема пам’яті там практично не трапляється.

4. Діагностика через WP_DEBUG

Буває, що ні плагіни, ні тема, ні пам’ять тут ні до чого, причина WSOD вислизає. Тоді треба змусити WordPress розповісти, що саме пішло не так.

WordPress десятиліттями носить у собі вбудований відладчик WP_DEBUG. За замовчуванням він вимкнений (білий екран замість помилок, задум, щоб не світити нутрощі сайту відвідувачам). Але адміністратору цей режим безцінний.

Додайте в wp-config.php:

1
define('WP_DEBUG', true);
2
define('WP_DEBUG_LOG', true);
3
define('WP_DEBUG_DISPLAY', false);

Що відбувається:

• WP_DEBUG вмикає режим налагодження;
• WP_DEBUG_LOG пише помилки у файл wp-content/debug.log, зручно читати, не показуючи відвідувачам;
• WP_DEBUG_DISPLAY зі значенням false приховує помилки з екрана (ви бачите білий аркуш, але логи пишуться).

Після ввімкнення відкрийте сайт, відтворіть проблему й зазирніть у wp-content/debug.log. Там буде рядок із файлом, номером рядка й типом помилки, наприклад, Fatal error: Call to undefined function ... in /wp-content/plugins/some-plugin/file.php:42. Це точна адреса проблеми.

Важливо: не залишайте WP_DEBUG увімкненим на продакшені після діагностики, логи ростуть швидко й можуть забити дисковий простір.

5. Recovery Mode, вбудований рятівник WordPress 5.2+

З версії 5.2 WordPress уміє сам розпізнавати фатальні помилки й пропонувати шлях до відступу. Recovery Mode (режим відновлення), функція, яку багато адміністраторів досі не використовують просто тому, що не знають про неї.

Як це працює. Коли PHP-код плагіна або теми викликає фатальну помилку, WordPress перехоплює її, зупиняє проблемне розширення й надсилає лист на email адміністратора. У листі, посилання, яке відкриває доступ в адмінку в обхід проблемного коду. Ви заходите, бачите плагін, що впав, із позначкою «викликав помилку», деактивуєте його, і сайт знову живий. Жодного FTP, жодного перейменування папок.

Обмеження Recovery Mode:

• Посилання діє обмежений час (близько доби) і прив’язане до IP-адреси;
• Потрібне налаштоване надсилання пошти з сайту (SMTP-плагін або хостингова пошта);
• Не рятує від помилок на рівні сервера (нестача пам’яті, битий .htaccess).

І все ж, якщо лист прийшов, ви економите десяток хвилин нервів і FTP-рухів.

Подивіться короткий посібник з виправлення WSOD, усі описані методи з живою демонстрацією:

⁉️🤔 Часті запитання

Чому білий екран з’являється тільки в адмінці, а сайт відкривається нормально?

Помилка локалізована в коді, який виконується тільки в панелі керування: метабокс плагіна, сторінка налаштувань теми, кастомний віджет адмінки. Вимкніть нещодавно встановлені плагіни по одному, винуватець знайдеться швидко. Якщо не допомогло, увімкніть WP_DEBUG_LOG і дивіться лог після спроби входу в адмінку.

Білий екран тільки на одній сторінці поста чи запису, що це?

Найімовірніше, проблема у вмісті конкретного запису: шорткод неіснуючого плагіна, битий HTML у тексті, конфлікт із кастомними полями. Відкрийте запис через Quick Edit в адмінці й тимчасово змініть статус на «Чернетка». Сторінка завантажиться? Отже, копайте всередині контенту.

Чи можна взагалі уникнути WSOD у майбутньому?

Повністю виключити, ні, але мінімізувати ризик реально. Три правила: (1) завжди тестуйте оновлення плагінів і тем на staging-копії сайту перед викочуванням на продакшен; (2) тримайте щоденний бекап файлів і бази даних; (3) не встановлюйте плагіни й теми із сумнівних джерел, особливо nulled-версії.

Recovery Mode не надіслав листа, що робити?

Пошта з WordPress-сайту без налаштованого SMTP-плагіна працює нестабільно. Налаштуйте SMTP (Post SMTP, FluentSMTP або WP Mail SMTP) як превентивний захід. Якщо лист уже не прийшов, повертайтеся до FTP-методу з розділу 1, він працює завжди.

Через скільки минає посилання Recovery Mode?

Посилання дійсне 24 години (точніше, до завершення nonce-токена). Після цього потрібно відтворити помилку заново, WordPress знову надішле листа.

Що робити, якщо нічого не допомогло?

Якщо чотири методи вище й Recovery Mode не повернули сайт, проблема глибша. Можливо, пошкоджений файл .htaccess (перейменуйте його й зайдіть в адмінку, WordPress створить новий через «Налаштування → Постійні посилання → Зберегти»). Або несумісність версії PHP: сучасний WordPress вимагає PHP 7.4+, а на хості досі може стояти PHP 5.6.

Ще один інструмент діагностики, плагін Health Check & Troubleshooting від команди WordPress.org. Він уміє запускати сесію безпеки: вимикає всі плагіни й перемикає на стандартну тему, але тільки для вашого браузера (відвідувачі бачать звичайний сайт). З ним можна безпечно вмикати плагіни по одному й ловити винуватця, не чіпаючи продакшен.

Немає часу на розслідування, а сайт потрібно підняти прямо зараз? Відновіть бекап. Якщо бекапу немає, урок на майбутнє: щоденні автоматичні бекапи коштують кілька доларів на місяць і окупаються в перший же день аварії. Практично кожен хостинг пропонує цю функцію в панелі керування.

І головне, не бійтеся WSOD. Це неприємно, але вирішувано. Тепер у вас є покроковий алгоритм дій, а не паніка й порожній екран.