History Hijacking: Чому Google карає за «зламану» кнопку Назад і як захистити сайт за допомогою CSP

Кожен власник сайту та SEO-спеціаліст веде щоденну запеклу боротьбу за утримання користувача на сторінках вебресурсу. Проте, коли в хід йдуть деструктивні технічні маніпуляції, під удар потрапляє не лише користувацький досвід (UX), а й репутація домену в пошукових системах. Один із найсерйозніших технічних гріхів, за який вебресурс може миттєво втратити весь органічний трафік і вилетіти з топів Google — це History Hijacking (несанкціоноване перехоплення або крадіжка історії браузера).

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

1. Глибокий технічний аналіз: як працює перехоплення історії

Сучасні стандарти веб-розробки надають програмістам колосальну гнучкість для керування сесіями та переходами без перезавантаження сторінок за допомогою HTML5 History API. Цей інструментарій є незамінним при створенні сучасних Single Page Applications (SPA) на базі Vue, Nuxt.js, React чи Angular, а також при реалізації динамічних AJAX-фільтрів в інтернет-магазинах на OpenCart чи WordPress. Для керування стеком історії використовуються три основні інструменти об’єкта window.history:

• history.pushState(state, title, url) — додає абсолютно новий запис у стек історії браузера.
• history.replaceState(state, title, url) — модифікує поточний запис у стеку історії без додавання нового кроку.
• Подія popstate — викликається операційною системою браузера кожного разу, коли користувач здійснює навігаційну дію по історії (натискає кнопку «Назад» або «Вперед»).

При нормальній роботі ці інструменти допомагають змінювати URL в адресному рядку без перезавантаження сторінки. Але при зловживанні скрипти починають агресивно «спамити» у стек історії фейковими записами.

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

Шкідливі або некоректно налаштовані рекламні скрипти використовують метод pushState() як зброю проти UX. Як тільки користувач потрапляє на сторінку, такий скрипт програмно виконує серію циклічних викликів window.history.pushState(), штучно заповнюючи стек історії браузера дублікатами поточної сторінки або проміжними редиректами. Коли людина намагається вийти і натискає кнопку «Назад», браузер чесно виконує команду і повертається на один крок назад у стеку історії. Але оскільки попереднім кроком є точно такий самий штучно згенерований стан вашої ж сторінки, користувач візуально залишається на місці.

Для того, щоб дійсно повернутися в пошукову видачу Google, бідному відвідувачу доводиться судорожно клацати по кнопці «Назад» десятки разів поспіль, намагаючись випередити швидкість виконання циклів JavaScript, або затискати кнопку миші для виклику контекстного меню історії та примусового вибору попереднього сайту.

2. Позиція Google: офіційні санкції та ручні заходи

Пошуковий гігант Google веде безкомпромісну війну за чистоту видачі та якість користувацького досвіду. Перехоплення кнопки «Назад» чітко класифікується офіційним документом правил Google Search Essentials (колишні Webmaster Guidelines) як грубе порушення в розрізі «Оманливих дій» (Deceptive practices) та «Прихованих перенаправлень» (Sneaky redirects).

Алгоритми Googlebot, що працюють у сучасних ізольованих пісочницях на базі двигуна Chromium, миттєво розпізнають аномальну поведінку коду:

1. Робот аналізує активність об’єкта window.history та фіксує виклики pushState(), які відбуваються без прямої взаємодії з користувачем (без так званого тригера User Activation, наприклад, кліку чи натискання клавіші).
2. Система збирає реальні телеметричні дані користувачів браузера Chrome за допомогою звітів Chrome User Experience Report (CrUX). Спроби блокування події popstate або ланцюжки редиректів при виході з сайту чітко сигналізують алгоритмам про наявність проблеми.

Яке покарання загрожує сайту? Вебресурс гарантовано отримує Manual Action (ручні санкції) від команди модерації Google Webmaster Tools. У панелі Search Console з’являється сповіщення про порушення безпеки або спам. Наслідки є катастрофічними: повне виключення домену з індексу Google або критичне падіння позицій за всіма ключовими запитами на 50-90 пунктів вниз. Процес виходу з-під таких санкцій після виправлення коду може тривати від кількох місяців до півроку.

3. Ненавмисний факап: як чисті сайти стають порушниками

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

• Тизерні та банерні рекламні мережі: Ви підключаєте нативний рекламний блок від маловідомої або сірої тизерної мережі. Ротатор банерів на стороні їхнього сервера в якийсь момент пропускає обфускований шкідливий JS-код від недобросовісного рекламодавця. Цей код виконується на вашому сайті, перехоплює історію і при спробі виходу перенаправляє користувача на платні підписки або дейтинг-платформи.
• Помилки в роутингу Single Page Applications: При самостійній розробці на Nuxt 4 або React з використанням динамічних параметрів фільтрації (наприклад, /category?price=from-100) розробники часто помилково використовують метод роутера router.push() замість router.replace(). В результаті кожна зміна повзунка ціни засмічує історію, і користувач не може вийти назад.
• Агресивні маркетинг-віджети: Скрипти онлайн-чатів, лідогенераторів або систем зворотного дзвінка з логікою Exit Intent (фіксація наміру залишити сайт) намагаються утримати клієнта будь-якою ціною. Якщо код написаний неякісно, спроба перехопити рух курсора до верхньої панелі браузера ламає нормальну обробку черги історії.

4. Як перевірити свій сайт на наявність History Hijacking

Оскільки шкідливі скрипти вміють маскуватися (не спрацьовують для авторизованих адмінів, перевіряють IP-адреси або запускаються виключно на мобільних пристроях), звичайна перевірка не допоможе. Потрібен ретельний технічний аудит:

Код для ручного тестування в консолі розробника

Відкрийте ваш сайт, натисніть клавішу F12 і перейдіть на вкладку Console. Введіть наступний JavaScript-код, який допоможе відстежити приховані маніпуляції зі стеком історії:

(function() {
    const originalPushState = history.pushState;
    history.pushState = function(state, title, url) {
        console.warn('Увага! Скрипт викликав pushState без переходу. Створено новий запис історії:', url);
        return originalPushState.apply(this, arguments);
    };
    console.log('Моніторинг History API успішно активовано. Слідкуйте за попередженнями...');
})();

5. Головна зброя захисту: конфігурація заголовків Content Security Policy (CSP)

Єдиним надійним технічним способом захистити свій сайт від несанкціонованого виконання сторонніх шкідливих скриптів, які ламають кнопку Назад, є впровадження жорсткої політики Content Security Policy (CSP). CSP — це спеціальний HTTP-заголовок відповіді сервера, який чітко вказує браузеру користувача, з яких саме доменів і джерел дозволено завантажувати та виконувати JavaScript-код, стилі, зображення та фрейми.

Нижче наведено готові практичні приклади конфігурації CSP для різних рівнів серверної архітектури вебресурсу.

Варіант А: Налаштування на рівні веб-сервера Nginx

Якщо ви адмініструєте власний сервер на базі Ubuntu та керуєте сайтом напряму або через панелі типу DirectAdmin, додайте наступну конфігурацію в блок server { ... } вашого конфігураційного файлу Nginx (зазвичай знаходиться за шляхом /etc/nginx/sites-available/):

# Додавання заголовка Content Security Policy в Nginx
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https://www.google-analytics.com https://ssl.google-analytics.com; object-src 'none'; base-uri 'self'; frame-ancestors 'none';" always;

Варіант Б: Налаштування для серверів Apache (через файл .htaccess)

Якщо ваш сайт працює на класичному хостингу або локальному середовищі WampServer/Laragon під керуванням Apache, додайте ці рядки в самий початок кореневого файлу .htaccess вашого WordPress або OpenCart сайту:

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https://www.google-analytics.com; object-src 'none'; base-uri 'self';"
</IfModule>

Варіант В: Динамічне впровадження через PHP / WordPress (функції теми)

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

function sebweo_send_csp_headers() {
    if (!is_admin()) {
        // Формуємо рядок політики безпеки
        $csp_policy = "default-src 'self'; " .
                      "script-src 'self' 'unsafe-inline' https://www.googletagmanager.com https://www.google-analytics.com; " .
                      "style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; " .
                      "font-src 'self' https://fonts.gstatic.com; " .
                      "img-src 'self' data: https://*.wp.com; " .
                      "frame-src 'none'; " .
                      "object-src 'none';";        
        header("Content-Security-Policy: " . $csp_policy);
    }
}
add_action('send_headers', 'sebweo_send_csp_headers');

Розбір директив CSP, використаних у прикладах:

• default-src 'self' — за замовчуванням дозволяє завантаження будь-яких типів контенту (скрипти, стилі, картинки) виключно з вашого власного домену.
• script-src 'self' 'unsafe-inline' ... — чітко обмежує виконання JavaScript. Дозволено лише власні файли, інлайн-скрипти шаблону та коди метрики (в даних прикладах використовується Google Analytics). Будь-який сторонній лівий рекламний JS-код буде заблокований браузером до моменту його виконання.
• object-src 'none' — повністю забороняє застарілі технології Flash та Java-аплети, які часто є джерелом вразливостей.
• frame-src 'none' — забороняє завантаження сторонніх фреймів, запобігаючи прихованим клікджекінг-атакам.

Особливий кейс: реклама Google AdSense та хеш #google_vignette в адресному рядку

Багато вебмайстрів, помітивши, що після показу або закриття повноекранної реклами (Vignette Ads) від Google AdSense в URL сайту додається суфікс #google_vignette, починають панікувати. Адже візуально сценарій виглядає загрозливо: користувач натискає кнопку «Назад», але замість виходу з сайту просто повертається на ту саму сторінку, з якої зникає цей самий хеш #google_vignette.

Виникає логічне питання: Чи вважає сам Google таку поведінку порушенням і чи загрожують за це санкції?

Як це працює з технічної точки зору?

Коли на сайті з’являється міжсторінкова реклама AdSense, скрипти Google використовують стандартний механізм браузера для роботи з якорями (hashes). Додавання хешу #google_vignette в адресний рядок автоматично створює новий запис у стеку історії браузера (Browser History Stack).

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

Чи карає Google за свій же скрипт?

Ні, за Google AdSense штрафів чи санкцій не буде. І ось чому:

1. Легітимність джерела. Скрипти AdSense є частиною екосистеми Google. Алгоритми Googlebot та системи оцінки якості пошуку чітко розрізняють маніпулятивні скрипти сторонніх «сірих» мереж і офіційні рекламні продукти компанії.
2. Взаємодія з користувачем (User Activation). На відміну від класичного History Hijacking, де стек забивається таємно і примусово за допомогою циклів pushState одразу при вході, у випадку з віньєтками AdSense зміна URL відбувається у відповідь на дію користувача (клік по лінку, закриття вікна чи очікування завантаження переходу).
3. Передбачуваність для Chrome. Браузер Google Chrome та алгоритми Core Web Vitals нативно навчені ігнорувати внутрішні технічні ідентифікатори AdSense (такі як google_vignette або gclid) при розрахунку метрик блокування навігації.

Коли це все ж таки може стати проблемою?

Хоча сам по собі #google_vignette є безпечним для SEO, проблеми можуть виникнути, якщо на сайті паралельно працюють інші кастомні JS-скрипти.

Наприклад, якщо ваш SPA-роутер (на Nuxt чи React) або плагін для гладкого скролу (Smooth Scroll) налаштований так, що він панічно реагує на будь-яку зміну хешу в URL й намагається програмно «перебити» її своїм викликом history.pushState() або replaceState(). У такому випадку виникає конфлікт скриптів: Google додає свій хеш, ваш сайт намагається його очистити або обробити, і стек історії зациклюється вже по-справжньому.

Резюме для кейсу: Поява #google_vignette та необхідність подвійного кліку на кнопку «Назад» для виходу з сайту після перегляду офіційної реклами Google — це легальна технічна особливість роботи платформи AdSense. Вона не є порушенням правил Google Search Essentials і не призведе до ручних санкцій. Проте вебмайстру варто стежити, щоб кастомні скрипти сайту не вступали в конфлікт із цим хешем.

Замість висновку