Что делать, если сайт перенаправляет посетителей на чужие страницы

Сайт открывается нормально у владельца, но клиенты жалуются, что вместо каталога или формы заказа попадают на страницу казино, сомнительный интернет-магазин, фальшивое предупреждение об антивирусе или предложение установить приложение. Иногда перенаправление происходит только с телефона, только после перехода из Google или рекламы, только один раз — а при повторной проверке всё снова работает.

Это не обязательно ошибка посетителя. Так часто выглядит вредоносный редирект: посторонний код определяет, кто и откуда открыл страницу, а затем выборочно отправляет часть аудитории на чужой сайт. Владелец, разработчик и даже автоматический сканер могут долго не замечать проблему.

Если сайт неожиданно перенаправляет людей на ресурс, который вы не настраивали, разумно считать это потенциальным инцидентом безопасности, пока не доказано обратное. Особенно опасно продолжать вести на такой сайт платную рекламу или принимать через него заказы.

Короткий ответ: что делать прямо сейчас

Если вы обнаружили нежелательное перенаправление:

1. Зафиксируйте проявление проблемы: исходную страницу, конечный адрес, время, устройство, браузер и источник перехода.
2. Приостановите рекламу, которая ведёт на заражённые страницы. Если редирект затрагивает корзину, оплату или личный кабинет, временно остановите и эти функции.
3. Не удаляйте файлы наугад и не восстанавливайте резервную копию поверх текущего сайта. Сначала сохраните снимок заражённого состояния и журналы сервера.
4. Свяжитесь с хостингом или специалистом по безопасности WordPress. Передайте собранные примеры и точное время срабатывания.
5. С чистого устройства защитите ключевые аккаунты: хостинг, регистратор домена, DNS/CDN, корпоративную почту и WordPress. Отзовите неизвестные сеансы, включите двухфакторную аутентификацию.
6. Проверьте Google Search Console, особенно раздел «Проблемы безопасности».
7. После удаления заражения смените все пароли ещё раз, устраните точку входа и только затем возвращайте рекламу и отправляйте сайт на повторную проверку Google.

Само перенаправление — только симптом. Главная задача состоит не в том, чтобы убрать одну подозрительную строку, а в том, чтобы выяснить, как она появилась и что позволяет злоумышленнику вернуть её снова.

Как выглядит вредоносный редирект

Нежелательное перенаправление не всегда одинаково. Посетитель может:

• сразу попасть на совершенно другой домен;
• несколько секунд видеть ваш сайт, после чего откроется реклама;
• получить новое окно или вкладку вместо прямого редиректа;
• попасть на поддельную страницу обновления браузера или антивируса;
• увидеть предложение разрешить уведомления;
• перейти на страницу казино, ставок, криптовалют, знакомств или сомнительных товаров;
• оказаться на фальшивой форме входа или оплаты;
• получить редирект только после клика по кнопке, меню или свободному месту на странице;
• увидеть нормальный сайт при повторном посещении.

Последний сценарий особенно коварен. Вредоносный код может записать cookie или значение в локальное хранилище браузера и больше не перенаправлять того же человека. В результате клиент сталкивается с проблемой один раз, а владелец после получения жалобы не может её повторить.

Почему сайт не перенаправляет самого владельца

Злоумышленникам выгодно как можно дольше оставаться незамеченными. Поэтому редирект может срабатывать выборочно:

• только для посетителей, которые не вошли в WordPress;
• только при первом открытии;
• только на мобильных устройствах;
• только в определённых странах;
• только при переходе из Google, социальной сети или рекламного объявления;
• только для определённых браузеров;
• не для IP-адреса владельца или разработчика;
• не при прямом вводе адреса сайта;
• случайно, например для каждого пятого или десятого посетителя.

Такое сокрытие называют cloaking: сервер или скрипт показывает разным посетителям разное содержимое. Google отдельно предупреждает, что взломщики могут делать вредоносное поведение видимым только для определённых источников перехода или User-Agent. Поэтому отсутствие редиректа на компьютере владельца не опровергает жалобу клиента.

Любое ли перенаправление означает взлом

Нет. У сайта могут быть нормальные технические редиректы:

• с http:// на https://;
• с версии с www на адрес без www или наоборот;
• со старой страницы на новую;
• с удалённого товара на подходящую замену;
• на языковую или региональную версию;
• после авторизации или оплаты;
• на платёжную страницу известного провайдера.

Проблема начинается, когда посетитель попадает на домен или страницу, которую бизнес не выбирал, либо редирект происходит в неожиданном месте. Переход на неизвестную рекламу, страницу загрузки, фальшивую проверку безопасности, казино или копию формы оплаты нельзя считать обычной ошибкой WordPress.

Иногда причина находится не на сайте. Если перенаправление видит только один человек и оно повторяется на разных сайтах, возможно заражение его браузера, расширения, устройства или локальной сети. Но если одинаковые жалобы поступают от нескольких независимых посетителей, особенно после перехода из одного источника, сайт и его инфраструктуру необходимо проверять полностью.

Откуда может появиться чужой редирект

У сайта нет единственной кнопки «перенаправлять посетителей». Команда может находиться на нескольких уровнях.

1. Взломанный плагин, тема или WordPress

Уязвимый или давно не обновлявшийся компонент может позволить загрузить посторонний PHP- или JavaScript-код. Иногда проблема появляется после установки темы или плагина из неофициального источника. В других случаях легальный плагин был скомпрометирован, получил уязвимость или продолжает работать в версии, для которой уже выпущено исправление.

Отключение подозрительного плагина может остановить редирект, но не гарантирует очистку: через уязвимость злоумышленник мог создать отдельный файл, нового администратора или постоянный backdoor.

2. Изменённые файлы сайта

Код редиректа часто внедряют в:

• .htaccess;
• index.php;
• файлы активной темы;
• header.php, footer.php или functions.php;
• wp-config.php;
• каталоги плагинов;
• mu-plugins;
• папку загрузок, где в нормальной ситуации должны находиться изображения и документы;
• неизвестные PHP-файлы в корне сайта и системных каталогах.

Официальная документация WordPress называет .htaccess, index.php, файлы шапки, подвала и функций среди частых целей при восстановлении взломанного сайта.

3. Вредоносная запись в базе данных

Редирект может быть добавлен не в файл, а в содержимое страницы, виджет, настройку темы, HTML-блок, шаблон Elementor или значение в таблице wp_options. Простая переустановка WordPress в таком случае ничего не изменит: заражённая команда останется в базе данных.

4. Посторонний администратор или украденный пароль

Если злоумышленник получил административный доступ, он может устанавливать плагины, менять файлы через редактор, добавлять задачи и возвращать удалённый код. Проверять необходимо не только список обычных пользователей, но и:

• администраторов WordPress;
• пользователей хостинга;
• SFTP/FTP-аккаунты;
• SSH-ключи;
• доступы разработчиков;
• application passwords WordPress;
• активные сеансы;
• аккаунты с доступом к CDN, DNS и панели домена.

5. Правила сервера, CDN или DNS

Перенаправление может быть создано вне WordPress:

• в конфигурации Apache или Nginx;
• в панели хостинга;
• в правилах CDN;
• в edge-функции или worker;
• через заменённые DNS-записи;
• после захвата аккаунта регистратора домена.

В этом случае очистка файлов WordPress не поможет. Более того, сайт может перенаправляться даже при полностью отключённом WordPress.

6. Сторонний скрипт, реклама или виджет

Чужой код иногда приходит через подключённый сервис: рекламную сеть, онлайн-чат, счётчик, pop-up, внешний виджет или контейнер Google Tag Manager. Google относит обманные сторонние ресурсы и перенаправления через встроенные компоненты к проблемам безопасности самого сайта — даже если вредоносный код физически загружается с другого домена.

7. Кэш или service worker

После очистки серверной части старый скрипт может продолжать отдаваться из кэша браузера, CDN или кэширующего плагина. Service worker также способен обслуживать сохранённые ресурсы независимо от обычной загрузки страницы. Поэтому после ремонта очищают все уровни кэша и проверяют сайт на новом устройстве или в чистом профиле браузера.

Как безопасно подтвердить проблему

Не стоит десятки раз открывать подозрительную страницу на рабочем компьютере. Google предупреждает, что заражённая страница может использовать уязвимость браузера, а вредоносное содержимое иногда намеренно скрывается от владельца.

Для первоначальной проверки полезно собрать следующие данные:

• URL страницы, с которой начался переход;
• конечный URL и все промежуточные адреса;
• дата, точное время и часовой пояс;
• телефон или компьютер;
• операционная система и браузер;
• страна и тип подключения: домашний Wi-Fi или мобильная сеть;
• откуда человек пришёл: Google, реклама, соцсеть, письмо или прямой адрес;
• был ли пользователь авторизован;
• происходил ли редирект повторно;
• скриншот или запись экрана.

Что может проверить владелец без доступа к серверу

1. Открыть раздел Security Issues / «Проблемы безопасности» в Google Search Console.
2. Проверить сайт в режиме инкогнито, не входя в WordPress, но не взаимодействовать с подозрительной конечной страницей.
3. Проверить с телефона через мобильную сеть, если жалобы относятся только к мобильным устройствам.
4. Посмотреть, нет ли в Google неизвестных страниц, используя запрос site:example.com и дополнительные подозрительные слова.
5. Убедиться, что домен использует ожидаемые DNS-серверы и записи не менялись без ведома компании.
6. Проверить список администраторов WordPress на наличие неизвестных пользователей.

Инструмент проверки URL в Search Console полезен тем, что позволяет посмотреть страницу так, как её видит Google. Это помогает при редиректах, которые включаются только для поискового робота или посетителей из результатов поиска.

Что должен проверить технический специалист

Уровень	Что проверяется
Домен и DNS	Регистратор, NS-записи, A/AAAA/CNAME, история изменений, неизвестные пользователи и API-ключи
CDN и прокси	Redirect Rules, Workers, Page Rules, кэш, сторонние интеграции
Веб-сервер	Конфигурация Apache/Nginx, .htaccess, виртуальные хосты, серверные cron-задачи
WordPress Core	Соответствие файлов официальным контрольным суммам, лишние файлы в корне и системных каталогах
Плагины и темы	Уязвимые версии, изменённые файлы, компоненты из неизвестных источников, неактивные расширения
wp-content	mu-plugins, drop-ins, папка uploads, кэш, резервные копии внутри публичной директории
База данных	wp_options, виджеты, HTML-блоки, шаблоны конструктора, содержимое записей, подозрительные скрипты
Доступы	Администраторы, application passwords, SFTP/SSH, ключи, активные сессии
Задачи	WP-Cron, системный cron, запланированные действия WooCommerce и нестандартные hooks
Внешний код	Google Tag Manager, рекламные сети, чаты, аналитика, виджеты и удалённые JavaScript-файлы
Журналы	Запросы к подозрительным файлам, изменения, входы, загрузки, ошибки PHP, срабатывания WAF

На сервере с WP-CLI специалист может, среди прочего, проверить официальные файлы WordPress и плагины, вывести администраторов и посмотреть запланированные события:

wp core verify-checksums --include-root
wp plugin verify-checksums --all
wp user list --role=administrator
wp cron event list

Успешная проверка контрольных сумм не доказывает, что сайт чист. Она не покрывает базу данных, серверную конфигурацию, DNS, CDN, пользовательскую тему, часть премиальных плагинов и вредоносные файлы за пределами проверяемых каталогов. Это один из инструментов расследования, а не кнопка «сайт безопасен».

Первые действия: остановить ущерб и сохранить данные

Приостановите рекламу

Продолжать покупать переходы на заражённый сайт опасно для клиентов и рекламного кабинета. Платформа может отклонить объявления или заблокировать домен, а посетитель — связать мошенническую страницу с вашей компанией.

Если проблема обнаружена в checkout, платёжной форме или личном кабинете, стоит временно ограничить эти функции. Внедрённый скрипт на странице оплаты потенциально может перехватывать вводимые данные, поэтому такой случай требует приоритетного расследования и связи с платёжным провайдером.

Сделайте снимок заражённого состояния

Резервная копия нужна даже тогда, когда она содержит вредоносный код. В ней остаются следы, по которым можно установить источник заражения, время изменения файлов и механизм повторного появления редиректа. WordPress также рекомендует перед очисткой создать отдельный snapshot текущего состояния.

Эту копию нельзя использовать как обычную рабочую резервную копию и хранить в публично доступной папке сайта. Её задача — расследование и возможность вернуть случайно удалённые данные.

Сохраните журналы

Не очищайте логи до расследования. Полезны:

• access log и error log веб-сервера;
• журнал входов WordPress;
• журнал действий администратора, если он был настроен;
• история изменений файлов;
• события WAF и CDN;
• история входов в хостинг, почту и аккаунт регистратора;
• логи исходящей почты;
• история развертываний и обновлений.

Чем раньше они сохранены, тем выше шанс понять точку входа. На некоторых тарифах хостинг хранит журналы лишь ограниченное время.

Защитите аккаунты с чистого устройства

Если пароль был украден с заражённого компьютера, его смена на том же устройстве не решит проблему. Сначала проверьте рабочий компьютер, обновите браузер и операционную систему, а затем меняйте доступы.

При первичной локализации инцидента необходимо:

• сменить пароли хостинга, регистратора, DNS/CDN и администраторов WordPress;
• сменить SFTP/FTP, SSH и при необходимости пароль базы данных;
• защитить корпоративную почту, через которую можно восстановить остальные аккаунты;
• отозвать активные сеансы и неизвестные ключи;
• включить 2FA;
• обновить WordPress salts в wp-config.php, чтобы завершить существующие сессии.

После окончательной очистки пароли меняют ещё раз: первая ротация ограничивает доступ во время расследования, вторая гарантирует, что новые данные не остались в доступе у кода, который ещё находился на сервере.

Почему простого восстановления из резервной копии недостаточно

Восстановить последнюю «чистую» копию кажется самым быстрым решением. Иногда это действительно часть правильного восстановления, но одной кнопки Restore обычно недостаточно.

Копия уже могла быть заражена

Между проникновением и первым заметным редиректом могут пройти недели. Если backdoor появился раньше, он будет присутствовать и в нескольких последних бэкапах.

Уязвимость останется открытой

После восстановления вернётся старая версия плагина или темы, через которую произошёл взлом. Автоматический бот может повторить атаку почти сразу.

Вредоносные файлы могут не удалиться

Некоторые системы восстановления перезаписывают существующие файлы, но не удаляют новые. Созданный злоумышленником PHP-файл останется рядом с восстановленной чистой установкой.

Причина может находиться вне файлов сайта

Бэкап WordPress обычно не включает настройки регистратора, DNS, CDN, панельные редиректы, серверные задачи и аккаунты хостинга. Если проблема находится там, восстановление ничего не изменит.

Украденные доступы продолжат работать

Даже идеально чистая копия будет снова изменена, если у постороннего пользователя остался пароль, SSH-ключ, активная сессия или доступ к почте владельца.

Правильная схема выглядит так: сохранить состояние и логи, определить область заражения, закрыть точку входа, развернуть проверенные файлы или очистить данные, удалить механизмы закрепления, сменить доступы, протестировать сайт и настроить наблюдение.

Типичные ошибки при самостоятельной очистке

Удалить только найденную строку редиректа

Строка может быть лишь последним звеном. Отдельный backdoor или задача cron добавит её снова через несколько часов.

Установить ещё один защитный плагин и нажать Scan

Сканер полезен, но работает внутри уже скомпрометированной системы. Вредоносный код может скрыть файлы, подменить результаты или находиться на уровне, который плагин не проверяет.

Удалить всё подозрительное без резервной копии

Так можно окончательно сломать сайт, потерять заказы или уничтожить доказательства, необходимые для поиска точки входа.

Сменить только пароль WordPress

Редирект может управляться через хостинг, SFTP, DNS, CDN, корпоративную почту или серверный ключ. Все точки доступа рассматриваются как единая цепочка.

Обновить плагины и считать задачу выполненной

Обновление закрывает известную уязвимость, но не удаляет уже созданных пользователей, файлов, задач и записей в базе.

Сразу запросить повторную проверку Google

Если хотя бы часть вредоносного поведения сохранилась, проверка не пройдёт. Сначала необходимо очистить все затронутые страницы и механизмы, проверить разные сценарии и только потом отправлять запрос.

Снова включить рекламу после одной удачной проверки

Условный редирект может проявиться не сразу. После очистки нужен период усиленного мониторинга и проверки с разных устройств, сетей и источников трафика.

Как понять, что сайт действительно очищен

Отсутствия редиректа на одном компьютере недостаточно. После ремонта необходимо подтвердить несколько вещей:

• неизвестные администраторы, ключи и сеансы удалены;
• официальные файлы WordPress и доступных плагинов проходят проверку;
• темы, плагины, mu-plugins, uploads и корневые каталоги проверены вручную;
• подозрительные записи удалены из базы;
• серверные и WordPress cron-задачи проверены;
• правила хостинга, CDN и DNS соответствуют ожидаемым;
• кэш сайта, CDN и браузеров очищен;
• редирект не повторяется на мобильном устройстве, при переходе из Google и рекламы;
• логи не показывают повторного обращения к вредоносным файлам;
• Search Console больше не находит проблем после завершения проверки;
• сайт проходит функциональное тестирование: формы, заказы, оплата, письма и личный кабинет работают.

Важно также установить причину. Если команда удалила заражение, но не может хотя бы обоснованно назвать вероятный путь проникновения, риск повторения остаётся высоким.

Что делать с Google и поисковым трафиком

Взлом может привести не только к редиректам. На домене иногда появляются тысячи спам-страниц, неизвестные ссылки и поисковые сниппеты на другом языке. Google может показать предупреждение перед входом на сайт или пометить результат как потенциально опасный.

После технической очистки:

1. Откройте отчёт Security Issues в Google Search Console.
2. Проверьте все указанные типы проблем и примеры URL — список примеров может быть неполным.
3. Найдите неизвестные индексируемые страницы через site:-запрос и отчёты Search Console.
4. Убедитесь, что вредоносные URL удалены и не перенаправляют людей на другие сайты.
5. Проверьте sitemap, robots.txt, canonical и важные страницы.
6. Отправьте запрос на повторную проверку безопасности.
7. Отслеживайте новые страницы, изменения сниппетов, позиции и брендовые запросы.

Google указывает, что проверка после запроса может занимать от нескольких дней до нескольких недель. Не нужно отправлять её повторно, пока предыдущая ещё выполняется.

Отчёт «Меры, принятые вручную» и отчёт «Проблемы безопасности» — не одно и то же. Первый относится преимущественно к нарушениям поисковых правил, второй — ко взлому и поведению, способному навредить посетителям. После инцидента стоит проверить оба.

Как снизить вероятность повторного заражения

Абсолютно неуязвимых сайтов не существует, но риск можно существенно уменьшить.

• Обновляйте WordPress, тему и плагины без многомесячных задержек.
• Перед обновлениями создавайте резервную копию и проверяйте критические функции на тестовой среде.
• Удаляйте неиспользуемые плагины и темы, а не просто отключайте их.
• Загружайте расширения только из доверенных источников.
• Используйте уникальные длинные пароли и 2FA.
• Выдавайте каждому специалисту отдельную учётную запись.
• Не отправляйте постоянные пароли в обычной переписке.
• Используйте SFTP вместо незашифрованного FTP.
• Ограничьте права файлов и административных пользователей.
• Отключите встроенное редактирование PHP-файлов, если оно не требуется рабочему процессу.
• Храните резервные копии отдельно от самого сайта и регулярно проверяйте восстановление.
• Настройте мониторинг доступности, изменений файлов, новых администраторов и проблем Search Console.
• Защитите аккаунт регистратора домена и корпоративную почту не слабее, чем WordPress.
• Документируйте плагины, внешние скрипты и людей, имеющих доступ.
• После ухода подрядчика сразу отзывайте его учётные записи и ключи.

Официальное руководство WordPress подчёркивает, что безопасность — это снижение риска, а не одна «волшебная» настройка. Плагин безопасности, хороший хостинг, резервные копии и обновления решают разные части задачи и не заменяют друг друга.

Часто задаваемые вопросы

Сайт нормально открывается у меня. Может ли он всё равно быть заражён?

Да. Редирект может исключать авторизованных администраторов, постоянных посетителей или определённые IP-адреса. Он также может срабатывать только на мобильных устройствах и после перехода из Google или рекламы.

Почему редирект произошёл только один раз?

Вредоносный скрипт мог сохранить cookie или метку в браузере, чтобы больше не показываться этому посетителю. Это помогает заражению оставаться незамеченным.

Антивирусный плагин ничего не нашёл. Значит, сайт чист?

Нет. Один сканер не видит все уровни инфраструктуры и все разновидности вредоносного кода. Необходимо сопоставить несколько проверок, файлы, базу, доступы, DNS/CDN и серверные журналы.

Поможет ли переустановка WordPress?

Она может восстановить системные файлы, но не очистит автоматически wp-content, базу данных, настройки сервера, DNS и посторонние аккаунты. Заражение может находиться именно там.

Нужно ли полностью переделывать сайт?

Обычно нет. Большинство заражённых сайтов можно очистить и укрепить без редизайна. Полная пересборка требуется, если невозможно отделить легальный код от заражённого, используется неподдерживаемая система или исходное состояние сайта неизвестно.

Могли ли пострадать данные клиентов?

Это зависит от места и возможностей внедрённого кода. Если заражение затронуло регистрацию, личный кабинет, оформление заказа или оплату, необходимо рассматривать возможную утечку данных, связаться с платёжным провайдером и проверить применимые требования к уведомлению об инциденте.

Как быстро исчезнет предупреждение Google?

После полной очистки нужно отправить запрос на проверку в Search Console. По данным Google, рассмотрение может занять от нескольких дней до нескольких недель. Поисковым результатам и спам-URL может потребоваться дополнительное время для обновления.

Может ли редирект вернуться после очистки?

Да, если не устранена уязвимость, остался backdoor, посторонний администратор, серверная задача или украденный доступ. Поэтому важны расследование причины и мониторинг после восстановления.

Когда необходимо обращаться к специалисту

Самостоятельная первичная проверка уместна, если вы понимаете устройство хостинга, умеете безопасно работать с файлами, базой данных и журналами и можете восстановить сайт при ошибке.

Лучше не экспериментировать на рабочем сайте, если:

• через него проходят заказы, платежи или персональные данные;
• редирект ведёт на фишинг или загрузку файлов;
• хостинг уже заблокировал аккаунт;
• пострадало несколько сайтов на одном сервере;
• появились неизвестные администраторы;
• код возвращается после удаления;
• заражение затронуло DNS, CDN или почту;
• у вас нет проверенной резервной копии;
• сайт критичен для ежедневной работы бизнеса.

Для начала диагностики специалисту полезно передать адрес сайта, время первого обнаружения, конечный URL редиректа, запись экрана, источник перехода и список недавних обновлений. Пароли лучше не отправлять в открытом письме: используйте временные учётные записи или защищённый способ передачи и отзовите доступ после завершения работ.

Главное

Нежелательный редирект — не просто неудобство и не обычный баг WordPress. Пока посетители попадают на чужие страницы, бизнес теряет рекламный бюджет, доверие, заказы и поисковую видимость. Если перенаправление происходит на странице оплаты или входа, риск становится ещё серьёзнее.

Правильное восстановление включает четыре задачи:

1. остановить ущерб;
2. сохранить данные для расследования;
3. удалить все части заражения и закрыть точку входа;
4. подтвердить очистку и наблюдать за сайтом после запуска.

Удалить одну подозрительную строку быстрее. Понять, почему она появилась и почему больше не сможет вернуться, — намного важнее.

Если ваш WordPress-сайт перенаправляет посетителей, 4 Pixels может провести диагностику, найти источник редиректа, восстановить работу сайта и составить план защиты от повторного заражения.