Як відновити сайт після зламу та повернути SEO-позиції: екстрений протокол дій для WordPress

Успішне відновлення сайту після зламу вимагає системного підходу: термінової ізоляції ресурсу з віддачею статусу HTTP 503, верифікації цілісності файлової структури за контрольними сумами, глибокої зачистки бази даних від бекдорів та коректної конфігурації відповідей сервера (HTTP 410/404) для видалення сміттєвих URL з індексу. Спроба сліпо відновити застарілий бекап без ревізії часто повертає сайт до того ж вразливого стану через законсервований шкідливий код.

Симптоми компрометації: експрес-діагностика зараження WordPress

Значна частина зламів вебресурсів на базі WordPress та WooCommerce залишається непоміченою власниками до моменту падіння трафіку або появи явних санкцій пошукових систем. Вчасна ідентифікація симптомів дозволяє визначити вектор атаки та локалізувати шкоду.

Зовнішній прояв	Тип ураження / Вектор атаки	Наслідки для SEO та бізнесу
Червоний екран або плашка «Deceptive site ahead» у браузері	Фішингові сторінки, шкідливі редиректи, блокування від Google Safe Browsing	Миттєве блокування всього органічного і прямого трафіку, втрата довіри клієнтів
Японські ієрогліфи або назви фарм-препаратів у пошуковій видачі Google	SEO спам на сайті (Japanese Keyword Hack / Pharma Hack)	Засмічення індексу тисячами згенерованих сторінок, розмиття релевантності та песимізація сайту
Редиректи мобільних користувачів на сторонні сайти казино чи лотерей	Ін’єкції у файли .htaccess, index.php або скрипти активної теми	Поведінкові санкції з боку пошукових систем, різке зростання показника відмов (Bounce Rate)
Поява невідомих облікових записів адміністратора або підозрілих cron-завдань	Впровадження веб-шелів, бекдорів (Backdoors), компрометація авторизаційних ключів	Постійний прихований доступ хакерів до файлів та бази даних навіть після видалення видимих вірусів

Діагностична матриця: відновлення з бекапу чи ручна чистка

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

Сценарій / Умови	Рекомендована дія	Критичні ризики
Точний час проникнення відомий, є перевірений «чистий» бекап, створений до дати інциденту	Відновлення файлів і бази даних з бекапу з подальшим обов’язковим оновленням усіх компонентів	Втрата замовлень інтернет-магазину або нових статей, створених між створенням копії та моментом зламу
Дата первинного зламу невідома або бекапи вже містять шкідливий код	Повна заміна ядра та плагінів на оригінальні дистрибутиви + ручний аудит бази даних і папки uploads	Потребує більше технічного часу, однак гарантує повне видалення прихованих веб-шелів
Модифіковано понад 30% файлової структури, пошкоджено системні таблиці БД	Ізоляція загрози, видалення системних директорій (wp-admin, wp-includes), глибока дезінфекція БД	Висока ймовірність повторного зараження без зміни авторизаційних ключів та закриття вразливості

Екстрений протокол: 5 кроків ізоляції та очищення сайту

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

Крок 1. Тимчасова ізоляція (Maintenance Mode)

Якщо ресурс генерує шкідливі редиректи або фішинговий контент, його необхідно негайно закрити для зовнішніх відвідувачів, налаштувавши сервер на віддачу статус-коду HTTP 503 (Service Unavailable). Це дає зрозуміти краулерам Google, що сайт тимчасово перебуває на технічному обслуговуванні, запобігаючи випаданню оригінальних сторінок з індексу під час чистки.

Крок 2. Зміна секретних ключів (SALT) та скидання авторизації

Для блокування сесій зловмисників, які могли перехопити cookie адміністратора, згенеруйте новий набір секретних ключів у конфігураційному файлі wp-config.php. Згідно з документацією WordPress Hardening Documentation, оновлення констант AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY та NONCE_KEY примусово анулює всі діючі сесії користувачів у системі.

Крок 3. Верифікація цілісності ядра та плагінів через WP-CLI

Замість ручного пошуку модифікованих ділянок PHP-коду скористайтеся консольною утилітою WP-CLI для порівняння контрольних сум локальних файлів з еталонними даними в офіційному репозиторії WordPress.org:

# Перевірка цілісності ядра WordPress
wp core verify-checksums

# Перевірка цілісності всіх встановлених плагінів
wp plugin verify-checksums --all

Відповідно до документації WP-CLI Command Reference, утиліта точно вказує на файли, де було додано або змінено код. Каталоги wp-admin та wp-includes найбезпечніше повністю видалити і замінити на свіжі файли відповідної версії ядра.

Крок 4. Зачистка бази даних, бекдорів та WP-Cron

Шкідливі скрипти часто закріплюються всередині бази даних або через системні планувальники завдань, викликаючи рецидив зараження:

• Ревізія адміністраторів: виконайте перевірку списку користувачів wp user list --role=administrator та видаліть усі сторонні профілі.
• Аудит таблиці wp_options: перевірте автозавантажувані параметри (autoload = 'yes') на наявність обфускованих функцій eval(), base64_decode(), gzinflate().
• Перевірка завдань WP-Cron: запустіть wp cron event list, щоб виявити та видалити підозрілі події, які періодично підвантажують спам-файли з віддалених серверів.

Крок 5. Захист медіабібліотеки (uploads)

Папка wp-content/uploads призначена виключно для медіафайлів і не повинна містити виконуваних PHP-скриптів. Створіть файл .htaccess у корені директорії uploads із наступним вмістом для повної заборони запуску коду:

<Files *.php>
deny from all
</Files>

Відновлення SEO-позицій та ліквідація пошукового спаму

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

Правильна віддача кодів відповідей сервера: HTTP 410 проти HTTP 404

Не налаштовуйте 301-редирект зі спам-сторінок на головну сторінку: це розмиває семантику домену та передає спам-сигнали на весь сайт. Оптимальне рішення — повертати для згенерованих хакерами URL заголовок HTTP 410 (Gone) або HTTP 404 (Not Found). Статус 410 прямо повідомляє пошуковому боту, що ресурс видалено назавжди, що суттєво прискорює очищення індексу Google у порівнянні зі стандартними помилками.

Очищення XML Sitemap та видалення спам-URL

Перевірте файли sitemap.xml вашого сайту. Видаліть будь-які згенеровані спам-мапи (хакери часто створюють десятки карт виду sitemap_spam.xml) та надішліть чистий файл карти сайту через Google Search Console для прискореної переіндексації основного вмісту.

Зняття блокування в Google Search Console та Google Safe Browsing

Зняття червоного попередження безпеки виконується згідно з офіційним протоколом Google Search Central Guide for Hacked Sites. Для повернення довіри алгоритмів виконайте наступні кроки:

1. Перейдіть у Google Search Console у розділ Security & Manual Actions (Проблеми безпеки та заходи, вжиті вручну).
2. Ознайомтеся з типами виявлених порушень (шкідливе ПЗ, соціальна інженерія, спам). Детальний опис правил блокування наведено в довідці Google Safe Browsing.
3. Натисніть кнопку Request Review (Запросити перевірку).
4. У формі запиту детально і лаконічно опишіть виконані дії: усунення вразливих плагінів, очищення бази даних, оновлення SALT-ключів та налаштування кодів 410 для спам-сторінок.

Після подання запиту автоматичні системи Google зазвичай проводять повторну перевірку протягом кількох днів, після чого попередження Safe Browsing знімається, а покази сайту у видачі відновлюються.

Захист від повторного зламу: чек-лист безпеки

Ліквідація наслідків без усунення першопричини відкриває шлях для повторного проникнення. Для довгострокової безпеки ресурсу реалізуйте базовий захисний комплекс:

• Регулярне оновлення: своєчасно оновлюйте ядро WordPress, плагіни та теми. Не використовуйте застарілі розширення, розробка яких припинена.
• Автоматичне резервне копіювання: створіть ізольовану систему збереження даних на зовнішньому хмарному сховищі. Докладно про побудову відмовостійких систем читайте в статті про автоматичне резервне копіювання сайту.
• Двофакторна автентифікація (2FA): налаштуйте 2FA для всіх облікових записів з адміністративними правами та обмежте кількість спроб входу.
• Коректні права доступу: встановіть права 755 для директорій та 644 для файлів. Для файлу wp-config.php обмежте права до 600 або 640.

Поширені питання (FAQ)

Скільки часу потрібно Google для зняття попередження «Deceptive site ahead»?

Після відправки запиту на перевірку через Google Search Console сканування сайту займає від 24 до 72 годин за умови, що всі шкідливі скрипти, спам-сторінки та редиректи повністю видалені з сервера.

Чи можна видалити SEO-спам за допомогою файлу robots.txt?

Ні. Закриття спам-URL через Disallow у файлі robots.txt забороняє боту сканувати сторінку, але не видаляє її з індексу, якщо на неї є зовнішні посилання. Єдиний коректний спосіб — віддача кодів HTTP 410 або HTTP 404 безпосередньо сервером.

Чому сайт знову заражається через кілька днів після чистки?

Рецидив зазвичай свідчить про наявність пропущеного веб-шела (бекдору) в директорії uploads чи базі даних, збереження скомпрометованих cron-завдань або невиправлену вразливість у застарілому плагіні/темі.

Якщо ваш вебресурс постраждав від зламу, потрапив під фільтри пошукових систем або потребує регулярного аудиту безпеки, звертайтеся до VORONOV Solutions: ми пропонуємо послуги екстреної чистки сайтів від вірусів, а також пакетне регулярне технічне обслуговування Website Care для надійного захисту вашого онлайн-бізнесу.