Білий екран. П’ять цифр: 500 Internal Server Error. Сайт лежить, клієнт у месенджері, а ви не знаєте, за що хапатися.

П’ятисота, найнеприємніший з HTTP-статусів. На відміну від 404 («сторінку не знайдено») або 403 («доступ заборонено»), вона не називає винуватця. Просто «на сервері щось пішло не так». А далі самі: плагін, тема, кривий PHP, хостинг, битий .htaccess, варіантів десятки, і кожен потребує різного лікування.

Хороша новина: помилка 500 завжди виправляється. Без паніки, без перевстановлення WordPress з нуля і в більшості випадків без розробника. За 7 кроків, від 30-секундної діагностики до хірургічної заміни системних файлів, ви знайдете причину й піднімете сайт. Кожен метод із конкретними файлами, рядками коду та скриншотами.

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

• Крок 1: вмикаємо WP_DEBUG і читаємо логи, одразу бачимо, який файл винен
• Крок 2: виключаємо проблеми хостингу, поки порпаєтеся в коді
• Крок 3: лагодимо .htaccess, причина номер один за статистикою підтримки
• Крок 4: піднімаємо ліміт пам’яті PHP, частий винуватець під час завантаження медіафайлів і входу в адмінку
• Крок 5: перезаливаємо ядро WordPress, коли файли пошкоджені збоєм автооновлення
• Крок 6: вимикаємо плагіни через FTP, метод, який закриває більше половини випадків
• Крок 7: скидаємо тему на дефолтну, крок, який часто пропускають

Що таке помилка 500 і звідки вона береться

HTTP 500 — це відповідь сервера, що означає «внутрішню помилку». Запит від браузера дійшов, Apache або Nginx його прийняли, PHP почав виконуватися і спіткнувся. На відміну від 404 або 403, де сервер усвідомлено відповідає «ні», п’ятірка на початку коду каже: щось зламалося всередині скрипта, і сервер не знає, що саме.

У WordPress помилка 500 виникає в чотирьох типових сценаріях:

• Встановили або оновили плагін, а він конфліктує з іншим кодом у системі.
• Змінили .htaccess, і синтаксична помилка обвалила Apache.
• PHP-скрипт вичерпав виділену пам’ять (білий екран із Allowed memory size of X bytes exhausted у логах).
• Файли ядра пошкоджені, збій під час автооновлення, бите завантаження через FTP, кривий плагін, що заліз у системні папки.

Рідше, тема з фатальною помилкою у functions.php, проблеми на боці хостингу (перевантаження, вимкнення PHP-модуля) або битий шорткод видаленого плагіна всередині контенту сторінки.

Перш ніж почати: зробіть повну резервну копію сайту. Без бекапу будь-яка дія з файлами сервера — це ризик. Більшість хостерів дають кнопку бекапу в панелі керування (cPanel, ISPmanager, aaPanel) у два кліки.

1. Увімкніть WP_DEBUG і прочитайте логи

Найшвидший спосіб дізнатися причину, змусити WordPress показати її. Типово ядро приховує PHP-помилки за білим екраном (це режим «не лякати відвідувачів»). Але в WordPress є вбудований механізм налагодження, константи WP_DEBUG.

Підключення режиму налагодження

Відкрийте wp-config.php у корені сайту через FTP або файловий менеджер хостингу. Знайдіть рядок:

1
/* That's all, stop editing! Happy blogging. */

Перед нею вставте блок:

1
// Включаем режим отладки
2
define( 'WP_DEBUG', true );
3
 
4
// Пишем ошибки в файл /wp-content/debug.log
5
define( 'WP_DEBUG_LOG', true );
6
 
7
// Не показываем ошибки посетителям на экране
8
define( 'WP_DEBUG_DISPLAY', false );
9
@ini_set( 'display_errors', 0 );

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

• WP_DEBUG, головний рубильник; без true решта констант не працюють.
• WP_DEBUG_LOG, спрямовує всі помилки у wp-content/debug.log, а не на екран. Відвідувачі не бачать лячних повідомлень.
• WP_DEBUG_DISPLAY + @ini_set, примусово ховає помилки з виводу сторінки.

Збережіть файл, оновіть проблемну сторінку сайту та завантажте wp-content/debug.log через FTP. У лозі ви побачите конкретний файл і рядок: Fatal error: Cannot redeclare my_function() in /home/user/public_html/wp-content/plugins/broken-plugin/broken.php on line 42.

Вимкніть налагодження після діагностики. Закоментуйте або видаліть додані рядки. WP_DEBUG на бойовому сайті сповільнює роботу, а debug.log з часом розростається до гігабайтів.

2. Зв’яжіться з хостинг-провайдером

Логи порожні або не записалися, помилка може бути на боці сервера, а не в коді WordPress. Особливо часто на дешевих тарифах shared-хостингу з жорсткими лімітами на процеси.

Відкрийте тікет у підтримку й додайте три речі:

• Точний час появи помилки з часовим поясом сервера.
• URL сторінки, на якій помилка відтворюється.
• Скриншот помилки, якщо є.

Техпідтримка перевірить серверні логи Apache або Nginx, навантаження на процесор і пам’ять, доступні PHP-модулі. На цьому кроці проблема часто вирішується: адміністратор хоста перезапускає PHP-FPM або править ліміт на кількість процесів.

Як визначити, на чиєму боці проблема

Створіть файл info.php з одним рядком:

1
<?php phpinfo(); ?>

Завантажте його в корінь сайту через FTP і відкрийте ваш-сайт.com/info.php. Побачили таблицю з параметрами PHP, сервер працює, помилка в коді WordPress. Побачили 500, помилка на рівні сервера, несіть цей URL у підтримку.

Після перевірки **видаліть **info.php. phpinfo() розкриває версії, шляхи та модулі сервера — це діра в безпеці.

3. Полагодьте файл.htaccess

.htaccess, конфігураційний файл Apache у корені сайту. WordPress використовує його для людино-зрозумілих URL, переспрямувань і базових правил безпеки. Одна зайва дужка, конфлікт правил від двох плагінів, і весь сайт падає з помилкою 500. За статистикою звернень до підтримки саме .htaccess виявляється причиною номер один.

Швидка перевірка: перейменуйте .htaccess на .htaccess_old через FTP і оновіть сайт. Запрацював, проблема точно в цьому файлі.

Тепер відновіть .htaccess: зайдіть в адмінку WordPress, Налаштування → Постійні посилання та натисніть «Зберегти зміни», не змінюючи структуру. WordPress згенерує новий, чистий .htaccess зі стандартними правилами:

1
RewriteEngine On
2
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
3
RewriteBase /
4
RewriteRule ^index\.php$ - [L]
5
RewriteCond %{REQUEST_FILENAME} !-f
6
RewriteCond %{REQUEST_FILENAME} !-d
7
RewriteRule . /index.php [L]

Якщо ви вносили в .htaccess кастомні правила (переспрямування, кешування, безпека), додавайте їх назад по одному й перевіряйте сайт після кожного. Так визначите рядок-убивцю.

4. Збільште ліміт пам’яті PHP

PHP-скриптам WordPress потрібна оперативна пам’ять. Коли плагін або тема запитують більше виділеного, скрипт падає. Результат: помилка 500 або біла сторінка з Allowed memory size of X bytes exhausted.

Стандартний ліміт у багатьох хостерів досі 64 MB. Для сучасного сайту на WordPress із десятком плагінів цього катастрофічно мало. Рекомендований мінімум, 256 MB.

Спосіб 1: через wp-config.php (пріоритетний)

Додайте в wp-config.php перед /* That's all, stop editing! */:

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

Ця константа перевизначає ліміт PHP для фронтальної частини сайту. Для адмінки WordPress автоматично піднімає планку до WP_MAX_MEMORY_LIMIT (за замовчуванням 256 MB).

Спосіб 2: через php.ini (якщо хостинг не дає правити wp-config)

Створіть файл php.ini зі вмістом:

1
memory_limit = 256M

Завантажте його в корінь сайту та в папку wp-admin/. Не допомогло, створіть або відредагуйте .user.ini у корені сайту з тим самим рядком.

Якщо жоден спосіб не спрацював, тариф хостингу фізично обмежує пам’ять. Час оновлювати тариф або змінювати хостера.

5. Перезалийте файли ядра WordPress

Пошкоджений файл ядра, нечаста, але підступна причина. Збій при автооновленні, битий FTP-трансфер, плагін, що змінив системні файли,, і wp-admin або wp-includes містять сміття.

Порядок дій:

• Завантажте свіжий ZIP-архів WordPress із wordpress.org.
• Розпакуйте архів на комп’ютері.
• По FTP зайдіть у корінь сайту та видаліть папки wp-admin і wp-includes (тільки їх, не чіпайте wp-content!).
• Залийте папки wp-admin і wp-includes зі свіжого архіву.
• Не перезаписуйте wp-content, там ваші теми, плагіни та завантаження.

Кореневі файли (wp-settings.php, index.php та інші) теж можна замінити свіжими з архіву. **Крім **wp-config.php, його не чіпайте, у ньому доступ до бази даних. Після заміни оновіть сайт, помилка зникне, якщо причина була в битих системних файлах.

6. Вимкніть плагіни

Плагін-убивця, найімовірніша причина помилки 500. Оновили кілька плагінів одночасно, і один ліг поперек іншого, привіт, білий екран.

Якщо адмінка працює

Зайдіть у Плагіни → виберіть усі → групова дія «Деактивувати» → «Застосувати». Помилка зникла, вмикайте плагіни по одному, оновлюючи сайт після кожного. Знайшли винуватця, видаліть або повідомте розробника.

Якщо адмінка недоступна

Зайдіть на сервер через FTP і перейменуйте папку wp-content/plugins на plugins_off. WordPress перестане завантажувати всі плагіни, і сайт оживе. Поверніть папці початкове ім'я та перейменовуйте підпапки плагінів по одній, так знайдете проблемний, не заходячи в адмінку.

На що звернути увагу: плагіни кешування (W3 Total Cache, WP Rocket) іноді записують свої правила в .htaccess і wp-config.php. Після деактивації такого плагіна помилка може залишитися, перевірте ці файли та видаліть рядки між маркерами # BEGIN W3TC і # END W3TC або аналогічними.

7. Перемкніться на типову тему

Активна тема, недооцінене, але реальне джерело помилки 500. Особливо якщо в functions.php додали сніпет з фатальною помилкою.

Перевірка проста: через FTP перейменуйте папку активної теми в wp-content/themes/ (наприклад, mytheme → _mytheme). WordPress виявить, що активна тема зникла, і автоматично перемкнеться на стандартну, Twenty Twenty-Five або іншу типову тему, встановлену в системі.

Сайт запрацював на типовій темі, проблема у вашій. Поверніть темі початкове ім'я, відкрийте functions.php і шукайте помилки в кастомному коді. Якщо код додавали не ви, зверніться до розробника теми.

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

Що робити, якщо помилка 500 з'являється тільки під час входу в адмінку?

Швидше за все, ліміту пам'яті PHP не вистачає саме для адмін-панелі, вона вантажить усі плагіни одночасно і важча за фронт. Додайте в wp-config.php рядок define( 'WP_MAX_MEMORY_LIMIT', '512M' );, це окремий ліміт для адмінки, вищий за фронтальний WP_MEMORY_LIMIT. Перевірте також папку плагінів: з нашої практики найчастіше винен плагін безпеки на кшталт Wordfence або бекап-плагін, який споживає пам'ять під час завантаження адмін-бару. Вимкніть їх через FTP (папка plugins_off з кроку 6) і перевірте.

Чи можна лагодити помилку 500 без FTP-доступу?

Так. Більшість хостерів дають файловий менеджер у панелі керування: cPanel → File Manager, ISPmanager → Файли. Через нього перейменовуються .htaccess, папки плагінів і тем, правиться wp-config.php, усі кроки ті самі. Зовсім без доступу до файлів, тільки через підтримку хостингу. Лайфхак: якщо встановлено плагін для сніпетів (Code Snippets, WPCode) і ви останньою дією додали сніпет, спробуйте відкрити ваш-сайт.com/?code_snippets_safe_mode=1 або аналогічний safe-mode URL вашого плагіна. Це вимикає всі сніпети без FTP.

Помилка 500 з'являється тільки на одній сторінці, в чому причина?

Бита функція або шорткод усередині контенту цієї конкретної сторінки. Відкрийте сторінку в редакторі WordPress (якщо адмінка працює) і тимчасово видаліть усі шорткоди, блоки Gutenberg і вставки коду. Якщо адмінка недоступна, знайдіть запис у базі даних через phpMyAdmin (таблиця wp_posts), скопіюйте вміст у текстовий редактор і приберіть підозрілі шорткоди. Найчастіші винуватці: шорткоди видалених плагінів ([dead_plugin] залишився, а плагіна немає), битий PHP у блоках контенту, некоректно вкладені Gutenberg-блоки.

Після відновлення помилка 500 повертається через пару годин, як знайти причину?

Циклічна помилка з інтервалом, майже завжди один із трьох сценаріїв: cron-задача WordPress запускає битий процес за розкладом, плагін кешування генерує битий кеш, або хостинг періодично впирається в ліміт процесів (особливо на дешевих shared-тарифах). Встановіть WP Crontrol і перевірте список cron-задач, знайдіть ту, що збігається за часом із падінням. Скиньте кеш плагіна кешування. Запитайте хостера про ліміт Entry Processes або PHP Workers, на shared-тарифах їх часто ріжуть до 5-10, і сплеск трафіку кладе сайт.

Чи потрібно проходити всі 7 кроків чи можна пропустити частину?

Перші два кроки (WP_DEBUG і хостинг), діагностичні: вони не ламають сайт і дають інформацію. З досвіду підтримки WordPress-сайтів, крок 3 (.htaccess) і крок 6 (плагіни) закривають переважну більшість випадків. Решта припадають на пам'ять PHP, пошкоджене ядро і тему. У типовій ситуації ви вирішите проблему вже на кроках 3 і 6, не проходячи весь ланцюжок.

З чого почати прямо зараз

Не повторюйте типовий сценарій: паніка → видалення всього підряд → погіршення. Йдіть по порядку, від діагностики до виправлення:

Головне правило ремонту WordPress: одна дія, одна перевірка. Ніколи не робіть два виправлення за раз, не зрозумієте, що спрацювало. І запишіть, який саме плагін або правка викликали помилку. Наступного разу полагодите все за 30 секунд.