Содержание
Краткое саммари
Скрытый редирект может срабатывать только на смартфонах, при переходе из поиска, из определенной сети или один раз для каждого посетителя. Проверьте сайт с реального телефона и в разных сетях, изучите Яндекс.Вебмастер, Google Search Console, Метрику, журналы сервера и подключенные скрипты. Перед очисткой сделайте рабочую резервную копию; после нее смените пароли и ключи, включите двухфакторную аутентификацию, обновите CMS и запросите повторную проверку.
Кому стоит прочитать статью: владельцам сайтов, веб-мастерам, SEO-специалистам, разработчикам и администраторам, которые заметили падение мобильного трафика, жалобы на переадресацию или предупреждение о заражении.
Редирект или переадресация посетителя на другую страницу — это нормально. Например, у сайта example.com может быть мобильная версия на субдомене m.example.com. Если пользователь на смартфоне перейдет на сайт example.com в выдаче, его автоматически перекинет на мобильную версию.
Но есть и другой вариант, когда из-за переадресации можно потерять мобильный трафик, получить санкции от поисковиков и выпасть из индекса. Разберем, почему так может произойти и как это исправить.
Когда мобильный редирект на сайте становится проблемой
Иногда такой редирект отправляет пользователей смартфонов не на мобильную версию того же сайта, а на другие URL — не те, которые он выбрал в выдаче. Такое может настроить сам владелец сайта, если продает трафик, а иногда это происходит без его ведома. Возможные причины разберем ниже.
Схема такая: в поиске пользователь видит example.com. На компьютере адрес открывается без изменений, а со смартфона происходит редирект на чужой сайт. Раньше эту схему часто называли WAP-click-редиректом. Теперь вредоносная переадресация чаще ведет на фишинговые формы, поддельные магазины, страницы подписок, загрузки приложений или мошенническую рекламу.
Пользователя может переправить на страницу с предложением обновить ПО, скачать антивирус или приложение для оптимизации смартфона, установить игру, подписаться на что-то платное, например, на гороскопы или эротический контент. Часто под этим скрываются программы для фишинга или другие, угрожающие безопасности конфиденциальных данных.
Скрытое перенаправление на сторонний ресурс относится к обманным переадресациям и нарушает правила Google в отношении спама. Яндекс также предупреждает владельцев о заражении и нарушениях в разделе безопасности Вебмастера.
Посетители теряют доверие к сайту, а проект — мобильный трафик и заказы. Поисковая система может показать предупреждение, понизить страницы или исключить их из поиска. Одного удаления видимого скрипта недостаточно: нужно закрыть источник заражения, проверить все версии страниц и затем запросить повторную проверку в панели веб-мастера.
FAQ по разделу
Любая переадресация вредна для SEO?
Нет, серверные 301 и 308 при переносе URL полезны, если ведут на равнозначную страницу. Опасен только скрытый или обманный редирект.
Почему проблема видна только части посетителей?
Код может учитывать устройство, источник перехода, IP-адрес, cookie, время и частоту визитов.
Может ли сайт пропасть из поиска?
Да, возможны предупреждения, снижение видимости и исключение зараженных URL до очистки и повторной проверки.
Причины появления скрытого редиректа
Веб-мастер сам так настроил
Иногда владелец сам перенаправляет мобильных посетителей на сторонние сайты ради продажи трафика или подключает партнерский код, не проверив его поведение. Если пользователь вместо обещанной страницы попадает на несвязанный ресурс, поисковые системы считают это обманом независимо от того, кто написал скрипт.
Скрипт ворует трафик, веб-мастер не в курсе
Нелицензионные CMS и темы, заброшенные плагины, бесплатные виджеты и рекламные скрипты могут содержать вредоносный код или уязвимости. Редиректы также внедряют через скомпрометированный контейнер диспетчера тегов, service worker, код в базе данных, настройки CDN и взломанный аккаунт поставщика внешнего JavaScript.
Злоумышленники взломали сайт
После взлома злоумышленник может изменить файлы, базу данных, правила веб-сервера, DNS или шаблоны CMS. Нередко он создает скрытого администратора и оставляет механизм повторного доступа, поэтому простое удаление строки с редиректом не решает проблему.
FAQ по разделу
Редирект всегда находится в файлах сайта?
Нет, проверьте базу данных, CMS, диспетчер тегов, service worker, DNS, CDN и внешние скрипты.
Может ли давно установленный плагин стать причиной?
Да, уязвимость могли обнаружить позже, а поддержку плагина — прекратить.
Почему код появляется снова?
Могли остаться похищенные учетные данные, скрытый администратор, веб-шелл или уязвимый компонент.
Как найти скрытый редирект на мобильных устройствах
Вредоносный код старается не показываться владельцу сайта: срабатывает только после перехода из поиска, на определенном устройстве, в мобильной сети или один раз за несколько визитов. Но есть несколько сигналов, по которым можно догадаться, что что-то не так с мобильным просмотром.
Послушать жалобы пользователей
Уточните у пользователя модель устройства, браузер, исходный и конечный URL, время перехода, источник трафика и тип сети — мобильный интернет или Wi‑Fi. Попросите запись экрана. Эти данные помогут найти событие в журналах сервера и аналитике.
Проверить самому — открыть сайт на смартфоне
Откройте сайт из результатов Яндекса и Google на реальном смартфоне. Повторите проверку по Wi‑Fi и через мобильный интернет, в обычном и приватном окне. Проверьте несколько посадочных страниц: заражение может быть выборочным.
Для первичной диагностики подойдут режимы мобильного устройства в инструментах разработчика Chrome, Firefox и Safari. Но эмуляция меняет в основном размер экрана и User-Agent, поэтому не заменяет проверку на реальном телефоне и в другой сети.
Заглянуть в Яндекс.Вебмастер и Google Search Console
В Google Search Console проверьте отчет «Проблемы безопасности» и раздел ручных мер. После очистки опишите выполненные действия и отправьте запрос на повторную проверку.
В Яндекс.Вебмастере откройте «Диагностика» → «Безопасность и нарушения». Там отображаются найденные угрозы и результаты проверок.
Проверить сайт в сервисах
У PR-CY есть проверка вирусов онлайн в бесплатном инструменте. Он помогает увидеть предупреждения баз безопасного просмотра.
Если вы хотите провести более полную проверку, используйте сервис Анализа сайта. Он проверит технические параметры, отношение поисковиков, оптимизацию главной и ошибки на внутренних страницах. Проверка на вирусы в него тоже встроена:
Посмотреть сайт в выдаче
У зараженного сайта в поиске или браузере может появиться предупреждение. Однако отсутствие плашки ничего не доказывает: поисковый робот мог еще не увидеть редирект либо вредоносный код скрывает его от автоматических проверок.
При переходе на такой сайт может появиться страница с информацией о взломе, блокирующая переход.
Посмотреть мобильный трафик в аналитике
В Яндекс.Метрике сравните визиты и конверсию по типу устройства, браузеру, источнику и посадочной странице. Резкий спад мобильных визитов, рост отказов или необычно короткие сессии — повод проверить редирект. Сопоставьте момент изменения с обновлениями CMS, рекламного кода и контейнера тегов.
Как настроить контроль мобильного трафика в Яндекс.Метрике:
- Создайте сегмент «Тип устройства — смартфоны» и сохраните отчет по источникам и посадочным страницам.
- Сравните текущий период с предыдущей неделей и с аналогичным периодом без сезонных скачков.
- Отслеживайте визиты, конверсии, отказы и время на сайте. Для важных показателей настройте регулярный отчет или выгрузку в собственную систему мониторинга.
- При аномалии проверьте журналы веб-сервера, историю изменений CMS и контейнера тегов за тот же период.
Просадка трафика сама по себе не подтверждает заражение: на нее влияют сезонность, позиции, ошибки счетчика и изменения спроса. Ищите совпадение нескольких признаков — жалоб, подозрительных ответов сервера, изменений кода и предупреждений поисковых систем.
FAQ по разделу
Достаточно ли для проверки режима смартфона в Chrome?
Нет, нужен тест на реальном устройстве, из поиска и в разных сетях.
Как зафиксировать цепочку переходов?
Запишите экран, конечный URL и время; разработчик сопоставит их с журналами сервера и сетевыми запросами.
Если сервисы ничего не нашли, сайт чист?
Не обязательно, выборочный редирект может не сработать для робота, поэтому нужны ручная проверка и аудит кода.
Как удалить скрытый редирект с сайта
Действия по исправлению зависят от причины, по которой появилась скрытая переадресация.
Перед изменениями создайте резервную копию файлов и базы данных, сохраните ее отдельно от сервера и проверьте восстановление. Не разворачивайте зараженную копию поверх очищенного сайта без дополнительной проверки.
Если сайт взломали злоумышленники
Если есть чистая резервная копия, сравните ее с текущей версией и при необходимости восстановите сайт. Попросите хостинг проверить файлы, процессы и журналы. При серьезном взломе временно ограничьте доступ к сайту, сохраните копию журналов и обратитесь к специалисту по реагированию на инциденты.
Можно поискать код вручную, часто зловредные элементы прописывают в этих местах:
- правила веб-сервера: .htaccess, конфигурация Nginx или Apache, файлы виртуального хоста;
- index.php, файлы темы и шаблонов, каталоги загрузок, временные папки и недавно измененные PHP-файлы;
- JavaScript, iframe, service worker и подключаемые скрипты с внешних доменов;
- база данных: содержимое страниц, настройки CMS, задания cron и учетные записи администраторов;
- диспетчер тегов, CDN, DNS, рекламные кабинеты и панели интеграций.
Смените пароли от хостинга, SFTP/SSH, CMS, базы данных, регистратора домена и диспетчера тегов. Отзовите неизвестные сессии и API-ключи, включите двухфакторную аутентификацию. Делайте это с заведомо чистого устройства.
Если виноваты скрипты виджетов
Редирект на чужой сайт может работать через сторонние скрипты, плагины, шаблоны CMS, темы, другие элементы. Виноваты могут быть как новые недавно установленные плагины, так и те, которые давно стоят, но уже устарели — их могли взломать.
Если вы сами ничего не устанавливали, посмотрите историю доступов к сайту. Возможно, другие администраторы или модераторы поставили какой-то зараженный скрипт по незнанию или даже чтобы вам навредить
Что делать:
- Найдите страницу и условия, при которых срабатывает мобильная переадресация. В инструментах разработчика проверьте сетевые запросы, теги script и iframe, service worker и изменения адреса через JavaScript.
- Отключайте подозрительные компоненты по одному на тестовой копии. После каждого изменения повторяйте тот же сценарий на смартфоне.
- Удалите вредоносный код со всех страниц и закройте источник заражения: обновите или замените уязвимый компонент, удалите неизвестных администраторов и задания cron.
- Очистите кеш CMS и CDN, проверьте HTTP-ответы и цепочки перенаправлений, затем запросите повторную проверку в Яндекс.Вебмастере и Google Search Console.
Обязательно обновите CMS и плагины до последней стабильной версии, удалите все, что вызывает подозрение и подберите лицензионные решения с официальных источников.
Если веб-мастер сотрудничает с некачественными партнерками
Еще одна причина — веб-мастер специально или неосознанно сотрудничает с фейковыми партнерскими системами. Обычно они притворяются простыми партнерками с баннерной рекламой.
Подозрительные партнерские предложения приходят через рекламу, мессенджеры и почту, иногда от имени агентств. Отключите код такой сети, сохраните журналы и договорные данные, проверьте остальные ее скрипты и не возвращайте интеграцию до независимого аудита.
FAQ по разделу
Можно просто удалить строку с переадресацией?
Нет, нужно найти способ проникновения и механизм повторного доступа.
Когда отправлять сайт на перепроверку?
После очистки всех URL, смены доступов, обновления компонентов и контрольных тестов.
Нужно ли очищать кеш?
Да, старый скрипт может оставаться в кеше CMS, браузера, CDN или service worker.
Как защитить сайт от повторного скрытого редиректа
Нужно поработать с безопасностью проекта, чтобы уменьшить риск повторного появления редиректа на чужой сайт.
Обновляйте версии, не ставьте пиратский софт
Если вы нашли причину утечки мобильного трафика в каком-то расширении или модуле, возможно, больше не стоит пользоваться сайтом, на котором вы его взяли. Используйте только лицензионное ПО и устанавливайте все виджеты, модули, плагины и всевозможные решения только с официальных ресурсов. Чем меньше установлено, тем лучше — вероятность уязвимости статистически меньше.
Следите за бюллетенями разработчиков и записями CVE для вашей CMS, библиотек и серверного ПО. Критические обновления ставьте сначала на тестовой копии, но без неоправданной задержки. Удаляйте неиспользуемые плагины: выключенный уязвимый компонент тоже может оставаться доступным на сервере.
Поговорите с сотрудниками, обновляйте пароли
Для каждого сервиса используйте отдельный длинный пароль и храните его в менеджере паролей. Где возможно, включите двухфакторную аутентификацию или ключи доступа. Не передавайте общий аккаунт нескольким сотрудникам.
Для панели администратора можно установить задержку ввода пароля для следующих попыток после ввода неправильного. Так злоумышленнику будет сложнее перебирать пароли к админке сайта.
Выдавайте сотрудникам минимально необходимые права, регулярно отзывайте доступы у бывших коллег и подрядчиков. Все изменения CMS, диспетчера тегов, DNS и рекламного кода должны фиксироваться: кто, когда и зачем их внес.
Внимательнее выбирайте рекламодателей
Проверяйте владельца рекламной сети, договор, домены загрузки скриптов и порядок модерации объявлений. Для аудитории и владельцев сайтов из России используйте, например, Рекламную сеть Яндекса и VK Рекламу.
FAQ по разделу
Как часто проверять сайт?
Автоматически — постоянно; вручную — после обновлений, подключения рекламы и любых аномалий трафика.
Какие доступы защищать в первую очередь?
Хостинг, регистратор домена, CMS, SFTP/SSH, базу данных, CDN и диспетчер тегов.
Расскажите о своем опыте: вы сталкивались с такими редиректами? Как исправили ситуацию?
