Після злому сайту технічна команда часто зосереджується на очевидному: видалити шкідливий код, закрити вразливість, змінити доступи й повернути сайт у робочий стан. Але для SEO цього недостатньо. Якщо зловмисники встигли створити спам-сторінки, додати приховані посилання або налаштувати шкідливі редиректи, частина цього контенту може залишатися в пошуковій видачі навіть після очищення сервера.
Google класифікує контент, доданий на сайт без дозволу через уразливість, як hacked content. Для бізнесу проблема не лише в технічному інциденті: користувачі можуть бачити в пошуку сторінки з нерелевантними або компрометуючими запитами, а пошукові системи — продовжувати обходити URL, яких уже не має бути. Тому відновлення SEO після злому — це окремий післяаварійний процес: інвентаризація заражених URL, правильні HTTP-відповіді, тимчасове приховання критичного контенту в Search Console, оновлення sitemap і фінальний запит на перевірку в Security Issues report.
Як зловмисники ламають індекс: cloaking, content injection і page injection
Перший крок — зрозуміти, що саме потрапило в індекс. Google описує кілька типових сценаріїв hacked content. Один із них — content injection: зловмисник додає до легітимних сторінок прихований текст або посилання, які можуть бути видимими для пошукових систем, але непомітними для звичайного користувача. Інший сценарій — page injection, коли на скомпрометованому сайті створюються нові spam-сторінки.
Окрема небезпека — cloaking. У цьому випадку сайт може показувати різний контент різним аудиторіям: власник або звичайний відвідувач бачить нормальну сторінку, а Googlebot або користувач із пошукового переходу — спам, редирект чи інший шкідливий сценарій. Саме тому перевірка лише через браузер адміністратора не є достатньою.
Типові ознаки, які варто шукати після інциденту:
- у видачі з’явилися URL за запитами, що не стосуються бізнесу, наприклад казино, фармація або інші спам-теми;
- у шаблонах, базі даних або контентних блоках є прихований текст чи зовнішні посилання;
- редиректи спрацьовують вибірково — лише для певних user-agent, реферерів із пошукових систем або частини відвідувачів;
- у логах сервера є запити до URL, яких не створювала редакційна або продуктова команда.
Важливо не обмежуватися списком у Security Issues report. Google прямо зазначає, що перелік URL у цьому звіті є прикладом і може не охоплювати всі уражені сторінки. Тому звіт Search Console — це стартова точка, а не повний аудит.
Інвентаризація URL: що зібрати перед деіндексацією
Перед налаштуванням статусів і подачею запитів у Search Console варто зібрати робочий реєстр уражених адрес. У ньому корисно розділити URL на три групи:
- легітимні сторінки, у які було додано прихований або шкідливий контент;
- штучно створені спам-сторінки, яких ніколи не мало бути на сайті;
- URL із підозрілими редиректами або нестабільною поведінкою для різних user-agent.
Для цього використовуйте дані Search Console, серверні логи, CMS, бази даних, файлової структури та власного сканування сайту. Мета — не просто видалити знайдені файли, а зрозуміти, які адреси вже бачив Googlebot і які адреси можуть залишатися в індексі після очищення.
404 чи 410: як не перетворити очищення на нову SEO-помилку
Після видалення спам-контенту кожен URL має повертати коректну відповідь. Якщо сторінка легітимна й очищена, вона має працювати як нормальна сторінка. Якщо адреса була створена зловмисниками й більше не повинна існувати, сервер не має віддавати для неї успішний код 200.
Для видалених сторінок зазвичай використовують 404 Not Found або 410 Gone. Практична різниця така: 404 повідомляє, що сторінку не знайдено, а 410 чіткіше сигналізує, що ресурс видалено. Для масиву URL, створених саме внаслідок page injection, 410 доречний тоді, коли команда впевнена: ці адреси не є частиною нормальної структури сайту й не мають повертатися.
Не варто масово перенаправляти спам-URL на головну сторінку. Такий редирект не розв’язує проблему hacked content: користувач і робот отримують нерелевантну відповідь, а сайт змішує легітимну головну сторінку зі слідами спам-інциденту. Якщо релевантної заміни немає, краще віддати чесний статус видалення, ніж приховувати проблему редиректом.
| Метод | Коли застосовувати | Ризик помилки |
|---|---|---|
| 404 Not Found | Для сторінок, які не знайдено або які могли зникнути не через спам-ін’єкцію. | Не пояснює, чи видалення остаточне. |
| 410 Gone | Для URL, створених зловмисниками, якщо вони точно не мають існувати надалі. | Не слід застосовувати до сторінок, які бізнес може відновити. |
| 301 на релевантну сторінку | Лише якщо є справді релевантна, легітимна заміна. | Масовий редирект на головну створює нерелевантний сигнал. |
| Search Console Removals | Для термінового приховання найкритичніших URL у видачі. | Не замінює очищення сервера й коректні HTTP-статуси. |
Removals у Search Console: екстрений інструмент, а не основне лікування
Інструмент Removals у Search Console варто використовувати для найшкідливіших випадків: коли в пошуку вже видно компрометуючі сторінки, брендові запити ведуть на спам або URL містять контент, який потрібно швидко прибрати з очей користувачів. Але це не заміна технічного очищення.
Перед подачею запиту перевірте три речі:
- URL справді належить до спам-інциденту, а не до легітимного розділу сайту;
- на сервері вже видалено шкідливий контент, скрипти, шаблони або записи бази даних, які його генерували;
- адреса повертає коректний статус або веде на справді релевантну сторінку, якщо редирект обґрунтований.
Не подавайте масове видалення за широким префіксом, якщо в ньому змішані спам-URL і корисні сторінки. У такій ситуації краще працювати з точнішим списком адрес, щоб не прибрати з видачі власний легітимний контент.
Sitemap після злому: показати Google чисту структуру сайту
Після інциденту sitemap має виконувати просту роль: показувати пошуковій системі актуальну, чисту структуру сайту. У стандартний sitemap.xml не слід додавати URL, які були створені зловмисниками, сторінки з помилками, редиректи без потреби або адреси, що повертають 404/410. У ньому мають залишитися лише легітимні сторінки, які компанія хоче бачити в індексі.
Практичний порядок дій:
- перегенеруйте основний sitemap після очищення CMS, шаблонів і бази даних;
- переконайтеся, що всі URL у sitemap відкриваються без спаму, прихованих посилань і небажаних редиректів;
- видаліть із sitemap адреси, створені під час атаки;
- надішліть оновлений sitemap у Search Console;
- порівнюйте індексовані URL із власним реєстром заражених адрес і продовжуйте обробляти залишки.
Не варто обіцяти конкретний строк повторної індексації. Відновлення після злому є багатокроковим процесом без фіксованого таймлайну: швидкість залежить від масштабу інциденту, частоти обходу сайту, якості очищення й того, чи не з’являються нові ознаки компрометації.
Security Issues report: як подати запит на перевірку
Коли сервер очищено, уражені URL оброблено, sitemap оновлено, а критичні сторінки за потреби приховано через Removals, можна переходити до запиту на перевірку в Security Issues report. У запиті важливо описати не загальні наміри, а виконані дії.
Що варто зафіксувати в описі:
- який тип hacked content було виявлено: content injection, page injection, cloaking або шкідливі редиректи;
- які вразливості або канали доступу усунуто;
- як очищено шаблони, базу даних, файли, плагіни або інші компоненти сайту;
- як оброблено спам-URL: статуси 404/410, релевантні редиректи там, де вони справді доречні, Removals для критичних адрес;
- як команда перевірила, що список зі звіту Search Console не був єдиним джерелом аудиту.
Якщо Google показує у звіті лише кілька прикладів, не сприймайте це як підтвердження, що інших уражених URL немає. За даними Google, список у Security Issues report є ілюстративним. Саме тому якісний власний аудит логів і контенту має бути частиною відновлення.
Контрольний список для SEO-відновлення після злому
- Підтвердити, що вразливість усунено, доступи змінено, а шкідливий код видалено.
- Зібрати повний список підозрілих URL із Search Console, логів, CMS, бази даних і ручного сканування.
- Розділити URL на легітимні очищені сторінки, спам-сторінки та сторінки з підозрілими редиректами.
- Для сторінок, створених зловмисниками, налаштувати коректне видалення: 404 або 410 залежно від ситуації.
- Не робити масовий 301-редирект спам-URL на головну.
- Використати Removals лише для термінового приховання найкритичніших адрес.
- Перегенерувати sitemap так, щоб він містив тільки чисті легітимні URL.
- Подати запит на перевірку в Security Issues report із чітким описом виконаних робіт.
- Моніторити індекс, логи й нові приклади hacked content до стабілізації.
Enterprise-контекст: як зменшити ризик повторення
SEO-відновлення після злому — це завдання вебмайстрів, SEO-фахівців і системних адміністраторів. Але причина інциденту часто лежить глибше: у застарілій архітектурі, надмірних правах доступу, слабкому аудиті змін або неконтрольованих інтеграціях. Для enterprise-систем важливо не лише прибрати наслідки, а й зменшити ймовірність повторної content injection або несанкціонованої зміни файлової структури.
У цьому контексті команда Softengi, член альянсу Intecracy Group, може бути залучена до проєктування та розробки кастомних enterprise-рішень із фокусом на безпечну архітектуру, контроль доступу й аудит змін. Для відповідних сценаріїв Intecracy Group також використовує платформні підходи на кшталт UnityBase, зокрема механізми Domain metadata, generated API, RBAC/RLS і audit trail. Це не замінює операційне SEO-відновлення після інциденту, але допомагає будувати системи, у яких зміни даних, контенту й доступів краще контрольовані на архітектурному рівні.
Поширені питання
Як швидко Google прибере спам-сторінки після налаштування 410?
Фіксованого строку немає. Відновлення після злому є багатокроковим процесом: Google має повторно обійти URL, побачити коректні відповіді сервера й переоцінити стан сайту. Не варто планувати відновлення позицій за конкретною датою.
Чи можна зробити 301-редирект усіх спам-сторінок на головну?
Ні, це погана практика. Якщо спам-URL не має релевантної легітимної заміни, масовий редирект на головну лише приховує проблему й створює нерелевантний сигнал. Для адрес, створених зловмисниками, краще використовувати коректне видалення через 404 або 410.
Що робити, якщо Security Issues report показує лише частину зламаних URL?
Сприймайте цей список як приклад, а не як повний аудит. Google зазначає, що звіт може містити не всі уражені сторінки. Потрібно додатково перевірити серверні логи, CMS, базу даних, шаблони, sitemap і результати власного сканування сайту.
Джерела даних
- Google Search Central: Security issues report: hacked content
- Google Search Central: Spam policies: hacked content and cloaking
- ENISA Threat Landscape 2025
- Cisco Cybersecurity Readiness Index 2025
- NIST: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
- FCC First Caller ID Authentication Report and Order