Перші 5 термінових кроків для відновлення сайту після злому

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

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

У цій інструкції ми розповімо про п’ять перших невідкладних кроків відновлення після злому сайту, у спрощеному, але практично застосовному форматі. Неважливо, чи це WordPress, самописне рішення, інтернет-магазин чи корпоративний сайт — головні принципи однакові: ізоляція, блокування доступу, повернення до чистого стану, перевірка та посилення безпеки.

Як визначити, що ваш сайт зламали

Злом не завжди супроводжується очевидним падінням сайту. Деякі атаки можуть тривати тижнями без явних ознак. Якщо помітили хоча б один із наведених симптомів, потрібно розглядати проблему як інцидент безпеки, а не просто технічну помилку.

• У результатах Google поруч із вашим сайтом з’являються заголовки з азартними іграми, ліками, криптовалютою або контентом для дорослих.
• Браузер показує попередження про шкідливий сайт, фішинг або небезпечне з’єднання.
• Ви не можете увійти в адмінпанель або бачите незнайомих адміністраторів.
• Раптове збільшення навантаження на сервер — CPU, RAM, диск або трафік електронної пошти.
• Неочікувані зміни у файлах .htaccess, index.php, wp-config.php або у файлах теми.
• Відвідувачів перенаправляють на інші домени без вашого відома.
• З вашого хостинг-акаунту без дозволу масово надсилаються листи.
• Відключення плагінів безпеки або видалення логів.

Наприклад, якщо блог, що зазвичай отримує 2000 відвідувачів на день, раптово починає обробляти 30 000 запитів, це найімовірніше бот-активність або атака brute force, а не справжній приріст аудиторії. А якщо тема розміром 10 МБ за кілька днів збільшується до 80 МБ — це може свідчити про приховані backdoor файли.

Перші 30 хвилин після злому: замість паніки — збір доказів і контроль

Не поспішайте видаляти файли хаотично. Це може стерти важливі сліди, ускладнити відновлення і призвести до відкату до зараженої резервної копії. Спершу зробіть «знімок» поточного стану: зафіксуйте дату, час, повідомлення про помилки, уражені URL, підозрілі акаунти, останні оновлення і логи хостингу. Ці дані допоможуть техпідтримці й експертам швидко поставити діагноз.

Особливо важливо вести облік подій на сайтах з електронною комерцією, реєстрацією або персональними даними. Визначте, які дані могли бути скомпрометовані, коли почалася атака і з яких IP-адрес. Якщо ваш сайт розміщений на Hostragons, для прискорення реакції надайте підтримці домен, уражену папку, часовий інтервал і повідомлення про помилки. Детальніше про вибір надійного хостингу читайте на сторінці Пакети безпечного веб-хостингу.

Крок 1: Ізолюйте сайт і обмежте шкоду

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

Переведіть сайт у режим обслуговування або тимчасово обмежте доступ

Якщо ви використовуєте WordPress — увімкніть сторінку технічного обслуговування, у самописних рішеннях можна повернути статус 503, або обмежте доступ лише для певних IP-адрес. Код 503 повідомляє пошуковикам, що сайт тимчасово недоступний, що краще за 404 або порожню сторінку. Якщо сайт поширює фішинг чи шкідливе ПЗ, краще повністю обмежити доступ.

• Не залишайте адмінпанель відкритою для всіх — застосуйте обмеження по IP.
• Тимчасово забороніть запуск PHP у папках для завантаження файлів.
• Якщо зловмисники використовують ваш SMTP для розсилки спаму — зупиніть доступ до поштового сервера.
• Якщо зламано сторінку оплати — тимчасово вимкніть інтеграцію з платіжними системами.

Зберігайте логи і поточний стан файлів

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

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

Крок 2: Змініть усі паролі, ключі та доступи

Багато власників сайтів після злому змінюють лише пароль від адмінпанелі. Але зловмисник міг отримати доступ через FTP, базу даних, панель хостингу, SSH-ключ, поштову скриньку, API-токен або сторонні сервіси. Тому важливо комплексно скинути всі облікові дані.

Які саме паролі потрібно змінити?

• Пароль від панелі хостингу.
• Паролі FTP, SFTP, SSH-користувачів.
• Пароль користувача бази даних та налаштування підключення.
• Адмін-акаунти CMS та всі редактори.
• Поштові скриньки, особливо ті, що надсилають листи від імені домену.
• API-ключі, токени платіжних систем, доступи до CDN і DNS-панелей.
• Ключі Git, деплойменту, автоматизації та резервного копіювання.

Паролі мають бути сильними — не менше 16 символів, унікальними, важко вгадуваними. Використання одного й того ж пароля на різних майданчиках підвищує ризик компрометації. Де можливо, увімкніть двофакторну автентифікацію (2FA), особливо для адміністративних акаунтів — це значно знижує ефективність brute force-атак.

Видаліть підозрілі акаунти і закрийте активні сесії

Якщо у CMS з’явилися незнайомі користувачі — недостатньо просто їх деактивувати. Занотуйте їх ролі, дату створення та активність, а потім видаліть. У WordPress можна скинути всі користувацькі сесії, оновивши ключі безпеки. У самописних системах очистіть таблицю сесій. В інтернет-магазинах першочергову увагу приділяйте адміністративним акаунтам, а не клієнтським.

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

Крок 3: Відновіться з чистої резервної копії або помістіть заражені області в карантин

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

Як обрати чисту резервну копію?

Спочатку визначте, коли з’явилися перші ознаки злому. Наприклад, якщо попередження Google Search Console з’явилось 12 березня, а серверні логи показують підозрілі POST-запити з 5 березня, резервна копія від 12 березня не підходить. Обирайте копії від 4 березня або раніше. Перед відновленням проскануйте резервні файли на шкідливий код.

• Дата резервної копії має бути до початку атаки.
• В копії не повинно бути незнайомих адмін акаунтів.
• Перевірте цілісність файлів, порівняйте ядро CMS з офіційним пакетом.
• У базі даних шукайте приховані iframe, base64 коди, підозрілі скрипти та спам.
• Після відновлення обов’язково оновіть всі компоненти сайту.

Що робити, якщо резервної копії немає?

Відновлення без бекапу потребує більшої уважності. Спершу зробіть копію сайту на тестовому середовищі. Помістіть підозрілі файли в карантин. Перезавантажте ядро CMS з офіційних джерел, замініть теми та плагіни на чисті пакети. Особливу увагу приділіть папці для завантажень — це улюблене місце для прихованих скриптів (.php, .phtml, .phar тощо).

Так само важливо очистити базу даних. Шкідливі редиректи часто зберігаються не у файлах, а в налаштуваннях сайту, віджетах, опціях теми або вмісті сторінок. Пошук можна робити за ключовими словами: script, iframe, eval, atob, base64_decode, gzinflate, shell_exec, document.location. Однак не всі base64 коди шкідливі, тому будьте обережні, щоб не пошкодити роботу сайту. Перед очисткою зробіть повну копію бази.

Крок 4: Очистіть шкідливий код, оновіть і закрийте вразливості

Відновлення сайту — це лише частина роботи. Якщо не знайти і не усунути причину злому, атака може повторитися. Четвертий крок — завершити очистку, закрити дірки в ПЗ і виправити помилки конфігурації.

Перевірочний список для файлової системи

• Перегляньте файли за датою останньої зміни, зверніть увагу на підозрілі зміни.
• Порівняйте ядро CMS з офіційним релізом.
• Перевірте папки завантажень на наявність виконуваних файлів.
• Проаналізуйте приховані файли — .user.ini, .htaccess та подібні можуть містити перенаправлення.
• Зменшіть права доступу: стандартно 644 для файлів і 755 для папок.
• Видаліть непотрібні теми, плагіни, старі резервні архіви та тестові папки.

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

В якому порядку оновлювати?

Спершу оновіть ядро системи, потім тему і в останню чергу — плагіни. Якщо версія PHP застаріла, після тестування сумісності оновіть її до підтримуваної. Сайти, які працюють на старих версіях PHP у 2026 році, мають високий ризик через відсутність оновлень безпеки. Важливо, щоб хостинг підтримував актуальні версії PHP, ізольовані акаунти, регулярне резервне копіювання та захист через веб-фаєрвол (WAF). Деталі про можливості хостингу дивіться на сторінці Hostragons веб-хостинг.

Переконайтеся, що SSL-сертифікат дійсний. SSL не захищає від злому, але шифрує трафік між користувачем і сервером, знижує ризик фішингу. Особливо це важливо на сторінках входу, оплати і реєстрації. Варіанти сертифікатів можна переглянути на придбати сертифікат SSL.

Крок 5: Перед запуском проведіть перевірку, моніторинг і впровадьте постійний захист

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

Перевірки перед виходом у світ

• Перевірте головну, вхідну, платіжну сторінки та популярні URL з різних пристроїв.
• Переконайтеся, що в Google Search Console немає повідомлень про безпеку чи ручних санкцій.
• Огляньте sitemap.xml і robots.txt.
• Проаналізуйте логи сервера на повторювані помилки 404, 500, POST-запити і спроби входу.
• Перевірте репутацію поштової розсилки і, якщо сайт у чорних списках, почніть процедуру видалення.
• Протестуйте форми оплати, контакти і завантаження файлів.

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

Постійні заходи безпеки

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

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

Додаткові кроки відновлення для SEO, репутації та довіри користувачів

Навіть після технічного очищення сайт потребує додаткової уваги з боку SEO. Зловмисники часто генерують тисячі спам-URL. Якщо вони потрапили у пошуковий індекс, після чистки слід налаштувати правильну поведінку — сторінки мають повертати 404, 410 або робитись коректні редиректи. Масове перенаправлення спам-URL на головну сторінку може призвести до зниження рейтингу через погані сигнали якості.

Перевірте у Search Console сторінки, що індексуються, повідомлення про безпеку, ручні санкції та карти сайту. Після видалення шкідливого контенту надішліть оновлений sitemap. За потреби попросіть пошукові системи повторно проіндексувати чисті сторінки, особливо якщо у видачі раніше з’являлися підозрілі заголовки.

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

Поширені помилки, яких варто уникати

Деякі помилки під час відновлення можуть завдати більше шкоди, ніж сам злом. Найпоширеніша — вважати, що проблема зникла, як тільки сайт знову запрацював. Якщо залишився backdoor, зловмисник знову проникне. Інша — відновлення резервної копії без перевірки її чистоти. Заражена копія знову занесе шкідливий код.

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

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

Коротка інструкція для швидкого реагування

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

З Hostragons ви отримуєте надійний хостинг із SSL, керування доменами і рішеннями для резервного копіювання, що підвищує стійкість вашого сайту. Якщо потрібно, перевірте конфігурацію свого хостингу на сторінках Hostragons пакети хостингу та Перевірка домену та управління доменним ім'ям. Перед вибором варіанту пам’ятайте: головне — баланс між швидкістю, безпекою, резервним копіюванням і підтримкою.

Питання-відповіді

Чи варто відразу знімати сайт з публікації після злому?

Якщо сайт поширює шкідливе ПЗ, перенаправляє користувачів або зламані форми оплати, доступ треба обмежити негайно. Якщо ж ситуація менш критична, можна ввімкнути режим обслуговування (503) або обмежити доступ по IP. Головне — захистити відвідувачів і повідомити пошуковим системам, що це тимчасово.

Чи достатньо відновитися з резервної копії?

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

Чи втрачає сайт позиції в пошуку після злому?

Якщо діяти швидко і правильно, довгострокових втрат SEO можна уникнути. Але якщо спам-сторінки індексуються, Google показує попередження або сайт тривалий час недоступний — позиції можуть погіршитися. Після очищення треба перевірити Search Console, надіслати запит на повторну індексацію і видалити спам-URL.

Чому мій WordPress сайт постійно зламують?

Часті повторні зломи — наслідок залишених backdoor, застарілих плагінів, слабких паролів, зайвих адміністраторів, неправильних прав доступу і заражених резервних копій. Важливо не лише видаляти видимий шкідливий код, а й знаходити і усувати корінь проблеми, а також оновлювати всі доступи.

Чи впливає вибір хостингу на безпеку сайту?

Так. Ізольовані облікові записи, підтримка актуальних версій PHP, регулярне резервне копіювання, фаєрвол, сканування на шкідливе ПЗ, швидка технічна підтримка і SSL — все це прямо впливає на рівень безпеки. Безпечний хостинг не гарантує 100% захист, але значно зменшує ризики і прискорює відновлення після інцидентів.