A malicious redirect is one of the most damaging things that can happen to a WordPress site. A visitor opens your page and lands somewhere else entirely — a spam shop, a fake prize page, or a malware download. The traffic you paid for ends up on someone else’s site, and your domain is the one that gets the bad reputation.
What makes these attacks so hard to deal with is not the redirect itself. It’s that you usually can’t reproduce it. You open your site and everything looks perfectly normal, while a customer emails you a screenshot of a page you’ve never seen.
Why the redirect never fires for you
Injected redirect code is almost always conditional. The attacker doesn’t want the site owner to notice, because a redirect that fires for everyone gets cleaned up within hours. So the code checks who is asking before it does anything:
- Logged-in users are skipped. If you have a WordPress session cookie, nothing happens.
- Only visitors from search engines are targeted. The code looks at the referrer, so typing your own URL in the address bar never triggers it.
- Only mobile devices are targeted. The user agent decides, and you test on a desktop.
- Once per visitor. A cookie is set after the first redirect, so even if you do catch it once, you can never show it to anyone else.
This is why “I checked and the site is fine” means very little with redirects. Your own visit is the least likely one to be attacked.
Where the redirect is hiding
There are only a handful of places the code can live, and it helps to know all of them before you start looking:
- PHP files — a few injected lines at the top of a theme’s
functions.php, a plugin file, orwp-config.php. - The database — a script injected into post content, into
wp_options, or thesiteurlandhomevalues pointed at another domain. .htaccess— rewrite rules that redirect based on user agent or referrer, often far below a lot of blank lines so you don’t scroll down to them.- mu-plugins — a folder many site owners never open, where a single file runs on every request without appearing in the plugin list.
- JavaScript — an injected script tag or a compromised third-party file that redirects in the browser, leaving the server logs clean.
Checking for it by hand
To catch a conditional redirect you have to pretend to be the visitor it targets. Open your site in a private window, on a phone, and arrive from a Google search result rather than by typing the address. If you have shell access, you can ask the server the same question directly and watch for a Location header:
curl -sI -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" \
-e "https://www.google.com/" https://example.com/ | grep -i "^location"Then check the obvious hiding places: look at the bottom of .htaccess, confirm that siteurl and home in the options table still point at your own domain, and list the mu-plugins folder. It’s also worth searching your files for the usual obfuscation helpers, since injected redirects are rarely written in plain sight:
grep -rlE "base64_decode|eval\(|gzinflate|str_rot13" wp-content --include="*.php"This works, but it only tells you about the moment you looked. A conditional redirect can sit quiet for days and then fire on a Monday morning for mobile visitors only.
Detecting it automatically, when a real visitor hits it
This is exactly the gap monitoring fills. Instead of you trying to guess the attacker’s conditions, the site itself watches every request that real visitors make.
BugMonitor checks the response headers at the end of every request. If a Location header is being sent and its domain is not your domain, that is logged immediately as a critical event — together with the target URL, the cookies and the headers of that request. You get to see not just that a redirect happened, but the exact conditions under which it fired, which is usually what tells you where the injected code is checking.
Because the check runs on real visits, it doesn’t matter that the redirect skips logged-in administrators — the first genuine visitor who gets redirected creates the report. Redirect loops are caught the same way. You can read more about what the event contains on the malicious redirect error insight page, and about how real visits are monitored in our post on Real User Session Monitoring.
Detection is half the job — prevention is the other half
Finding the redirect tells you that something already got in. Keeping it out is a separate problem, and it is worth solving at the same time, because a site that was injected once is usually injected again within days. Must-Have Security approaches it from the other end: it treats the ability to write executable code as a permission of its own, separate from being a WordPress administrator. A request that tries to write a PHP file into your theme, your plugins or your uploads folder is refused before the file ever reaches the disk, and the attempt is logged. Since a malicious redirect has to be written somewhere first — into a PHP file, an .htaccess, or a new file in mu-plugins — blocking that write removes the injection step entirely. It also runs a malware scan, so anything already on disk is found and removed rather than waiting for a visitor to trip over it.
What to do when you find one
Don’t just delete the redirect line and move on. The redirect is the symptom, and whatever wrote it is still there. Replace modified files from clean copies rather than editing them, reinstall WordPress core and any affected plugin or theme, and check the whole list of hiding places above — injected code is almost never in only one place. Then change every administrator password and rotate the security keys in wp-config.php, so any session the attacker still holds is invalidated. Finally, update everything: the overwhelming majority of these injections arrive through a known vulnerability in an outdated plugin.
And once it’s clean, leave something watching. The next redirect will be just as invisible to you as the last one was.
Download BugMonitor for free
Instantly detect and report layout problems, functional issues, JavaScript errors, SEO problems, network- and PHP errors.
