# Новые требования Google к back button hijacking: чек-лист для сайта до 15 июня 2026
13 апреля 2026 года Google Search Central объявил, что практика back button hijacking станет явным нарушением spam policies, а применять меры начнут 15 июня 2026 года. Для владельцев сайтов это не абстрактная новость про SEO-правила, а вполне прикладной сигнал: нужно проверить, не ломают ли старые скрипты, рекламные вставки, виджеты или кастомный JavaScript нормальную работу кнопки «Назад».
Если сайт мешает пользователю вернуться на предыдущую страницу и вместо этого подсовывает лишний экран, рекламу, промежуточный редирект или повторный заход в тот же сценарий, Google теперь рассматривает это как отдельную проблему качества. Последствия могут быть не только поведенческими, но и поисковыми: от просадки доверия пользователей до manual action или автоматических понижений.
Что именно изменилось
Раньше такие сценарии тоже считались плохой практикой, но теперь Google сделал их явной частью политики против malicious practices. В официальном сообщении Google прямо указал, что back button hijacking мешает базовой навигации браузера, нарушает ожидания пользователя и создает обманчивый опыт. Кроме того, сайтам дали конкретный срок на исправление: до 15.06.2026.
Для бизнеса это важный нюанс. Когда нарушение сформулировано явно, его проще проверять вручную, проще находить при аудите и проще связывать с падением качества трафика. Особенно это касается проектов, где за годы накопились рекламные интеграции, нестандартные формы, старые партнерские скрипты, мобильные webview-сценарии и самописные посадочные страницы.
Что такое back button hijacking простыми словами
Пользователь открывает страницу из поиска, читает материал или смотрит товар, нажимает кнопку «Назад» и ожидает вернуться в выдачу или на предыдущую страницу. Вместо этого сайт:
- подсовывает дополнительный экран;
- открывает нежелательный оффер;
- возвращает человека в тот же сценарий через историю браузера;
- отправляет на страницу, которой в обычной навигации не было.
Именно это Google считает манипуляцией пользовательским ожиданием.
Важно не перепутать проблему с нормальной работой SPA-приложений. Сам по себе `History API` не является нарушением. MDN напоминает, что `pushState()` добавляет запись в историю сессии, а `replaceState()` обновляет текущую запись. Нарушением становится не сам инструмент, а его обманное применение, когда история меняется ради ловушки, а не ради нормального маршрута пользователя.
Где проблема чаще всего появляется на рабочих проектах
1. Рекламные и партнерские скрипты
Часто владелец сайта уверен, что «ничего такого не внедрял», но проблема приходит вместе с внешним кодом. Это могут быть popunder-механики, агрессивные партнерские сети, сомнительные recommendation-виджеты, скрипты монетизации или зараженные вставки после взлома. Google отдельно предупредил, что back button hijacking может идти из библиотек и рекламных платформ, подключенных к сайту.
2. Лендинги с навязчивыми промежуточными шагами
Иногда маркетинговая команда или подрядчик добавляет дополнительные экраны: «подождите, у нас есть спецпредложение», «вы точно хотите уйти», «получите бонус перед выходом». Пока это обычный блок на странице, проблем меньше. Но когда сценарий начинает вмешиваться в историю браузера и ломает кнопку «Назад», риск уже технический и поисковый.
3. Legacy JavaScript после многолетних доработок
На старых сайтах часто остается код, про который никто уже не помнит: антибот-защита, exit intent, старый A/B тест, самописный роутинг, эксперименты с модальными окнами, куски отключенных интеграций. Визуально все может выглядеть терпимо, но в мобильном браузере пользователь получает совсем другой путь, чем планировалось.
4. Личные кабинеты и SPA-интерфейсы
В сложных интерфейсах проблема возникает тоньше. Команда меняет поведение истории ради удобства, но не тестирует реальные возвраты назад: после авторизации, после формы, после фильтра, после открытия карточки, после платежного шага. В итоге back stack разрастается искусственно, а человек не может быстро вернуться в выдачу, каталог или предыдущий раздел.
Что проверить на сайте до 15 июня 2026
Проверить реальные входы из поиска
Нужно пройти руками основные посадочные страницы: услуги, блог, карточки каталога, формы заявки, мобильные сценарии. Важен именно пользовательский путь: открыли страницу, сделали 1-2 действия, нажали «Назад», посмотрели, куда попадаем.
Посмотреть подключенные внешние скрипты
Если на сайте есть рекламные сети, партнерские виджеты, сторонние recommendation-блоки, JS из tag manager или старые счетчики, их стоит проверить отдельно. Особенно если жалобы появляются только на мобильных устройствах или только на части трафика.
Проверить History API и клиентский роутинг
Если проект на Next.js, React, Vue, Angular или на самописном фронтенде, стоит посмотреть, где именно вызываются `pushState`, `replaceState`, кастомные редиректы и обработчики `popstate`. Нормальный роутинг допустим, а искусственное наращивание истории ради удержания пользователя уже нет.
Сравнить поведение после форм и критичных шагов
Отдельно надо пройти сценарии после открытия модального окна, старта формы, логина, фильтрации, перехода к оплате и возврата из webview. Именно там чаще всего всплывают ошибки, которых нет в базовом smoke-test.
Проверить Search Console, если риск уже реализовался
Если сайт уже попал под manual action, Google рекомендует сначала убрать нарушение, а затем отправить Request Review в отчете Manual Actions. Это значит, что исправление должно быть реальным: удалить источник проблемы, перепроверить сценарии и только потом просить пересмотр.
Как исправлять без лишнего риска
Первый принцип: не лечить симптом, а найти источник. Если проблема в рекламном коде, не надо просто прятать блок визуально. Если проблема в старом JS, не надо добавлять поверх него еще один костыль. Нужна понятная цепочка:
- воспроизвести сценарий;
- понять, какой скрипт меняет историю или делает обманный редирект;
- отключить или заменить источник;
- заново пройти путь на desktop и mobile;
- проверить, не сломались ли аналитика, формы и внутренний роутинг.
На коммерческих сайтах особенно важно не переусердствовать. Иногда после быстрой правки ломается нормальная логика каталога, возврат в фильтр, переходы в личном кабинете или шаги checkout. Поэтому исправление лучше делать как техническую задачу с ручным тестом ключевых сценариев, а не как «попробуем удалить пару строк и посмотрим».
Почему это вопрос не только SEO
Back button hijacking бьет сразу по нескольким слоям проекта:
- по доверию пользователя, потому что сайт ведет себя как ловушка;
- по конверсии, потому что раздраженный посетитель чаще уходит совсем;
- по поддержке, потому что плавающие JS-проблемы сложнее диагностировать;
- по аналитике, потому что искусственные шаги искажают реальную воронку;
- по поиску, потому что Google теперь отдельно обозначил такую практику как нарушение.
Для бизнеса это типичный пример задачи на стыке поддержки, безопасности, фронтенда и технического SEO. Ее редко решает один человек «по памяти». Обычно нужен быстрый аудит сценариев, ревизия сторонних подключений и аккуратная доработка без потери рабочих конверсий.
Когда стоит заказывать технический аудит
Аудит нужен не только после санкций. Лучше проверять заранее, если:
- сайт давно живет на legacy-коде;
- есть несколько подрядчиков в истории проекта;
- подключались рекламные или партнерские скрипты;
- на мобильных есть странные возвраты назад;
- после SEO- или рекламных экспериментов упало качество трафика;
- пользователи жалуются, что сайт «не отпускает» назад.
Если у проекта есть личный кабинет, сложные формы, SPA-роутинг, webview внутри мобильного приложения или старая интеграция tag manager, такая проверка особенно оправдана. Здесь легко пропустить проблему на уровне одного сценария и долго искать причину по косвенным метрикам.
Официальные источники, на которые стоит опираться
- Google Search Central, публикация от 13 апреля 2026: back button hijacking становится явным нарушением, а enforcement начнется 15 июня 2026.
- Google Search Essentials / Spam Policies: раздел про malicious practices и общие последствия нарушений для видимости сайта.
- Search Console Help: Manual Actions report: рекомендации по Request Review после исправления manual action.
- MDN Web Docs: Working with the History API: описание `History API`, чтобы отличать нормальный роутинг от манипуляции историей браузера.
Вывод
До 15 июня 2026 года у владельцев сайтов есть короткое окно, чтобы проверить критичные страницы и убрать сценарии, которые мешают пользователю нормально пользоваться кнопкой «Назад». Для новых проектов это обычно одна задача на ревизию фронтенда и сторонних скриптов. Для старых рабочих сайтов это уже полноценная проверка качества поддержки.
Если на проекте есть легаси JavaScript, внешние рекламные подключения, личный кабинет, формы заявки или нестандартный роутинг, безопаснее пройти такой аудит заранее. Это дешевле, чем потом одновременно разбирать жалобы пользователей, падение конверсии и возможные вопросы со стороны Google Search.