Помилка 500 на сайті: як виправити — покрокова інструкція
Помилка 500 на сайті: як виправити — питання, яке часто спливає не у спокійний будній день, а в момент пікового трафіку, запуску реклами або після чергового оновлення. Якщо коротко, то це саме той випадок, коли зручно знати, як виправити помилку 500 на сайті, не втрачаючи час на хаотичні спроби. Код 500 означає внутрішню помилку сервера: сторінка не віддала відповідь, але браузер отримав не точну причину, а загальний сигнал про збій. Це неприємно, зате діагностується. І майже завжди.
Гарна новина в тому, що помилка 500 рідко з’являється «з нізвідки». Найчастіше збивається код, падає PHP, ламається .htaccess, конфліктують плагіни або тема, а іноді сервер упирається в ліміти пам’яті та часу виконання. Саме тому фраза помилка 500 внутрішня помилка сервера зазвичай означає не один, а кілька можливих технічних сценаріїв. Причина може бути й у хостингу. Або в свіжому коміті.
Якщо сайт уже приносить заявки або продажі, простій навіть на 10 хвилин б’є по грошах і по довірі. Тому порядок дій важливіший за здогадки: спочатку локалізуємо проблему, потім чіпаємо налаштування. Без хаосу.
1. Що означає помилка 500 і чому вона з’являється
Internal Server Error — це не діагноз, а парасолька для кількох збоїв. Сервер отримав запит, спробував його обробити й натрапив на проблему, яку не зміг коректно показати користувачу. Зовні все однаково: біла сторінка, повідомлення про помилку, іноді порожній екран.
Найчастіше трапляються 5 причин. Перша — помилка в PHP-коді після правки шаблону або функції. Друга — неправильні правила в .htaccess. Третя — конфлікт плагіна або теми. Четверта — нестача ресурсів: memory_limit, max_execution_time, процесорний час. П’ята — збій на боці сервера або хостингу. Буває і шоста, банальна: права на файли виставлені криво.
На WordPress і схожих CMS це особливо помітно після оновлень. Один плагін оновився, другий ні, кеш залишився старий, а тема звертається до вже видаленої функції. Виходить короткий, але неприємний каскад. Помилка 500 любить такі поєднання.
Якщо сайт зроблений як вебзастосунок, ланцюжок може бути довшим: API, черга завдань, база, зовнішній сервіс оплати. У таких проєктах корисно заздалегідь продумати безпеку сайту і логіку резервного відновлення, бо один збій без журналу подій перетворює пошук проблеми на ворожіння.
2. Спочатку перевірте, де саме виникає помилка
Перший крок — зрозуміти масштаб. Помилка 500 тільки на одній сторінці? Чи на всьому сайті? А може, в адмінці вона з’являється, а на публічній частині все ще відкривається? Ці 3 варіанти ведуть до різних причин.
Якщо помилка видно лише на одній сторінці, шукайте локальний код: шорткод, віджет, форму, нестандартний шаблон, підключений скрипт. Якщо падає весь сайт, дивіться .htaccess, PHP і системні обмеження. Якщо не відкривається адмінка, перевірте плагіни та тему. Після оновлення проблема часто сидить саме там.
Після перенесення на новий хостинг помилка 500 теж трапляється часто. Налаштування PHP можуть відрізнятися, права на папки — теж, а старі правила в конфігу не завжди підходять новому середовищу. Один перенос. Один сюрприз.
Корисно зафіксувати момент, коли все зламалося: після встановлення плагіна, після зміни теми, після зміни версії PHP, після перенесення. Ця маленька хронологія економить години. Іноді й день.
3. як перевірити .htaccess і плагіни
.htaccess — частий винуватець. Достатньо однієї неправильної директиви, і сервер почне віддавати 500 майже на кожній сторінці. Особливо якщо вручну змінювали редиректи, правила кешування або ЧПУ.
Найпростіший тест: тимчасово перейменуйте файл .htaccess, наприклад у .htaccess_old. Якщо сайт ожив, причина майже знайдена. Далі створіть новий файл і перезбережіть налаштування постійних посилань в адмінці CMS. У WordPress це робиться через розділ із постійними посиланнями, без ручного копіювання правил.
Якщо після відтворення правил помилка зникла, старий файл краще не повертати. У ньому могла лишитися зайва строка, наприклад від старого плагіна, який уже видалено. Одна зайва директива здатна покласти весь сайт. Не теоретично.
Коли сайт працює на складній структурі редиректів, особливо після редизайну, корисно заздалегідь перевірити, як поводяться старі адреси та канонічні посилання. Для проєктів з оновленням структури інколи доречно дивитися матеріал про як вибрати вебстудію для редизайну сайту, щоб не отримати плутанину в правилах сервера й внутрішніх маршрутах.
4. Вимкніть плагіни та перевірте тему оформлення
Якщо .htaccess чистий, переходьте до плагінів. На WordPress це робиться швидко: перейменуйте папку plugins через файловий менеджер або FTP. Усі плагіни вимкнуться одразу. Якщо помилка 500 зникла, причина в одному з них.
Далі вмикайте плагіни по одному. Після кожного ввімкнення перевіряйте сайт. Так шукається конфліктний модуль, навіть якщо їх 17. Нудно? Так. Працює? Також так.
Типові винуватці — плагіни кешу, безпеки, SEO, конструктора сторінок і будь-які розширення, які втручаються в маршрутизацію або генерацію контенту. Іноді проблема не в самому плагіні, а в його старій версії. Після оновлення це спливає особливо охоче.
Із темою оформлення чинять так само: тимчасово перемкніться на стандартну тему CMS. Якщо адмінка недоступна, перейменуйте папку активної теми через FTP, щоб система підхопила запасний варіант. Помилка 500 зникла — отже, у темі є битий шаблон, несумісний хук або старий виклик функції.
Коли сайт пов’язаний із зовнішніми сервісами, наприклад оплатою, помилку інколи провокує код інтеграції. Для таких випадків корисно заздалегідь оцінювати зв’язку з платежами та ризики оновлень. Подивіться, наприклад, матеріал про скільки коштує підключити Stripe на сайт, якщо у вас є схожа логіка інтеграції та редиректів.
5. Перевірте помилки PHP і ліміти сервера
Якщо плагіни й тема ні до чого, дивіться логи. У логах помилок PHP зазвичай видно, який файл, рядок або функція зламалися. Іноді там прямо написано: Allowed memory size exhausted. Іноді — fatal error. Іноді — мовчання, що ще гірше.
Логи можуть лежати в панелі хостингу, в окремій папці сайту або в системних звітах сервера. У різних провайдерів шлях свій, тому без панелі хостингу тут не обійтися. Перевірте хоча б 2 місця: журнал помилок сайту і системний лог акаунта.
Тепер до параметрів PHP. Шукайте memory_limit, max_execution_time, upload_max_filesize, post_max_size і версію PHP. Якщо сайт почав падати після оновлення версії PHP, відкат на сумісну версію часто вирішує проблему. Якщо пам’яті мало, важка сторінка, імпорт або плагін просто не встигають виконатися.
Параметр memory_limit особливо помітний на магазинах і великих каталогах. Одна вивантаження товарів може з’їсти ресурс цілком. Одна форма імпорту — теж. Якщо сайт використовує аналітику, черги, фонові завдання й моніторинг, корисно заздалегідь мати платформа аналітики та моніторингу сайтів · як частину спостереження, щоб бачити падіння не за скаргами клієнта, а за логами.
Якщо ви не впевнені, де дивитися налаштування, попросіть хостинг показати поточну конфігурацію PHP і ліміти сервера. Звіряйте не лише версію PHP, а й реальний ліміт пам’яті, час виконання та розмір файлів для завантаження. Дивовижно, як часто проблема сидить в одному значенні.
6. Очистіть кеш і перевірте нещодавні зміни
Кеш уміє маскувати і саму проблему, і її зникнення. Тому після правок очищайте кеш сайту, браузера та CDN, якщо він є. Інакше ви дивитиметеся на стару версію помилки й думатимете, що нічого не змінилося.
Спочатку скиньте кеш у панелі CMS або в плагіні кешування. Потім очистіть браузер, краще в режимі інкогніто. Якщо сайт роздається через CDN, purge робіть і там. Три точки, три кеші, один результат — лише після повного очищення можна вірити перевірці.
Далі подивіться останні зміни. Додали новий блок? Змінили функцію в шаблоні? Завантажили свіжий файл у бібліотеку? Відкотіть останню правку й перевірте знову. Помилка 500 нерідко з’являється після одного маленького рядка коду, а не після «великого оновлення».
У проєктах із постійною підтримкою таких речей майже завжди менше, бо зміни в коді й налаштуваннях ідуть через контроль. Якщо сайт у вас живий, із регулярними доопрацюваннями, стане в пригоді матеріал про підтримка сайту після запуску: там зручно подивитися, як не доводити кеш і оновлення до аварійного стану.
Окремо перевірте, чи не зламався CDN після зміни SSL, редиректів або політики безпеки. Один неправильний заголовок відповіді може дати помилку 500 лише для частини користувачів. І це вже складніше відловити.
7. Що робити, якщо помилка 500 не зникає
Якщо після всіх перевірок сайт усе ще падає, час діяти системно. Спочатку зверніться до підтримки хостингу й запросіть логи за конкретний час збою. Укажіть годину, дату й сторінку, де виникла помилка 500. Без цього техпідтримка шукатиме довше.
Далі перевірте права на файли й папки. Часто папкам ставлять 777 «тимчасово», а потім забувають повернути нормальні значення. Це погана практика, і не лише через помилку 500: сервер може блокувати такі права з міркувань захисту. Файли й каталоги мають мати коректні права.
Якщо є свіжа резервна копія, відновіть робочу версію сайту й перевірте, чи зникне збій. Це особливо корисно після невдалого оновлення ядра, плагіна або перенесення на інший сервер. Один відкат економить більше часу, ніж спроба вручну виправити 12 несумісних змін.
Коли сайт важливий для бізнесу, не тягніть із відновленням. Іноді дешевше повернути копію за вчора, ніж пів дня шукати причину в одному рядку коду. І якщо проєкт пов’язаний із зовнішніми запитами, формами та API, перевірте ще й мережеву частину: іноді проблема не в CMS, а в інфраструктурі. Для таких випадків корисна приватна мережева інфраструктура, коли частина складнощів переходить у контрольоване середовище.
Останній практичний крок — тимчасово ввімкнути мінімальну конфігурацію сайту. Залиште лише ядро, один шаблон, один робочий плагін і базові правила. Якщо помилка 500 зникає в цьому режимі, додавайте компоненти назад по одному. Так ви знайдете проблемний елемент без зайвих здогадок. Це повільно, зате чесно.
