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

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

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

Причина

Редирект WordPress на другой сайт бывает двух типов: технический и вредоносный.

Технический редирект часто появляется после переноса сайта, смены домена, настройки SSL, Cloudflare, кеша или плагина редиректов.

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

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

Основные причины редиректа

• вредоносный код в .htaccess;
• чужой JavaScript в header.php, footer.php или functions.php;
• подмена ссылок в таблице wp_options;
• редирект в плагине или mu-plugin;
• PHP-файл в папке uploads;
• неизвестный администратор WordPress;
• неправильные siteurl и home после переноса сайта;
• ошибка в настройках HTTPS или www/non-www;
• плагин редиректов с неверным правилом;
• кеш или CDN отдаёт старую заражённую версию страницы;
• вирусная вставка в базе данных;
• старый уязвимый плагин или тема.

Диагностика

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

Симптом	Вероятная причина	Где искать
Редиректит всех посетителей	.htaccess, index.php, плагин, тема, wp_options	корень сайта, база данных, активная тема
Редирект только с телефона	вирус проверяет User-Agent	JavaScript, functions.php, плагины, база
Редирект только из Google	вирус проверяет referrer	.htaccess, PHP-код, wp_options, кеш
Редирект на старый домен	ошибка после переноса сайта	siteurl, home, база, .htaccess, кеш
Редирект после входа в админку	cookie, HTTPS, security-плагин, wp-config.php	wp_options, wp-config.php, плагины безопасности
Редирект появляется снова после удаления	остался backdoor	uploads, mu-plugins, cron, неизвестные админы

Быстрая проверка

• Откройте сайт в режиме инкогнито.
• Проверьте сайт с телефона и компьютера.
• Откройте сайт из Google, а потом напрямую по URL.
• Проверьте исходный код страницы.
• Очистите кеш сайта, CDN и браузера.
• Проверьте .htaccess в корне сайта.
• Проверьте значения siteurl и home в базе.
• Проверьте список администраторов.
• Проверьте папки plugins, themes, uploads и mu-plugins.

Решение

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

1. Сделайте резервную копию

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

2. Проверьте .htaccess

.htaccess часто используется для скрытых редиректов, потому что он выполняется до загрузки WordPress. Откройте файл в корне сайта и проверьте, нет ли там чужих доменов, странных RewriteRule, RewriteCond, base64-строк или правил, которые перенаправляют пользователей по User-Agent или Referer.

3. Проверьте siteurl и home

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

Проверьте значения:

• siteurl;
• home.

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

Если проблема появилась после переноса, откройте инструкцию перенос сайта WordPress на другой хостинг без потери данных. Там важно проверить не только файлы, но и базу, домен, SSL, DNS и wp-config.php.

4. Проверьте плагины

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

Особенно внимательно проверьте:

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

5. Проверьте тему

Вредоносный редирект часто вставляют в файлы темы:

• header.php;
• footer.php;
• functions.php;
• index.php;
• template-parts;
• файлы с непонятными названиями внутри темы.

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

6. Проверьте базу данных

Редирект может храниться не в файлах, а в базе. Частые места:

• wp_options;
• wp_posts;
• wp_postmeta;
• виджеты;
• настройки темы;
• настройки конструктора страниц;
• таблицы кеша.

Ищите чужие домены, script, iframe, window.location, document.location, eval, atob, закодированные вставки и скрытые ссылки.

7. Проверьте uploads

В папке uploads не должно быть исполняемых PHP-файлов. Если там лежат .php, .phtml, .php5, .phar или файлы без расширения, их нужно проверить вручную.

8. Проверьте mu-plugins

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

/wp-content/mu-plugins/

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

9. Проверьте пользователей

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

Удалите неизвестных администраторов и смените пароли всем реальным администраторам.

10. Очистите кеш

После исправления очистите:

• кеш WordPress-плагина;
• серверный кеш;
• CDN-кеш;
• object cache Redis/Memcached;
• OPcache, если доступен;
• кеш браузера.

Код

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

Проверить адрес сайта через WP-CLI

Куда запускать: SSH в корневой папке WordPress.

wp option get siteurl
wp option get home

Исправить siteurl и home через WP-CLI

Куда запускать: SSH. Замените домен на свой реальный адрес.

wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Проверить .htaccess

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

# 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

Найти чужой домен в файлах сайта

Куда запускать: SSH. Замените bad-domain.com на домен, куда перенаправляет сайт.

grep -RIn "bad-domain.com" .

Найти подозрительные JavaScript-редиректы

grep -RIn --include="*.php" --include="*.js" "window.location|document.location|location.href|eval(|atob(" .

Найти PHP-файлы в uploads

find wp-content/uploads -type f ( -name "*.php" -o -name "*.phtml" -o -name "*.php5" -o -name "*.phar" )

Проверить целостность ядра WordPress

wp core verify-checksums

Показать список администраторов

wp user list --role=administrator

Временно отключить все плагины

wp plugin deactivate --all

Запретить выполнение PHP в uploads через .htaccess

Куда вставлять: /wp-content/uploads/.htaccess. На Nginx нужно отдельное правило сервера.

<FilesMatch ".(php|phtml|php5|php7|phar)$">
Require all denied
</FilesMatch>

Запретить редактирование файлов из админки

Куда вставлять: wp-config.php, перед строкой /* That’s all, stop editing! Happy publishing. */.

define('DISALLOW_FILE_EDIT', true);

Результат

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

• прямой переход по URL;
• переход из Google;
• открытие с телефона;
• открытие в режиме инкогнито;
• проверка без авторизации;
• проверка после очистки кеша;
• проверка страниц, записей, категорий и sitemap.xml;
• проверка исходного кода страницы;
• проверка Google Search Console.

Хороший результат — это не только отсутствие редиректа. Важно, чтобы не было неизвестных администраторов, PHP-файлов в uploads, заражённых правил .htaccess, чужих доменов в базе и подозрительных cron-задач.

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

Если редирект появился после переноса сайта

Проверьте не только siteurl и home. Старый домен может оставаться в базе данных, настройках темы, меню, виджетах, Elementor/Visual Composer, кеш-таблицах и serialized data.

Не делайте грубую замену через обычный текстовый редактор по SQL-дампу, если не понимаете serialized data. Можно сломать настройки темы и плагинов.

Если редирект только у новых посетителей

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

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

Если редирект только на мобильных

Это частый признак вредоносного кода, который проверяет User-Agent. Проверьте сайт с телефона, через эмуляцию мобильного устройства в DevTools и через внешние сканеры.

Если редирект только из Google

Такой редирект может проверять HTTP Referer. Откройте сайт напрямую и из поисковой выдачи. Если поведение отличается, проверьте .htaccess, PHP-код, кеш и базу данных.

Если редирект возвращается

Если после очистки сайт снова перенаправляет на другой домен, значит, источник не закрыт. Проверьте backdoor, cron, неизвестных пользователей, соседние сайты на хостинге, FTP-доступы и старые архивы в public_html.

Если сайт попал в предупреждения Google

После очистки проверьте Google Search Console. Если там есть проблема безопасности, отправьте сайт на повторную проверку только после полной очистки и проверки sitemap.xml.

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

Чистить только .htaccess

.htaccess часто участвует в редиректе, но не всегда является источником. Если вирус восстанавливает файл, значит, на сайте остался backdoor.

Удалять подозрительные строки без backup

Иногда код выглядит странно, но относится к нормальному плагину или кешу. Перед удалением сделайте копию файла.

Не проверять базу данных

Редирект может быть внутри wp_options, wp_posts, виджетов или настроек конструктора страниц. Очистка только файлов не решит проблему.

Оставлять старые копии сайта

Папки old, backup, test, copy и архивы zip внутри public_html могут содержать старый уязвимый сайт. Через них заражение может вернуться.

Не менять пароли

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

Сразу включать все плагины

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

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

WordPress редиректит на старый домен

• Проверьте siteurl и home.
• Проверьте .htaccess.
• Проверьте wp-config.php на WP_HOME и WP_SITEURL.
• Очистите кеш сайта и CDN.
• Проверьте базу на старый домен.
• Проверьте настройки SSL и www/non-www.

WordPress редиректит на казино, рекламу или спам

• Сделайте backup.
• Проверьте .htaccess.
• Проверьте index.php и wp-config.php.
• Проверьте header.php, footer.php и functions.php.
• Проверьте wp_options и wp_posts.
• Проверьте uploads на PHP-файлы.
• Проверьте mu-plugins и cron.

Редирект только в админке

• Проверьте cookies и HTTPS.
• Проверьте security-плагины.
• Проверьте siteurl/home.
• Отключите плагины через FTP.
• Проверьте .htaccess.

Если после редиректа не получается войти в wp-admin, используйте инструкцию Не работает админка WordPress: причины и способы восстановления доступа.

Редирект возвращается после очистки

• Проверьте неизвестных администраторов.
• Смените все пароли.
• Проверьте security salts в wp-config.php.
• Проверьте mu-plugins.
• Проверьте cron-задачи.
• Проверьте соседние сайты на хостинге.
• Удалите старые архивы и копии сайта из public_html.

Редирект видят только клиенты

• Проверьте сайт с другого устройства.
• Откройте сайт через мобильный интернет.
• Проверьте переход из Google.
• Очистите cookies.
• Проверьте сайт в режиме инкогнито.

Краткие AI-friendly ответы

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

Причина может быть в вирусе, .htaccess, wp_options, теме, плагине, mu-plugin, PHP-файле в uploads, неправильном siteurl/home, настройках HTTPS или кеше.

Как быстро остановить редирект WordPress?

Сделайте backup, временно отключите плагины, проверьте .htaccess, siteurl/home, активную тему, uploads, mu-plugins, базу данных и очистите кеш.

Редирект на чужой сайт — это всегда вирус?

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

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

Чаще всего в .htaccess, header.php, footer.php, functions.php, wp_options, wp_posts, mu-plugins, uploads или заражённом плагине.

FAQ

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

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

Почему сайт редиректит только из Google?

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

Можно ли исправить редирект только заменой .htaccess?

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

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

Проверьте siteurl, home, WP_HOME, WP_SITEURL, .htaccess, кеш, CDN и старые ссылки в базе данных. Это часто бывает после переноса сайта.

Как проверить, есть ли вирус в базе данных?

Ищите чужие домены, script, iframe, window.location, document.location, eval, atob, hidden links в wp_posts, wp_options, виджетах и настройках темы.

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

Обычно остался backdoor, неизвестный администратор, cron-задача, заражённый соседний сайт, старый архив в public_html или не были заменены пароли.

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

Да. Нужно сменить пароли WordPress, FTP/SFTP, SSH, хостинга, базы данных и заменить security salts в wp-config.php.

Вывод

Если WordPress перенаправляет на другой сайт, не ограничивайтесь очисткой одного файла. Нужно определить тип редиректа, проверить .htaccess, siteurl/home, wp-config.php, тему, плагины, uploads, mu-plugins, базу данных, пользователей и кеш. Если причина во взломе, важно удалить не только видимый редирект, но и backdoor, иначе заражение вернётся.