WordPress hacked redirect: why your site sends visitors to spam and how to find it

A WordPress hacked redirect is injected code that sends some or all of your visitors to another site, usually a scam, a fake prize page, a push-notification trap, a casino or an adult site. Most redirect hacks are selective: they fire only for visitors who arrive from Google, only on phones, only once per visitor, or never for logged-in users, which is why the owner often cannot reproduce what customers report. This guide shows how to make the redirect happen in front of you, where the code hides in WordPress, and how to remove it so it does not come back. It is part of the hacked website guide, which covers the full cleanup order.

Quick answer

• Reproduce it as a stranger: a private window, not logged in, arriving from a Google search, on a phone as well as a desktop.
• Tell a server redirect from a JavaScript one in the browser's Network tab with "Preserve log" on, or with curl -I.
• Look in five places: .htaccess or the nginx config, PHP files (index.php, wp-config.php, the theme, plugins and mu-plugins), JavaScript files, the database (siteurl, home, posts and widgets) and scheduled tasks.
• Remove it by reinstalling, not by editing one file. A backdoor usually re-adds the redirect.
• Close the way in: update, remove unknown administrators, change every password and key.
• Check Google's view afterwards: Safe Browsing status and Search Console's Security issues.

If you are a visitor

If a site keeps sending you somewhere else, close the page and do not accept notification prompts, download anything or enter details on the page you landed on. If it happens on many unrelated sites, the problem may be on your device instead: a browser extension or unwanted software. Remove extensions you do not recognise and run your system's security scan. If it happens only on one site, tell its owner; they may not know.

Is it really a hack?

Rule out your own settings first, because a misconfigured site can redirect too:

• Settings → General. The WordPress Address and Site Address must both be your own domain. A different domain there is either a typo or a hack.
• A redirect plugin or SEO plugin rule that points somewhere unexpected.
• HTTPS or www rules at the host or CDN that loop or go to an old domain.

The redirect checker follows every hop from your URL and shows each status code, which answers this in seconds for redirects that happen to everyone. A redirect to an unrelated domain that only some visitors get is a hack.

The shapes a redirect hack takes

Many redirect hacks also load their script from a domain that changes every few weeks, so blocklists lag behind. Sucuri has tracked one long-running campaign of this kind, which it named Balada Injector, since 2017, and estimated that it had infected more than a million WordPress sites, mostly through plugin and theme vulnerabilities, to send visitors to fake tech-support, lottery and push-notification scams.

How to reproduce the redirect

1. Open a private or incognito window, so no WordPress login cookie or old redirect cookie exists.
2. Search Google for your brand or a page title and click your own result.
3. Repeat on a phone using mobile data, not your office Wi-Fi, in case the redirect skips your IP address after the first time.
4. In a desktop browser, open the developer tools (F12) → Network, tick Preserve log, and click the result again. The list shows each hop.

Reading the Network tab:

• A 301, 302 or 307 response from your own domain with a Location header to the spam site is a server-side redirect: .htaccess, the nginx config or PHP.
• A 200 from your page followed by a request to another domain is a client-side redirect: JavaScript in your page, in a script file or loaded from another domain. Click your page's request and search its response for the domain or for location.

You can test the server side from a terminal too:

# As a visitor arriving from Google on a phone: look for a Location header to another domain
curl -sI -e "https://www.google.com/" \
  -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1" \
  https://example.com/

Let the checker compare the fetches

The hacked site checker fetches the page as a normal visitor, with Googlebot's user agent, and as a browser arriving from https://www.google.com/. It flags a final URL on another host that only some fetches reach, and inline scripts that read document.referrer, look for Google, Bing or Yahoo, and change location:

It does not run JavaScript and fetches from a desktop user agent, so a redirect in an external script file, a mobile-only rule or one that fires once per IP can pass it. Use it together with the manual steps above.

Where the redirect hides in WordPress

Work through these in order. Save a copy of the site first (wp db export and an archive of the files), so you can compare and find the way in later.

1. Server configuration

Look in .htaccess in the site root and in wp-content/, wp-content/uploads/ and wp-admin/, and in the nginx configuration if you have access. Injected rules usually test the referrer or user agent:

# Injected: sends mobile visitors from search engines to a spam site
RewriteCond %{HTTP_REFERER} (google|bing|yahoo) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (android|iphone|mobile) [NC]
RewriteRule ^(.*)$ https://spam-domain.example/ [R=302,L]

WordPress's own block sits between # BEGIN WordPress and # END WordPress. Anything outside it that you did not add, especially RewriteCond lines on HTTP_REFERER or HTTP_USER_AGENT, is suspect.

2. PHP files

# Core files that differ from the official release
wp core verify-checksums
wp plugin verify-checksums --all

# Code at the top of files that load on every request
head -n 5 index.php wp-config.php wp-load.php

# Redirect code and obfuscation in themes, plugins and must-use plugins
grep -rlE "HTTP_REFERER|HTTP_USER_AGENT" --include=*.php wp-content/ | xargs grep -lE "header\(|Location|wp_redirect" 2>/dev/null
grep -rlE "eval\(|base64_decode|gzinflate|str_rot13" --include=*.php wp-content/
ls -la wp-content/mu-plugins/
find wp-content/uploads -name "*.php"

Legitimate plugins use some of these functions too, so review each hit. Plugins you never installed, and any PHP file in uploads, are almost always malicious.

3. JavaScript files

Attackers often append a few lines to a legitimate script, such as a theme's main JavaScript file or a copy of jQuery, so the redirect loads on every page without touching PHP:

# Recently changed JavaScript files
find wp-content -name "*.js" -mtime -30 -ls

# Typical redirect and obfuscation patterns in scripts
grep -rlE "document\.referrer|window\.location|location\.replace|String\.fromCharCode|atob\(" --include=*.js wp-content/themes wp-content/plugins

Compare a suspicious file with a fresh copy of the plugin or theme. A minified file with an extra line at the very end is the classic sign.

4. The database

wp option get siteurl
wp option get home
wp db search "<script" --all-tables --stats
wp db search "document.referrer" --all-tables
wp db search "spam-domain.example" --all-tables
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

siteurl and home must be your domain. Scripts hide in post content, in widget options (widget_% in wp_options), in "header and footer scripts" settings of plugins and themes, and in custom HTML blocks. Remove administrator accounts you do not recognise and attribute their content to a real user.

5. Scheduled tasks and the server

wp cron event list --fields=hook,next_run_relative
crontab -l

A cron hook that belongs to no plugin you run, or a server cron job you did not create, can re-inject the redirect after every cleanup.

How to remove a redirect hack for good

Deleting the lines you found stops the redirect for a day. The backdoor that put them there, and the hole the attacker came through, are still open. Clean in this order:

1. Put the site in maintenance so visitors stop being redirected (wp maintenance-mode activate).
2. Update WordPress, every plugin and theme, and delete the ones you do not use. Replace plugins closed on wordpress.org.
3. Reinstall code from clean sources: wp core download --force --skip-content, reinstall every plugin and the theme from wordpress.org or the vendor, and review your child theme by hand.
4. Remove what you found in .htaccess, the database, mu-plugins, uploads and cron.
5. Change every password and key: all administrators, hosting, SFTP, the database and the salts (wp config shuffle-salts).
6. Test again with the reproduction steps above, on desktop and phone, from Google.

Recovering a hacked WordPress site, step by step covers each step in depth, including finding the entry point in the access logs.

Check what Google and browsers now show

A redirect to scam or malware pages often gets the site listed by Google Safe Browsing, which puts a red warning in browsers. When the Web Risk lookup runs in your report, it shows whether Google flags the site:

Open Search Console → Security & Manual Actions → Security issues. If it lists the hack, request a review once the site is clean; Google Safe Browsing flags and the "This site may be hacked" label cover both reviews. A week later, run the checks again: a returning redirect means something survived.

How the attackers got in

Redirect campaigns mostly exploit known holes in plugins and themes, and stolen or guessed administrator passwords. The WordPress security scan flags the public signs of both:

Then give every administrator two-factor login, keep updates monthly or automatic, and follow the WordPress security checklist.

Common mistakes

• Testing while logged in. Most redirect hacks skip logged-in users. Use a private window.
• Testing from the same IP twice. Once-per-visitor redirects stay quiet the second time. Switch to mobile data.
• Fixing .htaccess and nothing else. A PHP backdoor rewrites it within hours. Reinstall code and check the database.
• Restoring a backup without checking it. Attackers are often inside weeks before the redirect starts. Search the backup for the spam domain first.
• Blaming the visitor's device. Adware exists, but if several customers report the same redirect on your site only, the site is the problem.

Questions people ask

Why is my website redirecting to another site?

Either a setting sends it there or the site is hacked. Check Settings → General, redirect plugin rules and your host's or CDN's redirects first. If visitors land on a scam, casino or adult site, especially only when they come from Google or use a phone, injected code in .htaccess, PHP files, JavaScript or the database is doing it. Reproduce it in a private window and follow the cleanup steps.

Why does my site redirect only on mobile?

Because the injected code checks the user agent and fires only for phones, where owners rarely test and where scam pages earn more. Look for RewriteCond rules on HTTP_USER_AGENT in .htaccess, PHP that checks for "mobile" or "iphone", and scripts that test the screen size or user agent. Reproduce it on a real phone using mobile data, logged out, arriving from a Google result.

Why can't I reproduce the redirect my customers see?

Most redirect hacks hide from site owners: they skip logged-in WordPress users, fire only for visitors arriving from a search engine, only on phones, or only once per IP address or browser. Test in a private window, click your site from a Google result, and use a phone on mobile data. The Network tab with Preserve log on shows each hop when it happens.

Can a WordPress redirect hack come back after cleaning?

Yes, and it often does within hours or days. The redirect is usually re-added by a backdoor: a hidden PHP file, a must-use plugin, a scheduled task or a rogue administrator account. Reinstall core, plugins and theme from clean sources instead of editing single files, check cron events and users, change every password and the salts, and close the way in by updating.

Will a redirect hack affect my Google rankings?

Yes. Google may label results "This site may be hacked", list the site in Safe Browsing so browsers show a red warning, or treat redirects shown only to search visitors as sneaky redirects. Visitors who land on scams leave and do not come back. Clean the site, request a review in Search Console's Security issues report, and rankings recover as Google recrawls the clean pages.