Уявіть ситуацію: керівник відділу безпеки (CISO) або власник платформи отримує сповіщення від Google Search Console. Кількість індексованих сторінок корпоративного ресурсу раптово зросла з кількох сотень до десятків тисяч. У списку адрес з’являються шляхи з назвами медикаментів, казино або незрозумілими параметрами. Перша інстинктивна реакція — налаштувати масовий 301 редирект усіх невідомих URL на головну сторінку, щоб швидко «сховати» проблему та нібито врятувати SEO-показники.
Діяти без попереднього розслідування вкрай небезпечно. Згідно з даними Cisco Cybersecurity Readiness Index 2025, лише 27.7% організацій мають достатній рівень готовності до сучасних кіберзагроз, що часто призводить до хаотичних рішень під час реагування на інциденти. Зі свого боку, ENISA Threat Landscape 2025 констатує, що до 53.7% компрометацій відбуваються через експлуатацію вразливостей або архітектурних недоліків. Раптовий сплеск індексованих сторінок зазвичай вказує на масову автоматизовану ін'єкцію спаму. Однак перед початком «лікування» необхідно точно класифікувати аномалію, адже хибні дії з маршрутизацією можуть остаточно зруйнувати авторитет домену в пошукових системах.
Анатомія аномалії: чому Google Search Console раптово показує тисячі невідомих URL
Пошукові роботи постійно сканують мережу. Коли зловмисники отримують доступ до інфраструктури, вони часто намагаються монетизувати цей доступ найпростішим шляхом — експлуатуючи довіру пошукових систем до вашого домену. Вони впроваджують скрипти, які генерують тисячі оптимізованих під сірі ніші сторінок і спрямовують на них пошуковий трафік.
Проте не кожна тисяча невідомих URL означає компрометацію. Часто це наслідок технічного боргу або хибної конфігурації фільтрів на сайті. Якщо помилково сприйняти внутрішню архітектурну проблему за злам (або навпаки), можна заблокувати сканування легітимного контенту або залишити активним бекдор, який продовжуватиме генерувати спам-сторінки. Ручний аналіз логів сервера є обов'язковим етапом перед будь-якими змінами на рівні сервера чи CMS.
Тріада підозрюваних: як відрізнити Page Injection від Legacy 404 та Crawl Trap
Зіткнувшись із нетиповим масивом проіндексованих URL, інцидент слід класифікувати за однією з трьох категорій:
- Page Injection (Злам). Google класифікує контент, доданий без дозволу через вразливість сайту, як hacked content (зламаний контент). При page injection зловмисники створюють нові спам-сторінки на скомпрометованому сайті. Кількість таких URL зазвичай вимірюється тисячами, що свідчить про автоматизовану атаку. Ці сторінки можуть містити приховані посилання або текст (content injection), видимі для пошукових систем, але непомітні для звичайних відвідувачів.
- Legacy Technical Debt (Технічний борг). Це стосується застарілих структур URL, які більше не існують, але колись були частиною сайту (наприклад, до міграції системи). Зазвичай кількість таких сторінок вимірюється сотнями. Вони стабільно повертають стандартну помилку 404 і не містять ознак зловмисного коду.
- Parametric Crawl Trap (Параметрична пастка). Це проблема конфігурації веб-сервера або системи керування контентом (CMS). Некоректні фільтри, сортування товарів чи ідентифікатори сесій (session IDs) створюють для бота нескінченну кількість комбінацій URL. Googlebot безупинно сканує ці дублі. Кількість адрес може бути астрономічною, але вони ведуть на існуючий (проте задубльований) контент сайту.
Технологія маскування: як зловмисники використовують Cloaking та маніпуляції з User-Agent
Найскладніший аспект виявлення page injection — це використання хакерами клоакінгу (cloaking). Google Search Central визначає клоакінг як практику показу різного вмісту пошуковим системам і реальним користувачам для приховування спаму чи зламу.
Скрипти зловмисників аналізують HTTP-заголовки User-Agent та Referrer. Якщо сторінку відкриває адміністратор безпосередньо в браузері, сервер повертає стандартну помилку 404 (або м'яке перенаправлення), створюючи ілюзію, що все гаразд. Однак, якщо запит надходить від Googlebot або перехід здійснюється з пошукової видачі Google, сервер віддає згенерований спам-контент. Тому покладатися виключно на прямий перехід за посиланням не можна: необхідно завжди перевіряти URL-адреси саме так, як їх бачить пошуковий робот, використовуючи інструмент перевірки URL в Search Console або термінальні утиліти з підміною User-Agent.
Чому масовий редирект на головну — це помилка: правильна стратегія очищення індексу (404 vs 410)
Масове налаштування 301 редиректу всіх невідомих URL на головну сторінку — це найбільш руйнівний крок після інциденту. Google сприймає масові перенаправлення нерелевантних сторінок як Soft-404. Це не лише не передає авторитет сторінок, але й може бути розцінене як спроба маніпуляції пошуковою видачею, що призведе до додаткових санкцій. Крім того, редиректи заважають швидкому видаленню спаму з індексу.
Правильна стратегія базується на застосуванні диференційованих статусів відповідей сервера:
- Для адрес, згенерованих через page injection, сервер має повертати статус 410 (Gone). Цей код сигналізує пошуковому боту, що контент видалено остаточно, що значно прискорює деіндексацію.
- Для legacy 404 сторінок достатньо повернути звичайний код 404 Not Found, або ж точковий 301 редирект на справді релевантний новий контент (але не на загальну головну сторінку).
- У випадку crawl traps редиректи недоречні. Рішення полягає у правильному налаштуванні файлу robots.txt, використанні тегів canonical або блокуванні параметрів у налаштуваннях пошукових систем.
Аудит точок входу: де саме у системі ховається джерело генерації спам-сторінок
Після класифікації проблеми та видачі правильних HTTP-статусів настає етап усунення першопричини. Якщо це був злам, необхідно знайти вразливість — найчастіше це застарілі плагіни, некоректно налаштовані права доступу до бази даних або слабкі місця в кастомній логіці маршрутизації (роутингу).
Для запобігання подібним векторам атак архітектура корпоративних веб-платформ має спиратися на принципи Secure by Design. У межах послуг з кібербезпеки та безпечної розробки експертиза Softengi допомагає компаніям вибудовувати процеси Threat Modeling та Incident Response, що дозволяє вчасно локалізувати джерела ін'єкцій на рівні коду та конфігурацій.
Технологічним фундаментом для таких захищених систем часто стає платформа UnityBase (спільна розробка компаній Intecracy Group, де InBase виступає ключовим, але не єдиним розробником). Завдяки підходу Domain metadata платформа генерує REST API автоматично на основі моделі даних, що мінімізує людський фактор у написанні кастомних обробників маршрутів — типових мішеней для ін'єкцій. Для проєктів із підвищеними вимогами до безпеки офіційна документація UnityBase рекомендує Enterprise або Defence редакції, які забезпечують контроль доступу на рівні рядків (RLS) та ведуть глибокий аудиторський слід (Audit Trail). Це гарантує, що будь-яка несанкціонована спроба генерації чи зміни даних буде зафіксована та миттєво відстежена системою.
| Тип аномалії | Ознаки в логах та Search Console | Першопричина | Рекомендована дія |
|---|---|---|---|
| Page Injection (Злам) | Запити повертають 200 OK для Googlebot (клоакінг), але 404 для звичайних користувачів. | Компрометація CMS, ін'єкція коду або вразливість плагінів. | Видалення шкідливого коду, віддача коду 410 (Gone), очищення sitemap. |
| Legacy Technical Debt | Стабільні запити до старих URL, які раніше існували. Відсутність ознак клоакінгу. | Застаріла структура сайту, некоректна міграція. | Налаштування коректного 404 або 301 редиректу на релевантні нові сторінки. |
| Parametric Crawl Trap | Нескінченна генерація URL через комбінації фільтрів, сортувань або сесійних ID. | Помилка конфігурації веб-сервера або CMS. | Налаштування файлу robots.txt, використання тегів canonical та параметрів у Search Console. |
Поширені питання
Як перевірити, чи бачить Googlebot інший контент на моєму сайті, ніж звичайні користувачі?
Скористайтеся інструментом перевірки URL у Google Search Console або перевірте запит через термінал, підмінивши HTTP-заголовки User-Agent на ідентифікатор Googlebot, а Referrer на адресу пошукової системи. Якщо сервер повертає спам замість звичної помилки 404, сайт скомпрометовано за допомогою технології клоакінгу.
Чому не можна просто налаштувати 301 редирект для всіх невідомих URL на головну сторінку?
Пошукові системи розцінюють масові редиректи непов'язаних сторінок на головну як Soft-404. Це не передає вагу сторінок, заважає деіндексації спаму та може викликати санкції за маніпуляцію пошуковими алгоритмами.
Які інструменти допомагають виявити джерело ін'єкції сторінок у файловій системі чи базі даних?
Ефективним рішенням є ручний аналіз логів сервера на наявність аномальних POST-запитів, системи моніторингу цілісності файлів (FIM) та вбудовані механізми аудиту баз даних. Наприклад, корпоративні платформи на кшталт UnityBase мають вбудований Audit Trail (аудиторський слід), який фіксує всі зміни на рівні моделі даних.
Джерела даних
- Google Search Central: Spam policies: hacked content and cloaking
- Google Search Central: Security issues report: hacked content
- 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