Коли сайт раптово перестає відкриватися, головне — не починати хаотично змінювати файли, налаштування сервера чи базу даних. Неконтрольовані дії можуть ускладнити діагностику та призвести до втрати даних. У перші 15 хвилин варто зафіксувати симптоми, перевірити доступність інфраструктури й зупинити зміни, які могли спричинити збій.
Фіксація симптомів
Спочатку визначте, як саме проявляється проблема. Від цього залежить подальша перевірка та коло можливих причин.
- Сайт не відкривається взагалі. Браузер може показувати помилку DNS, тайм-аут, помилку з’єднання або повідомлення про недоступність сервера.
- Відображається помилка сервера. Коди 500, 502, 503 або 504 часто пов’язані з сервером, PHP, перевантаженням або недоступністю залежних служб.
- Відкривається біла сторінка. Причиною може бути критична PHP-помилка, конфлікт плагінів чи пошкоджений файл.
- Не працює лише адмінпанель. Це може вказувати на проблеми з авторизацією, базою даних, обмеженнями доступу або шкідливими змінами.
- Замість сайту показується сторонній вміст. Такий симптом потребує перевірки на злам, шкідливий код і несанкціоновані зміни.
Зробіть скріншот помилки, запишіть точний час її появи та перевірте сайт у кількох браузерах або з іншої мережі. Якщо доступу немає лише у вас, проблема може бути пов’язана з локальним кешем, DNS або підключенням. Також уточніть, чи однаково поводяться головна сторінка, окремі розділи та сторінка входу в адміністративну панель.
Згадайте останні зміни: оновлення WordPress, теми чи плагінів, редагування DNS, перенесення хостингу, зміну версії PHP, встановлення сертифіката або роботу з файлами. Ця інформація допоможе швидше звузити пошук причини. Не варто відкладати реакцію на проблему, адже Чому не варто відкладати ремонт сайту після збою — це питання не лише зручності для відвідувачів, а й збереження даних та доступу до системи.
Перевірка домену та хостингу
Якщо сайт не відкривається, перевірте базові компоненти, від яких залежить його доступність:
- Переконайтеся, що домен не завершився та не заблокований реєстратором.
- Перевірте, чи правильно налаштовані DNS-записи та чи вказують вони на актуальний сервер.
- Увійдіть до панелі хостингу й подивіться, чи активний обліковий запис, чи не перевищено дисковий простір та інші ліміти.
- Перевірте статус сервера або повідомлення від хостинг-провайдера про технічні роботи чи аварію.
- Спробуйте відкрити сайт через іншу мережу, наприклад мобільний інтернет, щоб виключити локальну проблему.
Помилки DNS можуть з’явитися після зміни реєстратора або хостингу й не завжди означають пошкодження самого сайту. Якщо домен працює, але сервер повертає помилки 5xx, потрібно перевіряти журнали, стан PHP, вебсервер і підключення до бази даних.
Не змінюйте DNS навмання та не видаляйте записи, якщо не розумієте їхнього призначення. Неправильна зміна може порушити роботу пошти, піддоменів, систем аналітики або сервісів оплат.
Вимкнення ризикованих змін
Якщо збій виник одразу після оновлення або редагування, зафіксуйте останню зміну й тимчасово припиніть подальші дії. Не запускайте масове оновлення всіх компонентів, не редагуйте одночасно конфігурацію сервера та файли сайту — так буде складніше визначити справжню причину.
Для WordPress потенційно проблемним компонентом може бути нещодавно оновлений плагін, тема або додатковий модуль. Якщо до адмінпанелі є доступ, вимикайте підозрілий компонент по одному та після кожної дії перевіряйте сайт. Якщо адмінпанель недоступна, роботу з файлами краще виконувати через панель хостингу або SFTP лише після створення копії.
Не видаляйте плагіни, теми, системні файли чи записи бази даних без розуміння наслідків. Також не встановлюйте випадкові «фікси» з неперевірених джерел: під виглядом виправлення вони можуть містити шкідливий код або погіршити стан сайту.
Резервна копія перед ремонтом
Перед ремонтом потрібно зберегти поточний стан сайту, навіть якщо він уже працює некоректно. Резервна копія може містити корисні файли журналів, пошкоджені, але ще відновлювані дані та інформацію про момент виникнення проблеми.
- Зробіть копію файлів сайту, зокрема каталогу завантажень і конфігураційних файлів.
- Експортуйте базу даних у форматі, який можна відновити на сервері.
- Збережіть копію окремо від основного хостингу, якщо це можливо.
- Зафіксуйте дату та час створення копії, а також спосіб її отримання.
- Перевірте, чи архів не пошкоджений і чи справді містить потрібні файли та базу даних.
Якщо сайт заражений, не варто бездумно копіювати всі файли на робоче середовище або одразу відновлювати резервну копію поверх поточних даних. Спочатку потрібно оцінити, чи є копія чистою, наскільки вона актуальна та які зміни в контенті можуть бути втрачені. Відновлення з резервної копії не завжди усуває першопричину: вразливість або скомпрометований доступ можуть залишитися.
Коли ескалувати проблему
До спеціаліста варто звернутися без зволікань, якщо після базових перевірок причина не очевидна або будь-яка подальша дія загрожує даним. Це особливо важливо в таких ситуаціях:
- немає доступу до хостингу, домену, пошти адміністратора чи облікових записів;
- пошкоджена або недоступна база даних;
- сайт показує ознаки злому, редиректи, сторонню рекламу чи змінені облікові записи;
- потрібне відновлення з резервної копії, але її стан не перевірений;
- після оновлення з’явилися критичні PHP-помилки або біла сторінка;
- сайт працює нестабільно, а сервер перевищує ліміти ресурсів;
- необхідне перенесення на інший хостинг без простою та втрати актуальних даних.
Передайте фахівцю скріншоти, точний час збою, перелік останніх змін, дані про хостинг і наявні резервні копії. Не надсилайте паролі у відкритому вигляді — краще створити тимчасовий доступ з обмеженими правами та після завершення робіт змінити облікові дані.
Перші 15 хвилин мають бути присвячені не випадковому «лікуванню» сайту, а збереженню інформації та контролю ризиків. Такий підхід не гарантує миттєвого відновлення, але допомагає не погіршити ситуацію й дає спеціалісту матеріали для точної діагностики.