WordPress перенаправляет на другой сайт: как исправить

WordPress перенаправляет на другой сайт: как исправить

Краткий ответ: если WordPress перенаправляет на другой сайт, сначала сделайте backup файлов и базы, проверьте .htaccess, wp-config.php, wp_options, активные плагины, тему, functions.php, JavaScript-вставки, пользователей-администраторов, cron, mu-plugins и файлы в uploads. Чаще всего причина — вредоносный редирект, заражённый плагин, изменённый .htaccess, чужой код в базе или неправильные значения siteurl/home.

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

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

Причина

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

Техническая ошибка чаще связана с неправильным доменом, SSL, http/https, www/без www, настройками siteurl/home, .htaccess, плагином редиректов или переносом сайта на другой хостинг.

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

Частые причины:

• в .htaccess добавлены чужие RewriteRule или Redirect;
• в wp_options изменены siteurl, home или добавлены вредоносные autoload-опции;
• в theme files вставлен подозрительный JavaScript или PHP-код;
• в functions.php добавлен wp_redirect(), header(‘Location’) или obfuscated-код;
• плагин заражён, устарел или конфликтует с настройками редиректа;
• в uploads лежат PHP-файлы, которых там быть не должно;
• создан неизвестный пользователь с ролью администратора;
• в wp-config.php добавлены чужие include, eval, base64_decode, gzinflate;
• в базе заражены записи wp_posts, wp_options, виджеты или настройки темы;
• в cron или mu-plugins есть код, который восстанавливает редирект после очистки;
• на уровне хостинга или CDN настроен неправильный редирект.

Диагностика

Сначала определите, какой именно редирект происходит. Это помогает понять, где искать причину: в WordPress, базе, сервере, плагине, теме или вредоносном коде.

Симптом	Вероятная причина	Что проверить
Всех посетителей сразу уводит на чужой домен	.htaccess, wp_options, wp-config.php, серверный редирект	.htaccess, siteurl/home, панель хостинга, CDN
Редирект только из Google	вредоносный код проверяет referrer	theme files, plugins, wp_options, JS-вставки
Редирект только на мобильном	мобильный malicious redirect	JS, header.php, footer.php, плагины рекламы, кеш
Редирект только для гостей	код скрывается от администратора	проверка в инкогнито, с другого IP, без авторизации
Редирект появляется снова после очистки	остался backdoor или cron-задача	mu-plugins, uploads, wp-cron, неизвестные файлы
Редирект на старый домен	ошибка переноса сайта или siteurl/home	wp_options, wp-config.php, Search/Replace в базе
Редирект после установки плагина	настройка редиректа или заражённый плагин	список плагинов, changelog, последние изменения
Редирект только на отдельных страницах	заражён контент, шаблон или шорткод	wp_posts, page builder, custom fields, виджеты

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

Решение

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

1. Сделайте backup. Сохраните файлы и базу данных до любых изменений. Даже заражённая копия лучше, чем отсутствие копии.
2. Проверьте редирект в инкогнито. Откройте сайт как гость, с мобильного, из другого браузера и без авторизации.
3. Проверьте .htaccess. Уберите неизвестные редиректы, но не стирайте рабочие правила сайта без копии.
4. Проверьте wp-config.php. Найдите чужие include, require, eval, base64_decode, подозрительные переменные и внешние URL.
5. Проверьте wp_options. Убедитесь, что siteurl и home ведут на ваш домен. Найдите подозрительные autoload-записи.
6. Отключите подозрительные плагины. Особенно недавно установленные, давно не обновлявшиеся или скачанные не из официальных источников.
7. Проверьте тему. Осмотрите header.php, footer.php, functions.php, шаблоны и дочернюю тему.
8. Проверьте uploads. В папке uploads не должно быть исполняемых PHP-файлов.
9. Проверьте пользователей. Удалите неизвестных администраторов, смените пароли, проверьте email-адреса.
10. Проверьте cron и mu-plugins. Там часто прячут код, который восстанавливает редирект после очистки.
11. Обновите WordPress, темы и плагины. Делайте это после backup и проверки совместимости.
12. Проверьте сайт после очистки. Главная, внутренние страницы, wp-admin, формы, мобильная версия, Search Console, sitemap и редиректы.

Код

Важно: код ниже предназначен для диагностики. Перед изменением wp-config.php, .htaccess или базы данных сделайте backup. Не показывайте ошибки посетителям сайта и не удаляйте найденные строки, пока не понимаете, за что они отвечают.

Куда вставлять: в файл wp-config.php, выше строки /* That’s all, stop editing! */. Код включает запись ошибок в debug.log, но не показывает ошибки посетителям.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

После этого проверьте файл:

/wp-content/debug.log

Стандартный .htaccess для WordPress в корне сайта выглядит так. Куда проверять: файл .htaccess в корневой папке сайта. Перед заменой скачайте текущий файл.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

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

Если есть доступ к WP-CLI, можно проверить адрес сайта, список плагинов, пользователей и cron-задачи. Команды выполняются в терминале на сервере:

wp option get siteurl
wp option get home
wp plugin list
wp user list --role=administrator
wp cron event list

Можно быстро поискать подозрительные строки в файлах. Команды выполняются на сервере из корня сайта:

grep -R "base64_decode" wp-content/ -n
grep -R "eval(" wp-content/ -n
grep -R "gzinflate" wp-content/ -n
grep -R "wp_redirect" wp-content/ -n
grep -R "Location:" wp-content/ -n

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

После диагностики на рабочем сайте отключите debug-режим:

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

Где искать вредоносный редирект

Редирект может быть не в одном месте. Если очистить только .htaccess, а backdoor останется в uploads или базе, сайт может снова заразиться.

.htaccess

Ищите чужие правила Redirect, RewriteRule, RewriteCond с неизвестными доменами, проверкой user-agent, referrer, mobile или IP.

wp-config.php

Проверьте, нет ли подозрительных include/require на файлы с непонятными именами, внешних URL, eval, base64_decode, gzinflate или кода выше стандартных настроек WordPress.

wp_options

Проверьте siteurl, home, active_plugins, template, stylesheet и autoload-опции. Вредоносный код может храниться в настройках темы, виджетах, transient-значениях или неизвестных опциях.

Тема

Чаще всего редирект вставляют в header.php, footer.php, functions.php, index.php, single.php, page.php или файлы дочерней темы.

Плагины

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

uploads

В uploads обычно должны быть изображения и медиафайлы. PHP-файлы в uploads — серьёзный повод для проверки.

mu-plugins

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

Пользователи

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

Как отличить вирус от неправильной настройки

Не каждый редирект — это взлом. Иногда сайт перенаправляет на другой домен после переноса, неправильной настройки SSL или плагина редиректов.

Признак	Похоже на настройку	Похоже на взлом
Редирект на старый домен	часто да	редко
Редирект на казино, рекламу, чужой магазин, подозрительный домен	нет	да
Редирект только с мобильного	редко	часто
Редирект только из Google	редко	часто
Редирект видят только неавторизованные пользователи	редко	часто
Редирект появился после переноса сайта	часто да	возможно, но не основная причина
Редирект возвращается после очистки .htaccess	редко	часто
Есть неизвестные PHP-файлы в uploads	нет	да

Как очистить сайт после редиректа

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

1. Сохраните заражённую копию. Она нужна для анализа и отката отдельных данных.
2. Сравните файлы с чистыми версиями. Ядро WordPress лучше заменить официальными файлами той же версии или обновить аккуратно.
3. Удалите подозрительный код из .htaccess. Оставьте только нужные правила WordPress и ваши подтверждённые редиректы.
4. Очистите тему. Проверьте header.php, footer.php, functions.php и дочернюю тему.
5. Очистите плагины. Удалите неиспользуемые, замените подозрительные, обновите устаревшие.
6. Проверьте базу данных. Ищите чужие домены, script, iframe, base64, eval, неизвестные autoload-опции.
7. Удалите backdoor-файлы. Проверьте uploads, cache, mu-plugins, wp-content и нестандартные папки.
8. Смените пароли. WordPress, хостинг, FTP/SFTP, база данных, email администратора, панели API.
9. Обновите соли WordPress. Это разлогинит старые сессии пользователей.
10. Проверьте права файлов. Файлы и папки не должны быть доступны на запись всем подряд.
11. Проверьте сайт повторно. Из инкогнито, с мобильного, по ссылке из поиска, с разных страниц.

Результат

После исправления важно получить не просто “редирект исчез”, а чистое и контролируемое состояние сайта.

• сайт больше не перенаправляет посетителей на чужой домен;
• wp-admin открывается;
• .htaccess очищен от неизвестных правил;
• wp_options содержит правильные siteurl и home;
• в теме нет подозрительных вставок;
• в plugins нет неизвестных или заражённых файлов;
• в uploads нет исполняемых PHP-файлов;
• неизвестные администраторы удалены;
• пароли и соли WordPress обновлены;
• формы заявок проверены;
• если есть WooCommerce — проверены корзина, checkout, оплата, доставка и письма;
• Search Console не показывает новые заражённые URL;
• создан свежий backup уже после очистки.

Дополнительные способы

Проверка через Search Console

Проверьте, какие страницы Google видел с редиректом или вредоносным содержимым. После очистки отправьте важные страницы на повторную проверку.

Проверка с другого устройства

Некоторые вредоносные редиректы не срабатывают для администратора. Проверяйте сайт из инкогнито, с телефона и с другого IP.

Проверка даты изменения файлов

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

Проверка cron

Некоторые заражения используют wp-cron для повторного создания вредоносного кода. Проверьте неизвестные cron events через WP-CLI или плагин диагностики.

Проверка CDN и хостинга

Если в файлах и базе всё чисто, проверьте редиректы на уровне Cloudflare, CDN, панели хостинга, Nginx/Apache-конфига и доменной панели.

Частые ошибки

• Удалять только .htaccess. Редирект может быть в базе, теме, плагинах, mu-plugins или uploads.
• Ставить security-плагин вместо очистки. Плагин может найти часть проблемы, но не всегда удаляет backdoor.
• Не делать backup перед очисткой. Можно удалить важные настройки, товары, формы или шаблоны.
• Проверять сайт только под администратором. Вредоносный редирект часто скрывается от залогиненных пользователей.
• Игнорировать wp_options. Вредоносный код часто хранится в базе, а не только в файлах.
• Не менять пароли. Если доступ остался у злоумышленника, сайт могут заразить снова.
• Не проверять пользователей. Неизвестный администратор может восстановить вредоносный код.
• Оставлять старые плагины. Уязвимый плагин может снова открыть доступ к сайту.
• Не проверять Search Console. Google может продолжать видеть заражённые URL после частичной очистки.

Диагностика проблем

Если редирект не удаётся убрать, проверьте сценарий глубже.

Проблема	Что может быть причиной	Что делать
Редирект возвращается через несколько часов	backdoor, cron, mu-plugin, заражённый плагин	проверить wp-cron, mu-plugins, uploads, неизвестные файлы
Редирект виден только с телефона	mobile redirect malware	проверить JS, header/footer, плагины рекламы, кеш
Редирект только из Google	код проверяет referrer	проверить theme files, wp_options, server logs
Редирект только на одной странице	заражён конкретный пост, шаблон, виджет или блок	проверить wp_posts, custom fields, page builder
Редирект на старый домен	ошибка переноса или настройки URL	проверить siteurl/home, wp-config.php, редиректы хостинга
.htaccess сам меняется после очистки	код с правом записи восстанавливает правила	найти процесс, плагин или backdoor, который пишет в файл
Админка тоже перенаправляет	siteurl/home, security-плагин, вирус, .htaccess	проверить базу, .htaccess, wp-config.php, плагины через FTP
Редиректа нет, но Google показывает предупреждение	кеш поиска, не все URL очищены, остались заражённые страницы	проверить Search Console, отправить на повторную проверку

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

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

• обновите WordPress, тему и плагины после backup;
• удалите неиспользуемые темы и плагины;
• не используйте nulled-плагины и темы;
• смените пароли WordPress, FTP/SFTP, хостинга, базы и email;
• проверьте всех пользователей с ролью администратора;
• отключите выполнение PHP в uploads, если это возможно на вашем сервере;
• настройте регулярные backup;
• проверяйте сайт каждый месяц по техническому чек-листу;
• используйте 2FA для администраторов;
• ограничьте доступ к wp-admin, если это допустимо для проекта;
• следите за изменениями файлов и security-логами;
• проверяйте Search Console после очистки.

FAQ

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

Причина может быть в вирусе, .htaccess, wp_options, wp-config.php, теме, плагине, JavaScript-вставке, server redirect, CDN, неправильных siteurl/home или заражённой базе данных.

Что делать в первую очередь?

Сделайте backup файлов и базы, проверьте редирект в инкогнито, откройте .htaccess, wp-config.php, wp_options, список администраторов, активные плагины, тему и debug.log.

Можно ли просто удалить .htaccess?

Нет. Сначала скачайте копию. Иногда .htaccess содержит нужные правила WordPress, HTTPS, кеша, мультиязычности и редиректов. Удаление без понимания может сломать сайт.

Почему редирект видят только посетители, а администратор не видит?

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

Где чаще всего прячется вредоносный редирект?

В .htaccess, wp-config.php, header.php, footer.php, functions.php, wp_options, wp_posts, uploads, mu-plugins, устаревших плагинах и неизвестных файлах внутри wp-content.

Почему редирект возвращается после очистки?

Значит остался backdoor, cron-задача, неизвестный администратор, заражённый плагин или код, который снова записывает вредоносные правила в файлы или базу.

Как проверить wp_options?

Через phpMyAdmin или WP-CLI проверьте siteurl, home, active_plugins, template, stylesheet и подозрительные autoload-опции. Ищите чужие домены, script, iframe, eval, base64 и непонятные длинные значения.

Может ли плагин редиректов быть причиной?

Да. Проверьте правила в Redirection, SEO-плагинах, кеш-плагинах, security-плагинах и плагинах мультиязычности. Иногда редирект является не вирусом, а ошибочной настройкой.

Что делать, если сайт редиректит на старый домен?

Проверьте siteurl/home в wp_options, WP_HOME/WP_SITEURL в wp-config.php, правила .htaccess, редиректы хостинга, CDN и остатки старого домена в базе данных.

Нужно ли менять пароли после удаления редиректа?

Да. Смените пароли WordPress, хостинга, FTP/SFTP, базы данных, email администратора и обновите соли WordPress. Иначе злоумышленник может снова получить доступ.

Вывод

Если WordPress перенаправляет на другой сайт, проблема может быть как в обычной настройке редиректа, так и во взломе. Безопасный порядок такой: backup, диагностика симптома, проверка .htaccess, wp-config.php, wp_options, темы, плагинов, uploads, пользователей, cron и серверных правил.

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