If you’re reading this, something is probably wrong with your site right now. Maybe a customer told you they were sent to a sketchy page when they clicked your link, maybe you opened your own site on your phone and ended up on a casino landing page. or perhaps your traffic from Google is cratering and you can’t figure out why.
First, take a breath. I’m here to tell you that not only is this is a common problem…it’s also very fixable. But the fix is almost never “delete the bad file and move on”, and understanding why is the difference between getting your site back for good and watching the same problem return in three weeks.
A redirect attack means an attacker has injected code somewhere on your site that sends visitors to a different URL, usually one they profit from. That destination might be a fake pharmacy, an online casino, an adult site, a fake virus warning, a fake Google reCAPTCHA page, or a chain of redirect domains that eventually lands on a malware download.
The injected code can live in many places. That’s the first thing to understand: there’s no single file to find. Redirect malware can hide in WordPress core files, in your active theme, in a plugin, in wp-config.php, in .htaccess, in your database, in a fake “must-use” plugin inside /wp-content/mu-plugins/, or in scheduled tasks (WordPress cron jobs) that re-inject the payload after you clean it up. Sophisticated attackers plant code in two or three of these places at once, so removing one copy doesn’t stop the redirect.
That’s why DIY cleanups so often fail; the owner finds something suspicious, deletes it, and the site looks clean for a day or two…and then the redirect comes back, because the attacker left a hidden mechanism specifically to restore the payload.
Not all redirect malware behaves the same way. The pattern often points to which malware family is involved and where to look first.
The simplest case: every visitor gets bounced to spam. This is usually injected JavaScript in the theme's header.php or functions.php, a malicious entry in the wp_options table, or PHP that runs on every page load. It's loud, easy to notice, and easy for the attacker, but it gets caught fastest because everyone sees it.
The site loads normally on your laptop, but customers on phones get sent to a casino. This is intentional; the malware checks the user-agent string and only fires for mobile devices because the attacker knows the site owner is more likely to test on desktop. If a customer says "your site is broken on my phone" and you can't reproduce it on your laptop/desktop, mobile-targeted redirect malware is a leading suspect.
You type your URL directly into the browser and your site loads fine; you click a Google result for your business but you get redirected. This is one of the nastiest variants because the owner almost never sees it. The malware checks the HTTP referrer and only redirects visitors arriving from search engines. Meanwhile, your Google rankings are quietly torching, because Google's crawler is being shown a different page than your real visitors.
The redirect only fires once per visitor (using a cookie), or only at certain hours, or only after a few page views. Same logic as the mobile case: make it harder for the owner to reproduce, easier to victimize real visitors.
These destinations almost always point to organized injection campaigns. Pharma hacks (fake Canadian pharmacies, weight-loss pills, erectile dysfunction drugs) are often tied to long-running spam SEO operations that quietly inject hidden pages into your site to rank in Google before redirecting clicks. You may have hundreds of spam URLs indexed under your domain that you've never seen.
The visitor lands on a page telling them to "verify you're human" by pressing Windows+R and pasting a command, or to "fix" their browser by running a script. This is a current, active campaign; it's a delivery vector for information-stealer malware on the visitor's machine. If your site is doing this, every visit is potentially infecting a real person and the urgency to fix it is much higher than a typical SEO spam case.
The SocGholish / FakeUpdates family is one of the most prolific. The injected JavaScript is often heavily obfuscated and conditionally loaded, which is part of why scanners miss it.
When I investigate a malicious wordpress redirect, I look in roughly this order:
Theme files. header.php, footer.php, functions.php, and any file that runs on every page load. Look for long base64 strings, eval() calls, or <script> tags pointing to a domain you don’t recognize.
The wp_options table. The siteurl and home rows should match your real domain. I’ve seen them rewritten to point to attacker infrastructure. The active_plugins row sometimes lists plugins that don’t exist in /wp-content/plugins/; those “ghost” plugins are often the persistence mechanism.
/wp-content/mu-plugins/. Most site owners don’t know this folder exists. Anything dropped in there auto-loads on every request, with no UI to disable it. It’s a favorite hiding spot.
wp-config.php. Sometimes modified to include an external file, or to define constants that change site behavior.
.htaccess. Server-level rewrite rules can redirect traffic before WordPress even loads. These rules can be conditional on user-agent or referrer, which is how mobile-only and search-only redirects often work.
The database. Posts, custom post types, and especially widget content can contain injected <script> tags. The wp_posts table is huge and easy to hide things in.
WordPress cron. Scheduled events that run reinjection scripts on a timer. Clean the files, and a few hours later, cron writes them back.
Server-level cron and PHP-FPM/Apache config. Rare, but on a compromised hosting account I’ve seen attackers add OS-level scheduled tasks that no WordPress scanner can ever see.
This is the most disorienting part for owners. You log in, click around, everything seems fine but then…you get an angry email from a customer.
Three reasons this happens:
You’re logged in. A lot of redirect malware specifically excludes WordPress administrators because the attacker doesn’t want you to notice.
You visit the site directly. As mentioned above, malware that only fires for search-engine visitors is invisible if you type the URL or use a bookmark.
You’re on a familiar device. Cookies set on your previous visits can suppress the redirect, and IP-based exclusions can keep your office network “safe” while everyone else gets hit.
The right way to test is from a different network (your phone on cellular) in a private/incognito window by clicking through a Google search result. If you don’t reproduce it that way, try a few different user-agents using browser developer tools.
Most WordPress security plugins compare your files to a database of known malware signatures. That works for old, well-documented infections but it doesn’t work well for:
Code that’s been newly obfuscated or randomized per-site (we’re seeing more and more of this with hackers using AI now)
Redirects that live in the database, not in files
.htaccess rules and server-level configurations
Conditional payloads that only trigger for specific visitors
Backdoors disguised as legitimate plugin code
Malicious mu-plugins (some scanners don’t check that folder)
A clean scan does not mean a clean site; it means the scanner didn’t find anything it recognized. Those are different statements.
A redirect infection has three layers, and a real cleanup has to deal with all of them:
Layer 1 — The visible payload. This is the actual code that performs the redirect and what most cleanups stop at (because dealing with layer 2 takes real expertise).
Layer 2 — The persistence mechanism. The hidden backdoor, fake admin user, malicious cron job, or compromised credential the attacker uses to put the payload back. Miss this and the redirect returns within days.
Layer 3 — The entry point. The vulnerable plugin, weak password, leaked API key, or compromised hosting account that let the attacker in originally. Miss this and a different attacker walks in through the same door next month.
If a cleanup only addresses Layer 1, your symptons with be back within a few days, most of the time less.
Most WordPress compromises trace back to one of these:
If your site has been redirecting for more than a few days, here’s what’s likely happening in the background, whether you can see it or not:
Google rankings drop. Search engines see the spam content and the redirects. Some sites lose positions within days and recovery after cleanup takes weeks to months.
Search Console security warnings. Google may show “This site may be hacked” or red interstitial warnings to users clicking your results. Your click-through rates collapse.
Google Ads suspended. If you advertise, your account can be paused for serving malicious content. Reinstating an Ads account after a malware suspension is slow and frustrating.
Email deliverability damage. If your site shares a domain with your business email and that domain ends up on threat-intelligence blocklists, your invoices start going to spam.
Customer trust. A customer who got bounced to a casino from your site doesn’t come back, and they tell other people.
Payment processor risk. For e-commerce sites, a malware finding can trigger account reviews from Stripe, PayPal, or your merchant bank.
The cost of a redirect infection is rarely the cleanup. It’s the lost traffic, lost trust, and lost months of SEO work. This is part of a broader class of malicious redirect attacks that hijack website traffic.
Web developers and hosting support are good at what they do. They are not, however, incident responders. The skill sets are different.
Call a cybersecurity specialist when:
The redirect comes back after a cleanup
You can’t reproduce the redirect yourself but customers keep reporting it
Search Console shows a security issue
You see admin users you don’t recognize, or admin emails you didn’t set
Your hosting provider has emailed you about “suspicious activity” or suspended your account
Your site is part of a larger business operation (e-commerce, lead generation, B2B reputation) where downtime or trust loss has real cost
You’ve been told to “just restore from backup” but you don’t know when the infection started, which means your backups may also be infected
The infection involves more than one site on your hosting account
A web developer can rebuild a site. A specialist’s job is to figure out what happened, how they got in, what else they touched, and how to make sure they can’t get back in…and then document it so you have a record if a customer, insurer, or payment processor asks.
Every investigation is different, but a typical engagement covers:
- Reproducing the redirect across multiple devices, networks, user-agents, and referrers, and capturing the full request chain
- Reviewing all WordPress admin users for unauthorized accounts, recent privilege changes, and suspicious email addresses
- Auditing every active and inactive plugin and theme against known vulnerability databases, and inspecting any custom or "ghost" plugins that don't match a public source
- Searching the filesystem for known and unknown backdoor patterns, recently modified files, files with mismatched timestamps, and suspicious code in mu-plugins, theme files, and uploads
- Reviewing wp-config.php, .htaccess, and any server-level configuration for tampering
- Querying the database for injected scripts, modified `siteurl`/`home` values, suspicious options, spam posts, and orphaned content
- Checking WordPress cron and server cron for scheduled reinjection
- Reviewing access and error logs (where available) to identify the original entry point and the timeline of the compromise
- Checking Search Console, Safe Browsing, and major blocklists for the current reputation status of the domain
- Documenting everything found, in plain English, so you have a record of what happened
After cleanup, the work isn’t finished. Hardening the site against the same class of attack (by closing the entry point, rotating credentials, removing unused plugins and themes, locking down file permissions, and putting monitoring in place) is what prevents the next call.
Before calling anyone, a few things you can verify on your own:
Open /wp-admin/users.php. Look at every user with administrator role. Recognize all of them? Anyone with a recent registration date you don’t remember creating?
Search Console → Security Issues. Log into Google Search Console for your domain. The Security Issues panel will tell you if Google has flagged anything.
Check Safe Browsing. Visit https://transparencyreport.google.com/safe-browsing/search and enter your domain.
Try to reproduce the redirect. From your phone on cellular, in an incognito window, click a Google search result for your business. Does it redirect?
Check your hosting account for sites you don’t remember. On shared hosting, attackers sometimes add subdomains or addon domains.
If any of those turn up something concerning, save the evidence (screenshots, URLs, timestamps) before you start changing things. It helps the investigation.
If your site is actively redirecting and you have customers, leads, or revenue tied to it, the longer you wait the more it costs — not in cleanup fees, but in trust and SEO damage that’s slow to recover.
Stonegate Web Security handles WordPress redirect cases as full investigations: find the redirect, find what’s keeping it there, find how they got in, and close the door behind them. If you’d like to talk through what’s happening with your site, get in touch and I’ll take a look.
You can also read more about WordPress malware removal, website security hardening, website security checkups, and ongoing security monitoring.
Written by Stonegate Web Security. If your site is redirecting right now and you’d like a second opinion, get in touch.