- Спочатку перевірте іншу мережу, повідомлення про помилку та статус домену й хостингу.
- До очищення чи відновлення збережіть поточні файли, базу та журнали; захист відвідувачів не відкладайте.
- Після ремонту перевірте шлях заявки до менеджера, а не лише відкриття головної сторінки.
Сайт не працює: що робити власнику в першу годину? Відкрийте його з телефона через мобільний інтернет, збережіть текст помилки, перевірте оплату домену й хостингу. До видалення файлів, перевстановлення або відновлення старої версії зробіть копію поточного стану. Якщо сайт перекидає людей на чужі сторінки, захистіть відвідувачів разом із хостингом і залучіть розробника.
Не кожна недоступність означає злам. Прострочена адреса, збій сервера та шкідливий код потребують різних дій. Завдання власника зараз: визначити симптом, зберегти те, що ще є, і передати виконавцю факти, за якими можна знайти причину.
Перші дії, поки сайт недоступний
- Перевірте іншу мережу. На телефоні вимкніть Wi-Fi та введіть адресу вручну. Порівняйте з комп'ютером. Якщо проблема лише у вас, це ще не загальна аварія.
- Зафіксуйте, що бачите. Зробіть скриншот з адресою, запишіть час і текст помилки. Перевірте головну та одну внутрішню сторінку. Не вводьте паролі, якщо бачите попередження чи чужий сайт.
- Відкрийте кабінети провайдерів звичним способом. Подивіться термін домену, статус хостингу, рахунки й повідомлення про аварію або блокування. Не переходьте для оплати за підозрілим листом.
- Збережіть поточний стан. Потрібні файли, база даних і журнали подій, тобто записи сервера про звернення й помилки. Якщо не знаєте, як їх скопіювати, попросіть хостинг зберегти їх до змін.
- Зменште шкоду. За підозри на зараження попросіть хостинг тимчасово обмежити публічний доступ зі збереженням даних. Призупиніть рекламу на неробочі сторінки та повідомте команді запасний канал звернень.
Збереження копії не має затримувати захист людей: попросіть провайдера обмежити доступ і зберегти матеріали паралельно. Призначте одну людину для зв'язку з хостингом і розробником. Коли кілька людей одночасно змінюють налаштування, зникає зрозуміла послідовність подій.
Симптом, можлива причина та безпечна перевірка
Сайт взагалі не відкривається
Можлива причина: домен не продовжили, порушилися DNS, хостинг не оплачений або заблокований, сервер недоступний. Домен є адресою сайту, хостинг зберігає його дані, а DNS пов'язує адресу із сервером. Повідомлення «не вдалося знайти сервер» і «час очікування вичерпано» вказують на різні етапи, але самі по собі ще не встановлюють причину.
Самостійно: перевірте адресу на помилки, іншу мережу та статус послуг у кабінетах. Якщо оплата прострочена, уточніть у свого провайдера порядок поновлення. Для .ua та .com.ua не розраховуйте на універсальний пільговий строк: перевіряйте правила зони й поточний статус у реєстратора.
Коли потрібен розробник: послуги активні, а сайт недоступний з різних мереж, або перед збоєм змінювали сервер чи DNS. Не підставляйте випадкову IP-адресу: це може додатково порушити роботу пошти.
Браузер попереджає про незахищене з'єднання
Можлива причина: сертифікат прострочений, не поновився або налаштований для іншої адреси. Сертифікат потрібний для захищеного HTTPS-з'єднання. Окрема можлива причина на вашому пристрої: неправильна дата. Саме попередження про сертифікат ще не є доказом зараження.
Самостійно: перевірте дату телефона й комп'ютера, точну адресу та повторіть перевірку в іншій мережі. Збережіть код попередження. У кабінеті хостингу подивіться стан сертифіката й повідомлення про його поновлення; строк залежить від того, який сертифікат використовується.
Коли потрібен розробник: попередження бачать різні пристрої, поновлення не проходить або захищена лише частина адрес. Не просіть клієнтів обходити захист браузера та не вимикайте HTTPS як спосіб ремонту.
Замість сайту помилка 500, 502 або 503
Можлива причина: 500 означає внутрішній збій сервера; 502 означає, що проміжний сервер отримав некоректну відповідь від наступного; 503 означає тимчасову неготовність обробити запит, наприклад під час обслуговування або перевантаження. Код допомагає звузити пошук, але не називає винний модуль.
Самостійно: збережіть код, час і адресу, прочитайте повідомлення хостингу. Запишіть, чи перед цим було оновлення, перенесення або зміна налаштувань. Перевірте одну внутрішню сторінку, щоб зрозуміти масштаб.
Коли потрібен розробник: помилка повторюється або стосується форми чи оформлення замовлення. Передайте хостингу час збою для пошуку в журналах. Не перезапускайте все поспіль і не запускайте повторні оновлення навмання.
Помилка підключення до бази або біла сторінка
Можлива причина: сайт не може зв'язатися з базою даних, де зберігаються тексти, налаштування та записи, або код завершується до показу сторінки. Таке трапляється через налаштування з'єднання, недоступність сервісу чи помилку після зміни коду. Біла сторінка не означає, що весь сайт видалено.
Самостійно: зафіксуйте повідомлення, перевірте сповіщення провайдера та згадайте останню зміну. Не створюйте нову порожню базу замість наявної.
Коли потрібен розробник: повідомлення повторюється або порожня сторінка виникла після оновлення. Він перевіряє журнали та з'єднання, спочатку зберігши дані. Паролі бази й вміст технічних помилок не публікуйте у відкритому чаті.
Сторінка відкривається, але без стилів
Можлива причина: не завантажилися файли оформлення CSS, залишилася стара збережена версія сторінки або після оновлення змінилися адреси ресурсів. Ознаки: текст є, але меню, відступи й кнопки виглядають як звичайний список.
Самостійно: зробіть скриншот і відкрийте сторінку в приватному вікні та на телефоні. Запишіть, чи проблема є на всіх сторінках і мовах. Якщо лише в одному браузері, це корисна підказка для розробника.
Коли потрібен розробник: оформлення зникло в різних відвідувачів або кнопки стали непридатними. Не перемикайте тему оформлення на живому сайті: це додасть нові зміни до невідомої причини.
Форми перестали приносити заявки
Можлива причина: форма не відправляє дані, пошта їх не доставляє або передача у CRM зупинилася. CRM тут означає систему, де команда обробляє звернення. Напис «дякуємо» на екрані ще не підтверджує отримання заявки менеджером.
Самостійно: узгодьте з менеджером одну тестову заявку з чіткою позначкою «тест». Запишіть час, сторінку й місце очікуваного отримання. Перевірте вхідні, спам і список звернень у системі. Якщо це замовлення, не повторюйте його безконтрольно й не запускайте справжню оплату.
Коли потрібен розробник: заявки немає в кінцевому місці або результат нестабільний. Потрібно простежити весь шлях, не лише кнопку. Поки збій не усунутий, дайте команді робочий запасний спосіб прийняти звернення.
Переадресація на чужий сайт лише з телефона чи Google
Можлива причина: сторонній код показує різний результат залежно від пристрою або способу переходу. Водночас треба перевірити рекламні вставки та підключені скрипти. Те, що у власника на комп'ютері все нормально, не спростовує проблему.
Самостійно: збережіть повідомлення клієнта, час, початкову адресу й опис переходу: телефон, пошук, пряме відкриття. Не досліджуйте підозрілу кінцеву сторінку та нічого з неї не завантажуйте.
Коли потрібен розробник: негайно після такого сигналу. Попросіть хостинг допомогти обмежити небезпечну видачу зі збереженням даних. Не вважайте проблему вирішеною після очищення кешу власного браузера.
Google попереджає про злам або показує чужі сторінки
Можлива причина: на сайт додали сторонні сторінки, підмінили вміст або пошук ще показує наслідки минулого зараження. Дивні заголовки іншою мовою та невідомі адреси варто передати для перевірки, навіть якщо головна сторінка виглядає звично.
Самостійно: відкрийте свій Search Console, інструмент Google для власників сайтів, і звіт «Проблеми безпеки». Збережіть наведені приклади адрес без переходу на небезпечні сторінки. Це приклади, а не обов'язково повний список.
Коли потрібен розробник: є попередження або підтверджені сторонні сторінки. Після очищення всього сайту та перевірки виправлень подайте запит на перевірку в цьому звіті. Не обіцяйте собі миттєвого зняття попереджень чи повернення позицій.
Хостинг заблокував сайт через шкідливий код
Можлива причина: провайдер виявив зараження або небезпечну активність. Обмеження та порядок їх зняття залежать від хостингу; звичайна оплата не є лікуванням зараження.
Самостійно: прочитайте повідомлення в кабінеті, попросіть перелік виявлень, час спрацювання, збереження журналів і можливість отримати копію файлів та бази без публічного запуску. Уточніть, які саме дії потрібні для повторної перевірки.
Коли потрібен розробник: одразу для оцінки очищення. Не видаляйте весь список автоматично: зараженим може бути фрагмент потрібного файлу. Перенесення зараженої копії на інший сервер без усунення причини переносить і проблему.
Вхід в адмінку перестав працювати
Можлива причина: помилка пароля, блокування входу, збій після оновлення або зміна облікового запису сторонньою людиною. Адмінка є закритою частиною для керування сайтом. Одна невдала спроба входу ще не доводить злам.
Самостійно: перевірте звичну адресу, розкладку клавіатури й власну пошту. Якщо немає ознак зараження, скористайтеся штатним відновленням пароля. Незнайоме повідомлення про зміну пошти чи адміністратора збережіть.
Коли потрібен розробник: відновлення не працює, пошту змінили без вас або є інші підозрілі ознаки. Не перебирайте паролі та не виконуйте чужі команди для зміни бази даних.
Як діяти, якщо сайт справді зламали
Попросіть зберегти повну копію поточного стану до очищення: файли, базу й доступні журнали. Позначте її як заражену, збережіть окремо від публічного сайту та обмежте доступ. Ця копія потрібна для розбору й порятунку даних, а не для повторного запуску. Запишіть, хто і коли її зробив.
З перевіреного пристрою змініть паролі хостингу, адміністраторів і пошти, через яку можна відновлювати доступ. Використовуйте різні паролі; де доступно, увімкніть додаткове підтвердження входу. Попросіть розробника завершити старі сеанси входу та перевірити технічні ключі доступу. Самої зміни одного пароля може бути недостатньо.
Перевірте список адміністраторів разом із відповідальною людиною: хто створив кожний запис і чи він потрібний. Збережіть список перед змінами, а невідомі облікові записи після перевірки заблокуйте. Не передавайте нові паролі в той самий сумнівний канал і не публікуйте скриншоти з персональними даними клієнтів.
Для відновлення потрібна перевірена чиста резервна копія. Дата до виявлення зламу не гарантує чистоти: проникнення могло відбутися раніше. Розробник має перевірити копію, усунути шлях повторного входу та погодити запуск. Якщо чистої копії немає, обсяг відновлення визначають після огляду; обіцяти повернення всього заздалегідь нечесно.
Перед погодженням старої версії запитайте, які дані з'явилися після її дати: звернення, замовлення, нові тексти чи файли. Попросіть окремий план їх збереження й перенесення, щоб повернення сторінок не стерло останні дні роботи. Не відкривайте копію зараженого сайту як звичайну програму на своєму комп'ютері та не залишайте архів у доступній з браузера папці.
Коли вам кажуть «копію зроблено», уточніть, чи є і файли, і база, де вона лежить та чи перевіряли можливість її прочитати. Знімок головної сторінки не замінює дані сайту. Погодьте з виконавцем одну конкретну точку повернення і попросіть повідомляти про завершення кожного узгодженого етапу, щоб команда знала, коли можна відновлювати звичайну роботу.
Не видаляйте лише знайдений заражений файл і не зупиняйтеся на цьому. Можуть залишитися інші зміни та причина проникнення. Не накочуйте стару копію поверх поточної без збереження: так можна втратити нові звернення й матеріали. Після очищення перевіряють сайт у різних умовах, повторно змінюють потрібні паролі та, якщо Google показує проблеми безпеки, надсилають запит на перевірку через Search Console.
Наш зріз: як часто сайт просто не відкривається
21-23.10.2026 ми виконали по одній перевірці 2 042 сайтів харківських компаній, адреси взяли з карток компаній у Google Maps. Для 98 не визначилася адреса домену, у 81 сервер не відповів, у 72 була сторінка помилки HTTP 4xx/5xx, з них 13 серверних помилок 5xx. Окремо для 148 не було робочого захищеного HTTPS-з'єднання. Ще 39 сайтів заборонили перевірку й до підрахунків не включені.
Це одноразовий зріз, не вимір тривалості простою і не підрахунок зламів. Сайт міг не працювати кілька хвилин, а непрацюючий домен може належати закритому бізнесу. Показники не слід складати як число унікальних аварій. Іншу вибірку та метод описує наше дослідження типових проблем сайтів.
Як зрозуміти, що відновлення завершене
Відкрийте сайт з телефона через мобільну мережу та з комп'ютера. Перевірте головну, сторінку послуги або товару, мовні версії та звичний шлях звернення. Якщо збій залежав від переходу з пошуку, попросіть перевірити саме цей сценарій без небезпечного відвідування заражених сторінок.
Надішліть погоджену тестову заявку та дочекайтеся її в менеджера. Для магазину погодьте окрему перевірку кошика й оформлення без випадкових справжніх платежів. Попросіть коротко записати: що сталося, що відновили, з якої копії, що ще обмежено та хто відповідає за наступну перевірку. Відкрита головна сторінка є лише частиною результату.
Куди звернутися по відновлення
Artbrain бере сайт у роботу, розбирається в поточному стані та погоджує подальші кроки. Якщо сайт зламали або заразили, оцінюємо його стан, пояснюємо обсяг відновлення й починаємо після погодження оцінки. Розбір задачі безкоштовний; до початку робіт узгоджуємо обсяг, терміни та вартість.
Передача від попереднього розробника, відсутні доступи, особливості платформ та планові оновлення описані на сторінці підтримки й доопрацювання сайтів. Планування витрат після аварії розглядаємо окремо в матеріалі про вартість обслуговування сайту.
Напишіть нам про збій: надішліть посилання на сайт, час появи проблеми, текст помилки та останню відому зміну. Вкажіть, чи є резервна копія і чи можете ви увійти до свого хостингу й адмінки. Паролі в першому повідомленні не потрібні. Цих фактів достатньо для початку розмови про наступний крок.
Часті питання
Сайт не працює: що робити насамперед?
Відкрийте його з телефона через мобільний інтернет, збережіть помилку й час, перевірте оплату домену та статус хостингу. До видалення, перевстановлення чи відновлення старої версії збережіть файли, базу та доступні журнали. За підозри на зараження попросіть хостинг обмежити публічний доступ зі збереженням даних.
Як зрозуміти, що сайт зламали?
Підозрілі ознаки: переадресації на чужі сайти, невідомі сторінки, незнайомі адміністратори, повідомлення хостингу про шкідливий код або проблеми безпеки в Search Console. Окрема помилка 500 чи прострочений сертифікат ще не доводять злам; потрібна перевірка причини.
Чи можна одразу відновити сайт із резервної копії?
Спочатку збережіть поточний стан, щоб не втратити нові звернення й матеріали. Копію для запуску потрібно перевірити на чистоту та усунути причину проникнення. Дата до виявлення зламу не гарантує, що копія безпечна.
Чому сайт перекидає на іншу адресу лише з телефона або Google?
Сторонній код може змінювати результат залежно від пристрою чи способу переходу. Збережіть початкову адресу, час і опис умов, не досліджуйте небезпечну сторінку. Передайте сигнал розробнику та хостингу, навіть якщо на вашому комп’ютері все виглядає нормально.
Що надіслати для оцінки відновлення сайту?
Посилання на сайт, час появи проблеми, текст помилки, останню відому зміну та інформацію про наявність копії. Напишіть, чи можете ви увійти до свого хостингу й адмінки. Паролі в першому повідомленні не потрібні. Розбір задачі безкоштовний, роботи починаємо після погодження оцінки.
