Skip to content

Все для WordPress, веб-розробки — і не тільки

🔧 Як виправити внутрішню помилку сервера WordPress 500
WordPress
6 хв1,277 слів3

🔧 Як виправити внутрішню помилку сервера WordPress 500

Білий екран. П’ять цифр: 500. Ні адмінки, ні сайту, ні натяку на причину. Знайома картина?

Внутрішня помилка сервера WordPress 500, найніміша з усіх помилок. Вона не каже, що саме зламалося, і від цього паніка тільки сильніша. Але реальність прозаїчна: у 9 із 10 випадків винні плагін, тема або один кривий рядок у .htaccess. Сервер не збожеволів, він просто натрапив на код, який не може виконати.

Зараз розберемо три головні сценарії та покроково полагодимо кожен. Без паніки, без дзвінка хостеру о третій ночі. Своїми руками, за 15 хвилин.

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

  • Вимкніть усі плагіни разом, перейменуйте папку plugins через FTP, помилка зникла? Винуватець серед них
  • Скиньте .htaccess до стандартного WordPress: крива директива кешування або редіректу ламає сайт миттєво
  • Увімкніть WP_DEBUG у wp-config.php, побачите конкретний файл і рядок із фатальною помилкою
  • Якщо сайт щойно переїхав на новий хостинг, перевірте версію PHP: WordPress з 2026 року вимагає PHP 8.3 або новіше, і старі плагіни часто несумісні

Коди відповіді HTTP: що сервер намагається вам сказати

Перш ніж пірнати в налагодження, варто розуміти абетку HTTP-відповідей. Сервер завжди відповідає браузеру тризначним кодом, і за першою цифрою вже видно, де шукати біду.

Ноутбук із програмним кодом та інструментами налагодження
  • 1xx, інформаційні: «з’єднання встановлюється, чекайте». До помилок стосунку не мають.
  • 2xx, успіх. Знаменитий 200 OK означає, що сервер віддав сторінку без нарікань.
  • 3xx, перенаправлення. Наприклад, 301 (постійний редірект) або 307 (тимчасовий). Браузер переходить за новою адресою мовчки — це команда, а не помилка.
  • 4xx, помилка на стороні клієнта. 404 Not Found, сторінку видалено або URL набрано з помилкою. Сервер живий, контенту просто немає.
  • 5xx, помилка на стороні сервера. Ось тут починається наша територія.

Серед 5xx три головні «пацієнти»: 503 Service Unavailable (сервер перевантажений, лікується кешуванням або переходом на потужніший тариф), 502 Bad Gateway (PHP-FPM впав або втратив з’єднання з вебсервером, проблема конфігурації) і, нарешті, **500 **Internal Server Error, найзагальніша і тому найпідступніша. Про неї й поговоримо.

Три головні причини помилки 500 і покрокове виправлення

Помилка 500 не загадкова, вона просто загальна. Сервер каже: «я не зміг виконати код, але не скажу який». Діагностика, методичний перебір трьох стандартних винуватців.

1. Несумісність версій PHP під час перенесення сайту

Класика жанру: ви перенесли сайт зі старого хостингу, де крутився PHP 7.4, на новий, з PHP 8.3 або 8.4. І одразу отримали білий екран.

Причина банальна: старий плагін або тема використовують функції, які в нових версіях PHP оголошені застарілими (deprecated) або видалені взагалі. Інтерпретатор відмовляється їх виконувати, і сайт падає.

Як лагодити. Зробіть повний бекап папок wp-content/plugins/ і wp-content/themes/. Потім перейменуйте папку plugins на plugins_old через FTP або файловий менеджер хостингу — це миттєво вимкне всі плагіни разом. Помилка зникла? Винуватець серед плагінів. Повертайте їх по одному, щоразу перевіряючи сайт. Той, після якого 500-та повернулася, і є проблема.

З темами та сама логіка: перемкніться на стандартну тему WordPress (Twenty Twenty-Five або новішу). Сайт ожив? Проблема у вашій темі, оновіть її або замініть.

Цей сценарій найчастіше проявляється під час перенесення сайту між хостингами з різними версіями PHP. Більшість хостерів уже не пропонують PHP 7.x у панелі керування, мінімальні вимоги WordPress з 2026 року починаються з PHP 8.3. Старий код без оновлень у такому середовищі приречений.

2. Пошкоджений.htaccess, невидимий убивця

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

Файл .htaccess (Apache) керує вебсервером на льоту: директива записана, директива виконується. Одна синтаксична помилка, некоректний прапорець або конфлікт правил, і весь сайт відповідає 500-ю.

Як лагодити. Під’єднайтеся до сайту через FTP або файловий менеджер хостингу. Знайдіть .htaccess у кореневій папці (public_html, www або htdocs). Скопіюйте його вміст у текстовий файл як бекап. Потім замініть увесь вміст на стандартний шаблон WordPress:

1 # BEGIN WordPress
2 
3<IfModule mod_rewrite.c>
4RewriteEngine On
5RewriteBase /
6RewriteRule ^index\.php$ - [L]
7RewriteCond %{REQUEST_FILENAME} !-f
8RewriteCond %{REQUEST_FILENAME} !-d
9RewriteRule . /index.php [L]
10</IfModule>
11 
12 # END WordPress

Цей код відновлює стандартні правила перезапису URL (ЛПУ) і прибирає все зайве. Сайт має ожити одразу. Далі можна заново налаштувати плагін, але тепер ви знаєте, куди дивитися, якщо щось піде не так.

Не допомогло? Поверніть старий .htaccess із бекапу і переходьте до наступного кроку. На Nginx .htaccess не працює, дивіться логи /var/log/nginx/error.log, проблема в конфігурації серверного блоку.

3. Фатальна помилка в PHP-коді

Плагін або тема викликають функцію, якої немає, передають неправильний тип аргументу або звертаються до неіснуючого класу. PHP перериває виконання, і перед вами та сама 500-та.

Без налагоджувальної інформації ви ворожите на кавовій гущі. На щастя, WordPress уміє показувати помилки, потрібно лише увімкнути режим налагодження.

Вмикаємо WP_DEBUG

Відкрийте файл wp-config.php у корені сайту. Знайдіть рядок:

1define( 'WP_DEBUG', false );

Замініть false на true. Якщо такого рядка немає, додайте його перед /* That's all, stop editing! */:

1define( 'WP_DEBUG', true );
Екран комп&#39;ютера з редактором коду та програмним кодом

Після збереження оновіть сторінку. Замість білого екрана ви побачите повідомлення на кшталт:

1Fatal error: Call to undefined function wpsupercache_gc() in
2/home/user/public_html/wp-content/plugins/wp-super-cache/wp-cache.php on line 342

У помилці вказано: тип проблеми (undefined function), файл-винуватець (wp-cache.php) і рядок (342). Це пряма вказівка на плагін, що спричинив падіння. Вимкніть його, перейменуйте папку плагіна, сайт запрацює. Далі оновіть плагін, знайдіть заміну або зв’яжіться з розробником.

Обов’язково поверніть WP_DEBUG у false після діагностики. На бойовому сайті вивід помилок відвідувачам не потрібен і може розкрити внутрішні шляхи сервера. Якщо хочете збирати логи без показу на екрані, додайте у wp-config.php рядки define( 'WP_DEBUG_LOG', true ); і define( 'WP_DEBUG_DISPLAY', false );. Помилки записуватимуться у wp-content/debug.log.

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

Чи можна просто перезавантажити сервер, щоб прибрати помилку 500?

Ні. На відміну від 503, яка часто зникає після перезавантаження (знімається пікове навантаження), помилка 500 спричинена проблемою в коді. Перезавантаження сервера її не виправить: після запуску сайт знову натрапить на той самий битий код і впаде.

Як визначити, плагін чи тема винні, якщо адмінка недоступна?

Під’єднайтеся через FTP або файловий менеджер хостингу. Перейменуйте папку wp-content/plugins, це миттєво вимкне всі плагіни. Сайт ожив? Проблема в плагінах. Ні, перейменуйте папку активної теми в wp-content/themes. WordPress автоматично перемкнеться на стандартну тему. Ожив? Проблема в темі.

Чи обов’язково вмикати WP_DEBUG на робочому сайті?

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

Що робити, якщо жоден із трьох способів не допоміг?

Перевірте ліміт пам’яті PHP, memory_limit у php.ini. Іноді скриптам не вистачає виділених мегабайт, і вони падають із 500-ю. Збільште до 256M або 512M. Не допомогло, зверніться до підтримки хостингу: попросіть подивитися логи помилок сервера (error_log Apache/Nginx). Там буде точна причина, яку ви не бачите з боку WordPress.

Сайт на Nginx, що робити з.htaccess?

Nginx не використовує .htaccess. Правила перезапису прописуються в конфігурації серверного блоку (nginx.conf або sites-available/your-site). Якщо ви на Nginx і отримали 500-ту, дивіться логи /var/log/nginx/error.log. Неправильний .htaccess на Nginx-сервері проблем не спричиняє, він просто ігнорується.

Як запобігти помилці 500 у майбутньому?

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

Що робити просто зараз, якщо сайт лежить із 500-ю

Помилка 500 — це головоломка з передбачуваним рішенням. У переважній більшості випадків ви полагодите сайт за чверть години, пройшовшись трьома кроками в правильному порядку: вимкнути плагіни, скинути .htaccess, увімкнути WP_DEBUG. Порядок важливий, від найімовірнішого і найшвидшого до найдетальнішого.

Якщо переносили сайт на новий хостинг, починайте з перевірки PHP. Якщо налаштовували кешування або редіректи, з .htaccess. Якщо оновлювали плагіни і сайт упав, з WP_DEBUG. А якщо нічого не робили, а 500-та з’явилася сама, пройдіть усі три кроки підряд, один із них майже напевно спрацює.

Не відкладайте діагностику: кожна хвилина простою сайту — це втрачені відвідувачі та позиції в пошуку. Відкрийте FTP, зробіть бекап і вперед.

Редакція
РедакціяРедакційна команда→ Усі публікації

Професійна команда авторів та редакторів, що спеціалізуються на створенні якісного контенту.