Білий екран замість сайту або адміністративної панелі WordPress називають «білим екраном смерті». Найчастіше сторінка просто перестає виводити вміст: немає тексту, меню чи повідомлення про помилку. Це не означає, що всі дані зникли, але без діагностики не можна визначити, чи проблема пов’язана з плагіном, темою, версією PHP, файлами ядра або сервером.
Перед будь-якими змінами варто зробити резервну копію файлів і бази даних, якщо до них ще є доступ. Відновлення з неповної копії або редагування робочих файлів без підготовки може ускладнити подальший ремонт і призвести до втрати даних. Загальний алгоритм дій описано також у матеріалі Білий екран WordPress: як повернути сайт до роботи.
Увімкнення журналу налагодження
Перший крок — отримати технічні дані замість припущень. WordPress може записувати помилки у файл журналу, якщо в конфігурації увімкнено режим налагодження. Зазвичай для цього в wp-config.php тимчасово встановлюють такі параметри:
define( 'WP_DEBUG', true );
define( 'WPDEBUGLOG', true ); define( 'WPDEBUGDISPLAY', false );
Після цього помилки записуються до wp-content/debug.log, але не показуються відвідувачам. Це безпечніше для робочого сайту, адже виведення технічної інформації на екран може розкрити шляхи до файлів, назви таблиць та інші деталі системи.
Якщо доступна лише панель хостингу, перевірте також журнали PHP та вебсервера. Варто звернути увагу на повідомлення про Fatal error, нестачу пам’яті, неможливість підключитися до бази даних або помилки конкретного розширення. Після завершення діагностики режим налагодження потрібно вимкнути, оскільки постійний запис журналів може збільшувати їхній обсяг, а некоректне налаштування — розкривати службову інформацію.
Тема або плагін
Одна з найпоширеніших причин білого екрана — конфлікт після оновлення або встановлення теми чи плагіна. Проблема може виникнути через несумісність із поточною версією WordPress, PHP, іншим розширенням або через помилку в коді.
Якщо адміністративна панель відкривається, вимкніть нещодавно встановлені або оновлені компоненти та перевірте сайт. Коли панель недоступна, це можна зробити через файловий менеджер або SFTP: каталог потрібного плагіна в wp-content/plugins тимчасово перейменовують. Для перевірки теми аналогічно перейменовують її каталог у wp-content/themes, щоб WordPress спробував активувати доступну стандартну тему.
Змінюйте лише один компонент за раз і попередньо збережіть копію файлів. Масове видалення плагінів або редагування PHP-коду без резервної копії може зламати інші функції сайту. Якщо після вимкнення розширення сайт запрацював, це ще не доводить, що воно є єдиною причиною: потрібно перевірити сумісність версій, налаштування та записи журналу.
Версія PHP
WordPress, тема та плагіни виконуються в середовищі PHP. Після зміни версії на сервері старий код може перестати працювати, а після оновлення WordPress окреме розширення може вимагати новішої версії PHP. У результаті сайт інколи показує лише порожню сторінку або серверну помилку.
У панелі хостингу перевірте активну версію PHP та повідомлення в журналі помилок. Не варто одразу перемикати сайт на випадкову версію: надто стара версія створює ризики безпеки, а надто нова може бути несумісною з поточним кодом. Перед зміною бажано зробити резервну копію, за можливості протестувати сайт на копії або staging-середовищі та перевірити вимоги WordPress, теми й плагінів.
Якщо білий екран з’явився відразу після перемикання PHP, можна тимчасово повернути попередню сумісну версію для діагностики. Це не завжди є остаточним рішенням: після відновлення доступу потрібно оновити застарілі компоненти або замінити ті, що більше не підтримуються.
Пошкоджені файли ядра
Файли ядра WordPress можуть бути пошкоджені через неповне оновлення, помилку під час перенесення, збій диска, некоректні права доступу або втручання шкідливого коду. У такому разі сайт може перестати запускатися навіть після вимкнення плагінів і теми.
Перевіряти ядро варто після виключення очевидних причин. Якщо панель доступна, скористайтеся штатною процедурою перевстановлення файлів WordPress тієї самої версії. За відсутності доступу можна завантажити чистий дистрибутив відповідної версії та замінити системні каталоги й файли, не перезаписуючи wp-content і wp-config.php. Перед такими діями обов’язково збережіть копію сайту.
Проста заміна файлів не усуває зараження, помилки бази даних або проблеми з конфігурацією сервера. Якщо виявлено невідомі PHP-файли, змінені права доступу, підозрілих користувачів чи перенаправлення, потрібна окрема перевірка безпеки. Видалення підозрілих файлів навмання може знищити легітимний код або ускладнити встановлення джерела зараження.
Повернення сайту онлайн
Після виявлення причини спочатку усуньте її на копії або в контрольованій послідовності, а потім перевірте робочий сайт. Переконайтеся, що відкривається не лише головна сторінка, а й адміністративна панель, записи, форми, кошик, сторінки з медіафайлами та підключення до бази даних. Окремо перевірте сайт у режимі без кешу та перегляньте журнали після тестового запиту.
- Збережіть резервну копію поточного стану перед фінальними змінами.
- Вимкніть режим налагодження або налаштуйте його так, щоб помилки не показувалися відвідувачам.
- Видаліть або оновіть несумісний компонент лише після перевірки його ролі.
- Перевірте версію PHP, права доступу до файлів і доступність бази даних.
- Очистьте кеш WordPress, плагіна кешування, CDN та браузера, якщо сайт уже виправлено, але відображається стара версія.
Спеціаліст потрібен, якщо недоступні і сайт, і панель керування, немає актуальної резервної копії, журнал містить критичні помилки, підозрюється вірус або після змін сайт працює нестабільно. У таких випадках важливо не виконувати численні непов’язані дії поспіль: це може знищити сліди проблеми та збільшити ризик втрати даних. Безпечна діагностика має починатися з копії, журналів і визначення межі несправності — WordPress, сервер, база даних чи зовнішня інфраструктура.