Помилка 500 Internal Server Error у WordPress: причини та покрокове виправлення

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

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

Якщо сайт приймає замовлення, оплати або заявки, а доступу до файлів і журналів немає, безпечніше одразу передати діагностику в межах технічної підтримки сайту. Невдале «швидке виправлення» на робочому магазині може коштувати дорожче за саму помилку.

Що насправді означає код 500

За HTTP-стандартом 500 Internal Server Error — загальна відповідь на неочікувану серверну умову. Браузер бачить лише результат, але не знає, на якому шарі стався збій.

Запит до WordPress проходить кілька рівнів:

1. домен і DNS спрямовують відвідувача на сервер;
2. вебсервер Apache або Nginx приймає запит;
3. PHP запускає WordPress;
4. ядро завантажує тему, плагіни й конфігурацію;
5. WordPress звертається до бази та зовнішніх сервісів;
6. сервер формує HTTP-відповідь.

Помилка на будь-якому з етапів може завершитися кодом 500. Саме тому текст у браузері майже ніколи не достатній для діагнозу.

Не плутайте 500 з іншими помилками

Початковий код можна перевірити в DevTools браузера або через перевірку HTTP-заголовків. Важливо тестувати саме проблемну адресу, а не лише головну сторінку.

План перших 15 хвилин

Коли сайт недоступний, дійте за короткою схемою:

1. Перевірте сайт у приватному вікні та з іншої мережі.
2. Запишіть точний час, URL і дію перед помилкою.
3. З’ясуйте масштаб: весь сайт, адмінка, одна сторінка, форма чи checkout.
4. Зробіть знімок поточного стану або резервну копію, якщо це можливо.
5. Відкрийте журнал помилок хостингу, PHP або WordPress.
6. Якщо перед збоєм було оновлення — перевірте відповідний плагін або тему першими.
7. Змінюйте одну річ за раз і ведіть короткий журнал дій.
8. Після відновлення перевірте не лише головну, а й форму, кошик, оплату та адмінку.

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

Спочатку визначте масштаб проблеми

Масштаб одразу звужує пошук.

Помилка на всьому сайті й у /wp-admin/

Найімовірніші причини: фатальна помилка під час раннього завантаження, пошкоджений файл конфігурації, несумісність PHP, .htaccess, недоступний PHP-FPM або серверний збій.

Публічна частина не працює, а адмінка відкривається

Перевіряйте тему, шаблон, кеш сторінок, плагін оптимізації та код, який виконується лише на frontend.

Адмінка падає, але сайт для відвідувачів працює

Причиною може бути плагін адміністративного інтерфейсу, імпорт, резервне копіювання, редактор, нестача пам’яті або надто довгий запит.

Помилка лише на одній сторінці

Дивіться шаблон цієї сторінки, shortcode, віджет, конкретний запит до бази, зовнішнє API або пошкоджені дані. Вимикати весь сайт через локальну проблему не потрібно.

Помилка лише під час збереження, імпорту чи оплати

Перевіряйте AJAX/REST-запит, ліміт пам’яті, max_execution_time, розмір запиту, PHP-FPM, webhook або відповідь платіжного сервісу. У Network браузера відкрийте саме невдалий запит і зафіксуйте його URL, метод та час.

Журнали помилок: найкоротший шлях до причини

Починайте не з припущень, а з логів. Залежно від хостингу вони можуть називатися Error Log, PHP log, Apache error log або Nginx error log. Для WordPress зручно тимчасово записувати помилки у wp-content/debug.log.

У wp-config.php, перед рядком про завершення редагування, можна тимчасово додати:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Так повідомлення записуються в журнал, але не показуються відвідувачам. Після діагностики поверніть WP_DEBUG у false, видаліть або захистіть журнал. У ньому можуть бути шляхи до файлів, назви таблиць та інші технічні деталі.

Як читати типовий запис

Приклад:

PHP Fatal error: Uncaught TypeError ...
in /wp-content/plugins/example-plugin/file.php on line 184

Найкорисніші частини:

• тип помилки: Fatal error, TypeError, Allowed memory size exhausted;
• повний шлях до файлу;
• назва плагіна або теми;
• номер рядка;
• час, який треба зіставити зі своїм тестом.

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

Причина 1. Несумісний або пошкоджений плагін

Плагін — найчастіший кандидат, якщо помилка з’явилася одразу після оновлення, встановлення нового розширення або зміни PHP.

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

1. Вимкніть останній змінений плагін.
2. Очистьте лише пов’язаний кеш.
3. Повторіть точну дію, яка давала 500.
4. Якщо сайт запрацював, перевірте журнал і журнал змін плагіна.
5. Не залишайте застарілу вразливу версію постійним «рішенням».

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

Через SFTP або файловий менеджер перейменуйте папку конкретного плагіна, наприклад:

wp-content/plugins/example-plugin
wp-content/plugins/example-plugin.disabled

Якщо підозрюваного немає, можна тимчасово перейменувати всю папку plugins, але це вимкне всі розширення. На WooCommerce така дія може вплинути на кошик, оплату, доставку, листи й інтеграції. Після відновлення назви активуйте плагіни по одному, а не всі разом.

Must-use плагіни

Каталог wp-content/mu-plugins завантажується автоматично й не вимикається зі звичайного списку. Якщо звичайні плагіни відключені, а помилка лишилась, перевірте MU-плагіни, drop-ins object-cache.php, advanced-cache.php, db.php і серверні інтеграції хостингу.

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

Причина 2. Помилка в темі або дочірній темі

Тема може впасти після оновлення, ручного редагування functions.php, зміни версії PHP або виклику функції плагіна, якого вже немає.

Якщо WordPress Recovery Mode надіслав технічний лист, перейдіть за спеціальним посиланням і вимкніть проблемну тему. Якщо листа немає, через SFTP перейменуйте папку активної теми. WordPress спробує перейти на встановлену стандартну тему.

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

Якщо помилка лише в одному шаблоні, порівняйте його з останньою робочою версією. Часті причини:

• синтаксична помилка після ручного редагування;
• виклик видаленої функції;
• неправильний тип даних після оновлення PHP;
• нескінченна рекурсія;
• важкий запит у циклі;
• залежність від неактивного плагіна.

Причина 3. Пошкоджений .htaccess

На Apache синтаксична помилка або недозволена директива в .htaccess може спричинити 500 до запуску WordPress.

Безпечна перевірка:

1. Завантажте копію поточного .htaccess.
2. Перейменуйте його, наприклад у .htaccess.old.
3. Відкрийте сайт і проблемну адресу.
4. Якщо сайт запрацював, у WordPress відкрийте «Налаштування → Постійні посилання» й збережіть структуру, щоб створити базові правила.
5. Повертайте додаткові правила блоками та перевіряйте після кожного.

Не копіюйте чужий .htaccess цілком. У ньому можуть бути правила іншого домену, PHP handler, кеш, захист, редиректи або директиви, які ваш сервер не дозволяє.

На Nginx файлу .htaccess немає. Якщо порада «видаліть .htaccess» нічого не змінює, перевіряйте конфігурацію virtual host, error_log, PHP-FPM і правила reverse proxy.

Причина 4. Ліміт пам’яті або час виконання PHP

Повідомлення Allowed memory size exhausted прямо вказує на нестачу пам’яті в конкретному процесі. Це не завжди означає, що треба просто підняти ліміт. Причиною може бути нескінченний цикл, важкий імпорт, велике зображення, невдалий запит або конфлікт плагінів.

Тимчасове збільшення ліміту може допомогти завершити діагностику, але спочатку зафіксуйте поточні значення. На керованому хостингу реальний ліміт може задаватися не WordPress, а php.ini, .user.ini, панеллю або політикою тарифу.

Схожі записи:

• Maximum execution time exceeded — процес працював довше дозволеного;
• upstream timed out — вебсервер не дочекався PHP-FPM;
• server reached max_children — усі PHP-процеси зайняті;
• MySQL server has gone away — з’єднання з базою розірвано;
• No space left on device — закінчилося місце або inode.

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

Причина 5. Несумісна версія PHP

Старий плагін може використовувати конструкцію, видалену з нової PHP; новий плагін — вимагати версію, якої на сервері ще немає. Помилка часто з’являється після перемикання PHP у панелі або автоматичного оновлення середовища.

Перевірте:

• поточну версію PHP для конкретного домену;
• вимоги WordPress, теми та критичних плагінів;
• розширення PHP, потрібні магазину чи інтеграціям;
• журнал одразу після зміни;
• чи однакова версія працює в web і CLI/cron.

Не перемикайте версію наосліп на production. Краще відтворити сайт на staging, оновити несумісний компонент і прогнати ключові сценарії. Тимчасовий відкат PHP може повернути доступ, але не повинен залишати сайт на непідтримуваній гілці.

Причина 6. Неправильні права або власник файлів

Проблема часто виникає після ручного завантаження, розпакування архіву, перенесення чи запуску команди від іншого користувача. PHP не може прочитати файл, записати кеш або створити тимчасовий каталог.

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

Зіставте проблемний файл із сусідніми робочими, перевірте owner/group і подивіться точний запис Permission denied у журналі.

Причина 7. Пошкоджені файли ядра WordPress

Неповне оновлення, обрив диска, невдале ручне копіювання або зараження можуть пошкодити ядро. Перед перевстановленням переконайтеся, що помилка не в wp-content і не в конфігурації.

Безпечний варіант:

1. створити повну копію;
2. зафіксувати версію WordPress;
3. отримати чистий офіційний пакет тієї самої або контрольовано новішої версії;
4. замінити лише файли ядра, не чіпаючи wp-content і wp-config.php;
5. перевірити журнал, адмінку, медіа, форми та cron.

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

Причина 8. Сервер, WAF, диск або база

Коли код не змінювався, а 500 з’являється хвилями або лише під навантаженням, перевіряйте інфраструктуру:

• використання CPU, RAM, I/O та кількість процесів;
• вільне місце й inode;
• стан PHP-FPM;
• помилки Apache/Nginx;
• доступність MySQL/MariaDB;
• ModSecurity або WAF;
• rate limit і блокування IP;
• cron, імпорт, резервне копіювання та черги;
• зовнішні API, які блокують запит.

WAF може повертати 500 або 403 лише для певного payload: наприклад, під час збереження сторінки з фрагментом коду. Не вимикайте захист глобально. Знайдіть ID правила в журналі й створіть точковий виняток лише після перевірки запиту.

Якщо є сумнів, чи домен, DNS і сервер узагалі відповідають правильно, пройдіть перевірку домену, хостингу та сервера. Помилку сертифіката або неправильний HTTPS не слід маскувати під 500: для цього є окремий гайд про SSL-сертифікат і виправлення HTTPS.

Швидка матриця «симптом → перевірка»

Особливий випадок: WooCommerce

У магазині недостатньо повернути головну сторінку. Після виправлення перевірте:

1. сторінку товару і варіації;
2. додавання та видалення з кошика;
3. купон;
4. checkout для гостя й авторизованого користувача;
5. кожен активний спосіб оплати та доставки;
6. листи покупцю й адміністратору;
7. webhook, CRM, склад і фіскалізацію;
8. фонові завдання та Action Scheduler;
9. створення замовлення без дублювання платежу.

Не повторюйте реальну оплату без контрольного сценарію. Використовуйте sandbox платіжної системи або спеціальне тестове замовлення й одразу перевіряйте журнали.

Що не варто робити

Вносити п’ять змін одночасно

Ви втратите причинно-наслідковий зв’язок і не знатимете, що повернути назад.

Показувати PHP-помилки відвідувачам

Повний шлях до файлу, структура каталогів та фрагменти запиту допомагають не тільки вам. Записуйте помилки в закритий журнал.

Видаляти плагіни, тему або базу без копії

Перейменування оборотне, видалення — ні. Спочатку збережіть файли й дамп.

Ставити права 777

Це небезпечне маскування проблеми, а не правильне налаштування.

Відновлювати випадковий старий бекап поверх робочої бази

У магазині так можна стерти нові замовлення. Спочатку збережіть поточну базу, визначте час збою та план злиття даних.

Оновлювати все на production під час аварії

Масове оновлення додає нові змінні. Спочатку ізолюйте причину й поверніть сервіс, потім оновлюйте контрольовано.

Як зрозуміти, що сайт справді відновлено

Код 200 на головній — лише початок. Перевірте:

• головну та 3–5 типових внутрішніх сторінок;
• /wp-admin/, вхід і збереження запису;
• форми та доставку повідомлень;
• пошук, фільтри, особистий кабінет;
• кошик, checkout і тестову оплату;
• cron та фонові черги;
• журнал помилок після тестів;
• мобільну й десктопну версії;
• кеш із чистої сесії;
• зовнішній HTTP-статус і час відповіді.

Після відновлення запустіть перевірку швидкості сайту. Якщо 500 зникла, але TTFB різко виріс або сервер періодично не відповідає, причина могла залишитися й проявитися знову під навантаженням.

Як запобігти повторенню

1. Оновлюйте WordPress, тему та плагіни спочатку на staging.
2. Створюйте автоматичну копію та окремий pre-update backup.
3. Зберігайте журнали з ротацією й обмеженим доступом.
4. Моніторте HTTP-статус, час відповіді, диск і строк SSL.
5. Видаляйте непотрібні плагіни, а не лише вимикайте.
6. Використовуйте підтримувану версію PHP й перевіряйте сумісність до перемикання.
7. Документуйте ручні зміни в коді та конфігурації.
8. Майте список доступів і відповідального за відновлення.
9. Раз на квартал перевіряйте відновлення копії на окремому середовищі.
10. Після інциденту зафіксуйте першопричину, а не лише виконані дії.

Коли потрібен спеціаліст

Звертайтеся по допомогу, якщо:

• сайт приймає платежі або зберігає критичні заявки;
• немає робочої резервної копії;
• 500 повертається після тимчасового виправлення;
• журнали вказують на базу, PHP-FPM, WAF або сервер;
• є ознаки зараження;
• потрібно зберегти замовлення між копією та поточною базою;
• однаковий збій виникає на кількох сайтах акаунта;
• ви не знаєте, які зміни вже зробив інший підрядник.

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

Підсумковий чекліст

• зафіксовано URL, час і дію перед помилкою;
• визначено масштаб збою;
• створено поточну копію;
• перевірено серверний і PHP-журнал;
• WP_DEBUG_DISPLAY не показує помилки відвідувачам;
• плагіни й тема тестуються по одному;
• .htaccess збережено перед зміною;
• перевірено PHP, пам’ять, timeout, диск і права;
• після відновлення протестовано форми, адмінку й checkout;
• переглянуто нові записи в логах;
• увімкнено моніторинг і створено контрольний бекап;
• першопричину записано в технічний журнал.