# Білий екран і помилка 500 у WordPress: як знайти причину

> Білий екран і помилка 500 у WordPress: вмикаємо debug.log, вимикаємо плагіни й тему, піднімаємо memory_limit і лагодимо .htaccess за 15 хвилин.

Білий екран без жодного напису або помилка 500 при відкритті сайту на WordPress означають одне: PHP впав ще до того, як встиг віддати HTML браузеру. Розбираємось, як за 15 хвилин знайти причину і повернути сайт у робочий стан, не перевстановлюючи WordPress з нуля.

## Що означає білий екран і помилка 500 у WordPress

«Білий екран смерті» (White Screen of Death) з'являється, коли PHP-скрипт завершився з фатальною помилкою, а виведення помилок на екран вимкнено — так налаштовано за замовчуванням на бойових серверах. Помилка 500 Internal Server Error — по суті те саме, тільки повідомлення формує вебсервер, а не сам WordPress.

Причини в обох проблем майже завжди одні: конфлікт плагіна або теми після оновлення, нестача пам'яті PHP, пошкоджений файл `.htaccess` або синтаксична помилка в коді після ручного редагування functions.php. Перший крок — увімкнути логування і подивитися реальний текст помилки, а не вгадувати.

## Як увімкнути журнал помилок у 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 );
```

Після цього WordPress перестане показувати помилку на екрані відвідувачам, але запише весь стек викликів у файл `wp-content/debug.log`. Подивитися останні рядки логу можна командою:

```
# Показати останні 50 рядків логу помилок
tail -n 50 wp-content/debug.log
```

Шукайте рядок з `PHP Fatal error` — у ньому вказано файл і номер рядка, де стався збій. Зазвичай це шлях усередині `wp-content/plugins/` або `wp-content/themes/`.

## Як знайти винуватця серед плагінів і тем

Якщо лог вказує на конкретний плагін — перейменуйте його папку через FTP або файловий менеджер панелі, наприклад `plugin-name` у `plugin-name-off`. WordPress побачить, що файл плагіна зник, і автоматично вимкне його без доступу до адмінки.

Швидше зробити те саме через WP-CLI, якщо він підключений на сервері:

```
# Вимкнути всі плагіни одразу
wp plugin deactivate --all

# Вмикати плагіни по одному, перевіряючи сайт після кожного
wp plugin activate plugin-name
```

Про інші команди керування плагінами і темами з терміналу — у статті [WP-CLI: керування WordPress з командного рядка](https://www.zevshost.net/uk/kb/wp-cli-commands/). Якщо після вимкнення всіх плагінів сайт запрацював, проблема в одному з них — вмикайте по черзі, поки помилка не повернеться.

Якщо справа не в плагінах, перемкніть тему на стандартну:

```
wp theme activate twentytwentyfour
```

## Помилка 500 через нестачу пам'яті PHP

Рядок `Allowed memory size of 134217728 bytes exhausted` у логі означає, що скрипту не вистачило ліміту `memory_limit`. Значення 134217728 байт — це 128 МБ, стандартний ліміт на багатьох тарифах. Підняти його можна в трьох місцях, за пріоритетом:

| Файл | Рядок | Коли застосовувати |
| --- | --- | --- |
| wp-config.php | `define( 'WP_MEMORY_LIMIT', '256M' );` | працює майже завжди, пріоритет |
| .htaccess | `php_value memory_limit 256M` | тільки якщо PHP працює як модуль Apache |
| php.ini / панель хостингу | `memory_limit = 256M` | якщо є доступ до налаштувань PHP у панелі |

256 МБ вистачає більшості сайтів на WooCommerce і з важкими конструкторами сторінок. Якщо після збільшення ліміту помилка не зникла, справа не в пам'яті, а в нескінченному циклі або рекурсії в коді плагіна.

## Проблеми з .htaccess і правами доступу

Помилка 500 без запису в debug.log майже завжди означає пошкоджений `.htaccess`. Перейменуйте файл на щось на кшталт `.htaccess-old` і зайдіть на сайт знову:

```
# Тимчасово вимкнути .htaccess
mv .htaccess .htaccess-old
```

Якщо сайт відкрився, створіть новий файл, зайшовши в адмінці в розділ «Налаштування → Постійні посилання» і натиснувши «Зберегти зміни» — WordPress пересоздасть правила автоматично. Другий частий винуватець — неправильні права доступу. Правильні значення для WordPress:

```
# Права на папки — 755, на файли — 644
find /var/www/site/public_html -type d -exec chmod 755 {} \;
find /var/www/site/public_html -type f -exec chmod 644 {} \;
```

## Чек-лист діагностики білого екрана

Перед тим як звати техпідтримку хостингу, пройдіться по пунктах:

- Увімкнули `WP_DEBUG_LOG` і подивилися `wp-content/debug.log`.
- Вимкнули всі плагіни через FTP або WP-CLI і перевірили сайт знову.
- Перемкнули тему на стандартну (Twenty Twenty-Four).
- Підняли `memory_limit` до 256М у wp-config.php.
- Перевірили `.htaccess` і права доступу 755/644.

Якщо перед останнім оновленням робили резервну копію — часто швидше відкотитися, ніж шукати причину вручну; порядок відновлення описано в статті [WordPress бекап: UpdraftPlus і ручний метод](https://www.zevshost.net/uk/kb/wordpress-backup-nastroika/). А щоб білий екран не з'являвся після кожного оновлення плагінів, налаштуйте безпечний процес — він розписаний у статті [Безпечне оновлення WordPress: порядок дій і відкат](https://www.zevshost.net/uk/kb/wordpress-bezopasnoe-obnovlenie/).

---

Джерело: https://www.zevshost.net/uk/kb/wordpress-belyy-ekran-oshibka-500/