Як відновити сайт після зламу: технічне очищення, репутація та SEO

• Як дізнатися про злам сайту
• Що робити в перші години після зламу сайту
  • Чому недостатньо просто змінити пароль
• Як провести технічне відновлення сайту після зламу
• Як знайти й закрити вразливість на сайті
• Як відновити репутацію після зламу сайту
• Як відновити SEO після зламу сайту
• Як не допустити повторного зламу: чек-лист

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

Як дізнатися про злам сайту

Про злам найчастіше повідомляє хостинг-провайдер або Google Search Console. Але остаточний висновок роблять за сукупністю ознак: від чужих сторінок у видачі до незнайомих адміністраторів у панелі керування.

• Які є поширені ознаки зламу сайту
• Які є сервіси перевірки зламу сайту
• Як перевірити злам сайту за допомогою інструментів Cityhost

Які є поширені ознаки зламу сайту

Хостинг-провайдери мають найкращі системи моніторингу веб-ресурсу та максимально швидко надсилають повідомлення про можливі проблеми. Однак помітити абсолютно все вони не здатні фізично, тому краще самостійно регулярно перевіряти свій інтернет-проект.

І обов'язково звертати увагу на такі ознаки зламу сайту:

• браузер показує червоний екран замість сайту: «Deceptive site ahead» при фішингу або «The site ahead contains malware» при зараженні;
• у Google Search Console у звіті «Проблеми безпеки» є попередження про зламаний контент;
• відвідувачів перенаправляє на сторонні ресурси, наприклад, казино або фармацевтичні магазини;
• у пошуковій видачі є сторінки, яких ви не створювали, часто японською мовою або з назвами ліків;
• органічний трафік різко впав без зв'язку з відомими оновленнями алгоритмів Google або, навпаки, стрімко зріс;
• у панелі керування з'явилися адміністратори, яких ви не додавали, або плагіни й теми, яких ви не встановлювали;
• хостинг-провайдер повідомив про підозрілу активність, розсилання спаму з вашого акаунта або призупинив веб-ресурс;
• користувачі скаржаться на дивну поведінку сайту, якої ви самі не бачите — шкідливий код часто спрацьовує лише для переходів із пошуку;
• навантаження на CPU різко зросло без видимої причини — перевірте графіки в панелі хостингу;
• у папці wp-content/uploads з'явилися файли з розширенням .php, а в wp-config.php чи .htaccess змінилася дата редагування;
• на пошту прийшов лист, що ваш сайт у Search Console підтвердив новий власник.

Разом з тим не кожна проблема на сайті свідчить про його злам. Помилки 500, 502, 503 найчастіше пов'язані зі збоєм плагіна, кешем чи перевантаженням хостингу. З «Error establishing a database connection» складніше: зазвичай це теж технічний збій, але іноді — наслідок зміни доступів до бази в wp-config.php. Якщо разом із помилкою є хоча б одна ознака зі списку — це вже привід провести комплексну перевірку сайту на злам.

Читайте також: Як захистити сайт на WordPress і не стати жертвою вразливостей відкритого коду

Які є сервіси перевірки зламу сайту

Головний інструмент — Google Search Console. Але є ще декілька сервісів, які перевіряють сайт за секунди, надаючи звіт про віруси, наявність домену та пошти в чорних списках.

Для аналізу ефективності цих сервісів я перевірив свій сайт на кожному:

• Google Search Console — у боковому меню перейдіть в Security & Manual Actions («Безпека та заходи, вжиті вручну») → Security Issues («Проблеми безпеки»). Якщо все добре, ви побачите зелену галочку «Проблем не виявлено», в іншому випадку — категорію проблеми та приклади заражених сторінок.

• Sucuri SiteCheck — вставте доменне ім'я та натисніть Submit. Через 5-10 секунд ви отримаєте звіт зі статусом безпеки та знайденими проблемами.

А нижче побачите, чи немає шкідливого програмного забезпечення на веб-ресурсі та чи немає самого онлайн-проекту в чорних списках.

• Google Safe Browsing — перейдіть на Transparency Report, вставте посилання на сайт та натиснуть на іконку пошуку. Наприклад, в моєму випадку система показала «Небезпечного контенту не знайдено».

На Safe Browsing ви також можете подивитися приклад, як користувачі будуть бачити веб-ресурс, на якому зафіксовано злам.

• VirusTotal — перейдіть на головну сторінку, вставте адресу сайту та натисніть Search. Сервіс перевірить її більш ніж 70 антивірусними рушіями та базами чорних списків і покаже статус вашого проекту в кожному з них.

• MXToolbox — перейдіть у розділ Blacklists, вставте домен та натисніть Blacklist Check. Якщо разом із веб-ресурсом хакери використовували вашу пошту для спам-розсилок, навпроти чорних списків замість зелених галочок будуть червоні з поясненням причини.
• Пошук Google — відкрийте браузер в режимі «Інкогніто», введіть site:вашдомен та подивіться результати видачі. Шукайте сторінки, яких ви не публікували: незнайомі каталоги, ієрогліфи, назви препаратів, азартні ігри. Додатково перейдіть на декілька власних сторінок, щоб перевірити відсутність редиректів на підозрілі веб-ресурси.

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

Як перевірити злам сайту за допомогою інструментів Cityhost

Клієнти Cityhost можуть самостійно перевірити логи в панелі керування. Для цього перейдіть в «Хостинг 2.0» → «Ресурси» — «Запити». Або скористайтеся FTP-клієнтом, наприклад, FileZilla, та знайдіть папку logs.

У вкладці «Запити (HTTP)» можна переглянути не самі файли логів, а зведену статистику на їх основі. Для цього натисніть «+» біля потрібного розділу:

• за кодами відповіді сервера — допомагає знайти помилки: 200 означає успішне завантаження, 404 — сторінку не знайдено, 500, 502 або 503 — виникла проблема в роботі сайту чи сервера;
• за сторінками (URI) — показує, до яких сторінок і файлів найчастіше зверталися;
• за IP-адресами — дає змогу помітити надмірну активність ботів або підозрілих відвідувачів;
• за типами запитів — показує кількість звернень GET, POST та інших запитів до сайту.

Запідозрити злам сайту також можна за незвичними змінами у використанні ресурсів. У розділі «Хостинг 2.0» → «Керування» → «Ресурси» варто перевірити графіки навантаження на CPU, RAM, диск, процеси та MySQL.

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

Водночас високе навантаження не завжди свідчить про злам: його також можуть спричинити оновлення, резервне копіювання, помилка плагіна чи звичайний наплив відвідувачів.

Що робити в перші години після зламу сайту

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

Важливо! При зламі сайту не завжди є можливість увійти в панель адміністратора WordPress, відповідно, доводиться проводити роботи на боці хостингу. Потрапити туди можна через файловий менеджер у панелі керування хостингом (розділ «Файли» або File Manager) або через FTP-клієнт на кшталт FileZilla з доступами, які видав провайдер. Файли проекту, зокрема wp-config.php, .htaccess та папку wp-content, лежать у каталозі public_html або www.

Покрокова інструкція, як діяти в перші години зламу, допоможе вам уникнути хаотичних дій, нових проблем та поглиблення наявних:

1. Зберіть факти. Ви могли дізнатися про злам із позначки у видачі, звіту «Проблеми безпеки», листа хостера або помітити чужі сторінки — зробіть скриншоти всього. Обов'язково фіксуйте дату й час кожного виявлення, щоб потім провести аналіз й коректно оформити звернення до провайдера та Google.
2. Ізолюйте веб-ресурс. Переведіть сайт у режим обслуговування з кодом 503. Саме 503 Service Unavailable одночасно захищає відвідувачів від зараження й повідомляє пошуковим системам, що сайт тимчасово недоступний, тож вони не індексують шкідливий вміст та не знижують позиції за нього. Якщо залишився доступ до адмінпанелі, використовуйте плагін SeedProd чи WP Maintenance, якщо ні — в особистому кабінеті хостинг-провайдера.
3. Створіть резервну копію. Звучить дивно для вже зламаного сайту, але ця копія дозволить зафіксувати стан при зламі. Найпростіше зробити її в панелі хостингу: заархівуйте каталог сайту й окремо експортуйте базу даних через phpMyAdmin (виберіть базу → вкладка «Експорт» → «Вивести»).
4. Замініть паролі. Спочатку акаунт хостингу та доступи FTP/SSH. Потім змініть доступ до бази даних: у панелі хостингу знайдіть розділ керування БД MySQL, змініть пароль користувача, а потім одразу відкрийте wp-config.php та впишіть новий пароль у рядок DB_PASSWORD. Потім змініть паролі всіх адміністраторів WordPress, а в кінці — пошту, до якої прив'язані ці акаунти.
5. Замініть ключі автентифікації. У wp-config.php є вісім рядків із довгими наборами випадкових символів — за ними WordPress впізнає всіх, хто зайшов на сайт. Візьміть нові рядки в офіційному генераторі ключів та замініть ними старі. Після цього сайт перестане впізнавати будь-кого, доки людина не введе логін та пароль заново.
6. Зверніться до провайдера. Технічна підтримка бачить всі логи доступу, серверні сканери, історію змін файлів. Вони можуть сказати, чи не постраждали ваші інші проекти на цьому ж акаунті.

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

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

Чому недостатньо просто змінити пароль

Зміна вашого пароля не чіпає зловмисника, який створив для себе окремого адміністратора. Я перевірив це на тестовому сайті: створив другого адміністратора з логіном hacker-test, зайшов під ним в іншому браузері, а потім змінив пароль у своєму основному акаунті.

На скриншоті видно розділ Users з двома адміністраторами: моїм акаунтом та створеним для тесту hacker-test.

На скриншоті та сама панель керування, відкрита в іншому браузері під акаунтом hacker-test уже після зміни мого пароля. Сесія hacker-test після цього працювала далі, наче нічого не сталося — жодного повторного входу не вимагали.

Далі я замінив вісім рядків із ключами у wp-config.php. Прямого доступу до файлів TasteWP не дає, тому скористався плагіном WP File Manager: відкрив у ньому кореневу папку сайту, знайшов wp-config.php та відредагував потрібний блок прямо в браузері.

Щойно я зберіг файл, з панелі керування вилетіли обидва акаунти: і hacker-test, і я сам. Тож це ефективний спосіб позбутися зловмисника, який вже додав себе адміністратором вашого інтернет-проекту в панелі керування WordPress.

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

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

• Комплексне сканування різними методами
• Ручне та автоматичне очищення сайту
• Як закрити бекдори на сайті

Комплексне сканування різними методами

Проведіть повторне зовнішнє сканування через Sucuri SiteCheck і VirusTotal. Вони дивляться на сайт очима відвідувача, тому знаходять редиректи та підмінені сторінки. Але вони не бачать нічого в самих файлах на сервері.

Тож виконайте другу перевірку зсередини. Встановіть Wordfence або MalCare: обидва плагіни безкоштовно сканують файли безпосередньо на сервері й показують, які з них відрізняються від офіційних версій. Саме так знаходять приховані фрагменти коду, які зовнішні сервіси пропускають.

Швидкість сканування я перевірив на тестовому сайті: безкоштовний Wordfence обійшов 5 713 файлів, шість плагінів, шаблон та 1362 адреси за 59 секунд.

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

Додатково запустіть антивірусну перевірку в панелі хостингу — вона працює на рівні всього акаунта, а не одного сайту. Якщо ваш сайт розміщено в Cityhost, перейдіть «Хостинг 2.0» → «Керування» → «AiBolit» → «Запустити сканування».

Ручне та автоматичне очищення сайту

Автоматичне очищення виглядає привабливо, але має свої нюанси. Я його перевірив з плагіном Wordfence: додав у файл ядра wp-blog-header.php сторонній рядок і запустив повторне сканування. Плагін одразу позначив файл як змінений та запропонував кнопку Repair, відновлення зайняло секунду, доданий рядок зник.

На скриншоті — результат повторного сканування, де Wordfence знайшов змінений файл ядра.

На скриншоті — повідомлення про успішне відновлення файлу.

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

Друга серйозніша — сканер не знає, який код на сайті ваш власний. На щойно створеному тестовому сайті, де я ще нічого не встиг зробити, Wordfence позначив два файли ядра як змінені з рівнем небезпеки High — update-core.php та wp-settings.php. Це не зараження: найімовірніше, їх підправила сама платформа пісочниці під свої потреби. Але власник, який натисне «відновити всі файли», може зламати сайт, навіть не зрозумівши, що зробив.

Тому автоматичне очищення розумно застосовувати точково: до конкретного файлу, щодо якого ви впевнені. Кнопку, яка відновлює все одразу, краще не чіпати взагалі.

У решті випадків надійніше зробити все самостійно:

1. Замініть ядро WordPress. Подивіться свою версію в розділі «Консоль» → «Оновлення», завантажте з wordpress.org архів тієї самої версії й розпакуйте його на комп'ютері. Далі у файловому менеджері хостингу видаліть каталоги wp-admin та wp-includes, завантажте на їхнє місце нові з архіву. Папку wp-content не чіпайте, адже там ваші зображення, теми й плагіни.
2. Перевірте файли в корені сайту. У чистому WordPress на моєму тестовому сайті файловий менеджер показав рівно 24 елементи разом із папками, і майже всі починаються з wp-, окрім index.php, xmlrpc.php, license.txt, readme.html та .htaccess. Хоча окремі плагіни теж інколи додають сюди свої дані, але загалом файл із випадковою назвою варто додатково перевірити. Окремо відкрийте wp-config.php: він має починатися з <?php та містити лише налаштування, без довгих незрозумілих рядків.
3. Перегенеруйте .htaccess. Найпростіший спосіб отримати чистий файл — видалити наявний та зайти в «Налаштування» → «Постійні посилання» → «Зберегти зміни». WordPress створить його заново. Перевірте також підкаталоги: копії .htaccess зі стороннім кодом часто лежать не лише в корені.
4. Перевстановіть плагіни й теми. Не намагайтеся очистити їхні файли вручну: видаліть плагіни повністю та встановіть заново з офіційного каталогу. Те, чим давно не користуєтеся, просто видаліть.

Особливу увагу зверніть на базу даних. Спочатку зробіть її копію через phpMyAdmin («Експорт» → «Вивести»), бо будь-яка помилка тут ламає сайт цілком. Потім скористайтеся пошуком по таблицях та перевірте фрагменти, які майже завжди означають стороннє втручання: <script, <iframe, eval(, base64_decode, gzinflate, а також незнайомі доменні імена. Дивіться передусім таблиці wp_posts, wp_options і wp_users. Якщо знайшли шкідливий код усередині вашої ж статті — видаляйте лише сам сторонній фрагмент, а не весь запис. Якщо не впевнені, що саме перед вами, краще нічого не чіпати й показати знахідку технічній підтримці.

Читайте також: Що таке база даних та для чого вона потрібна

Як закрити бекдори на сайті

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

Щоб знайти бекдори на сайті, виконайте наступні дії:

1. Перегляньте список користувачів у панелі керування та видаліть усіх адміністраторів, яких не впізнаєте.
2. Знайдіть файли, змінені за останні два тижні: у файловому менеджері хостингу відсортуйте вміст за датою зміни.
3. Пошукайте у файлах типові маркери прихованого коду: base64_decode, eval, gzinflate, str_rot13.
4. Перевірте, чи не з’явилися чужі карти сайту.
5. Відкрийте в Search Console розділ Settings → Users and permissions та видаліть власників і користувачів, яких ви не додавали.

Перший та останній пункти здаються надто очевидними, але в цьому й суть. Власники рідко перевіряють список адміністраторів та підтверджених власників у Search Console, а зловмисники саме на це й розраховують: доступ до вашого сайту в них залишається навіть тоді, коли всі файли вже чисті.

Як знайти й закрити вразливість на сайті

Почніть з перевірки плагінів та шаблонів. Відкрийте розділ «Плагіни» → «Встановлені», випишіть назви разом із номерами версій, те саме зробіть для тем у розділі «Зовнішній вигляд». Далі перевірте кожну назву в безкоштовних базах вразливостей:

• WPScan Vulnerability Database — найбільша база плагінів та шаблонів WordPress;
• Patchstack Database — зручний пошук з датами виявлення та статусом виправлення;
• Wordfence Intelligence — надає опис, у яких саме версіях проблему усунули.

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

Далі рішення залежить від знахідки:

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

Якщо ж у списку все чисто, причина лежить поза плагінами та темами. Найчастіші варіанти:

• вкрадений або підібраний пароль адміністратора, особливо якщо він повторювався на інших сервісах;
• заражений сусідній сайт на тому самому акаунті хостингу, звідки зловмисник перейшов до вашого;
• застаріла версія PHP, яку давно ніхто не оновлював.

Перші два випадки видно в логах доступу, третій перевіряється в панелі хостингу за хвилину.

Як відновити репутацію після зламу сайту

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

• Чи обов'язково взагалі когось повідомляти
• Чи всіх відвідувачів треба повідомляти
• Що і де писати після зламу сайту

Чи обов'язково взагалі когось повідомляти

Чинний Закон України «Про захист персональних даних» не містить прямого обов'язку повідомляти про витік за зразком європейського GDPR — жорсткого правила «72 години» в українському праві немає. Натомість закон встановлює загальний обов'язок захищати персональні дані, повідомляти Уповноваженого Верховної Ради з прав людини про обробку даних із підвищеним ризиком та інформувати саму людину про факт збору її даних.

Однак, якщо ваш сайт пропонує товари чи послуги мешканцям ЄС або відстежує їхню поведінку через аналітику та рекламні cookies, на вас поширюється GDPR незалежно від того, де зареєстрована компанія. Він вимагає повідомити наглядовий орган протягом 72 годин з моменту, коли ви дізналися про витік, а якщо ризик для людей високий — повідомити й самих постраждалих. Штрафи сягають 10 мільйонів євро або 2% світового річного обороту — залежно від того, яка сума більша.

Чи всіх відвідувачів треба повідомляти

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

Що і де писати після зламу сайту

Текст має відповідати на п'ять запитань у чіткому порядку: що сталося, які дані зачеплено, що ви вже зробили, що робити користувачу та куди звертатися з питаннями. Наприклад, для інтернет-магазину це може бути таке повідомлення:

«Шановні клієнти! 14 липня ми виявили несанкціонований доступ до нашого сайту. Зловмисник міг отримати імена, номери телефонів та електронні адреси, які ви вказували під час оформлення замовлення. Дані платіжних карток на сайті не зберігаються, тому вони не постраждали.

Ми вже закрили вразливість, очистили сайт, змінили всі паролі та передали логи хостинг-провайдеру для перевірки.

Радимо змінити пароль, якщо ви використовували такий самий на інших сервісах, і не переходити за посиланнями з листів, які нібито надійшли від нашого магазину.

Питання — на пошту support@example.com або за телефоном. Ми оновлюватимемо цю сторінку в міру з'ясування деталей».

Розмістіть повідомлення помітним банером або окремою сторінкою на сайті, надішліть прямі листи постраждалим, а в соцмережах опублікуйте короткий пост із посиланням на повну версію.

Як відновити SEO після зламу сайту

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

• Як зняти попередження Google
• Як прибрати спам-сторінки з індексу
• Скільки триває відновлення позицій

Як зняти попередження Google

Спочатку переконайтеся, що сайт повністю очищений та вразливість закрита. Google прямо попереджає: запит, надісланий до того, як проблему усунули, подовжує розгляд наступного, а веб-ресурс може отримати позначку повторного порушника.

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

1. Відкрийте «Безпека та заходи, вжиті вручну» → «Проблеми безпеки» та перегляньте всі виявлені проблеми й приклади URL.
2. Натисніть Request a Review та опишіть окремо по кожному типу проблеми, що саме ви знайшли та як виправили. Хороший запит відповідає на три питання: у чому полягала проблема, які кроки ви зробили та який результат отримали.
3. Дочекайтеся відповіді, не надсилаючи повторних запитів. Перевірка фішингових сторінок займає близько доби, зараження шкідливим кодом — кілька днів, а спам-злам може розглядатися кілька тижнів, бо потребує ручного аналізу.

Ось як може виглядати текст запиту:

«У розділі "Проблеми безпеки" було зафіксовано вставлений спам-контент. Ми виявили, що зловмисник отримав доступ через застарілу версію плагіна [назва], та згенерував 340 сторінок з фармацевтичними ключовими словами в каталозі /wp-content/uploads/.

Що зроблено: плагін видалено та замінено, каталоги wp-admin і wp-includes замінено чистими копіями офіційної збірки, знайдено й видалено два прихованих файли з бекдорами, змінено всі паролі та ключі автентифікації, видалено трьох невідомих адміністраторів.

Результат: усі 340 спам-сторінок віддають код 410, повторне сканування Wordfence і Sucuri SiteCheck не виявляє заражень, автоматичні оновлення увімкнено».

Якщо сайт потрапив до інших чорних списків, враховуючи McAfee, Norton та Bing, подайте окремі запити на перегляд у кожному з них.

Як прибрати спам-сторінки з індексу

1. Видаліть усі спам-адреси та переконайтеся, що вони віддають код 404 або 410. Статус 410 Gone прямо каже пошуковику, що сторінка видалена назавжди, тому індекс очищається швидше. Налаштувати його можна через SEO-плагіни, наприклад, Rank Math.
2. Для термінового приховування скористайтеся інструментом Removals у Search Console — він тимчасово прибирає адреси з видачі, поки Google переобходить веб-ресурс.
3. Приберіть чужі файли карти сайту, які міг додати зловмисник, і ще раз перевірте список власників ресурсу в Search Console.
4. Не надсилайте запит на індексацію кожної адреси вручну. Дайте Google переобійти сайт природно, а через URL Inspection перевіряйте лише пріоритетні сторінки.
5. Якщо видалені спам-сторінки встигли зібрати трафік або зворотні посилання, налаштуйте 301 редиректи на релевантні легітимні сторінки.

Читайте також: Основні відмінності редиректів 301 і 302

Скільки триває відновлення позицій

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

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

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

Найкращий план відновлення — той, яким ви більше ніколи не скористаєтеся. Але статистика тут невтішна: ще у 2016 році Google повідомляв, що 12% очищених сайтів зламують повторно протягом 30 днів. Саме тому, що власники усунули наслідки, але не знайшли справжню причину.

Тож після відновлення варто закріпити кілька постійних правил:

• оновлюйте ядро, плагіни й теми щотижня, а критичні оновлення безпеки встановлюйте одразу, не відкладаючи;
• тримайте мінімально необхідний набір розширень: кожен зайвий плагін — це ще одна потенційна вразливість;
• залиште увімкненою двофакторну аутентифікацію та щомісяця переглядайте список адміністраторів сайту й користувачів у Search Console;
• перевірте, що автоматичні резервні копії створюються, зберігаються поза сервером сайту й мають глибину щонайменше 30 днів — саме глибина рятує, коли злам помічають із запізненням, бо свіжі копії можуть вже містити зараження;
• тримайте активним захисний екран, який блокує атаки до того, як вони дістануться сайту. У безкоштовній версії Wordfence він працює, але нові правила надходять із затримкою на 30 днів, тож для сайтів з оплатами варто обирати платні рішення.

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

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