Home » Blog » Your Site Redirects Visitors But Looks Fine to You — Here’s Why

Your Site Redirects Visitors But Looks Fine to You — Here’s Why

A customer emails you. They say your site sent them to some sketchy page about a browser update. You open your site. It loads fine. You click around. Everything works.

So you assume they made a mistake, or their phone had a virus, or they clicked an ad somewhere else.

Then a second person says the same thing. Then your traffic drops.

Here is the uncomfortable part: they are almost certainly right, and the reason you cannot see it is that the malware was built specifically so you cannot see it.

What Is a WordPress Redirect Hack?

A WordPress redirect hack is malicious code injected into your site’s files or database that sends visitors to pages the attacker controls. Those pages are usually spam, gambling sites, fake pharmacies, crypto scams, or phishing forms. The key feature is that the redirect is conditional — it checks who the visitor is before deciding whether to fire.

That last sentence is the whole story. Older malware redirected everyone. Modern malware is picky.

It looks at whether you are logged in. It looks at what device you are on. It looks at where you came from. Only when the visitor matches the right profile does it send them away. Everyone else gets a perfectly normal website.

Why You Can't See It

You cannot see the redirect because the malware checks whether you are logged in and skips you on purpose. It also often checks your device type and where you arrived from. Site owners visit their own site while logged in, on desktop, by typing the address directly — which is exactly the profile the malware ignores.

This is called cloaking. It has one goal: keep the site owner calm while the site quietly earns money for someone else.

Here are the filters that show up most often.

What the malware checks	What it does	Why attackers use it
Are you logged in?	Skips logged-in users entirely	The owner sees a clean site and never investigates
Where did you come from?	Fires only when the visitor arrives from Google, Bing, or social media	Search traffic is the most valuable to monetize
What device is this?	Fires only on mobile	Mobile users have fewer ad blockers and are easier to trick
Have you been here before?	Fires only on the first visit	Repeat visitors and returning owners see nothing
What is your user agent?	Skips known scanner and search engine bots	Avoids being flagged by security tools

Some campaigns get very specific. Fake browser-update lures have been documented targeting visitors in the US, UK, and Australia in particular — which matters if that is where your customers are.

There is also a technical reason remote scanners miss these. If a redirect is built into your .htaccess file with conditions attached, an external scanner’s request will not match those conditions, so the scanner sees a clean page and reports no problem. A clean scan result is not proof of a clean site.

How to Actually Test Your Site

Stop testing while logged in. That is the single change that reveals most of these.

Work through this list in order:

Open a private or incognito window. Make sure you are fully logged out, not just in a different tab.
Search for your site on Google and click the result rather than typing your address. This triggers referrer-based redirects that direct visits never will.
Test on a real phone, on mobile data rather than your home Wi-Fi. Many redirects are mobile-only.
Ask someone in another country to check if your audience is spread across the US, UK, Canada, or Australia. Some campaigns are geo-targeted.
Check Google Search Console. Look at the Security Issues report and Manual Actions. Also check whether pages you never wrote are showing up in your indexed pages.
Search Google for site:yourdomain.com. If you see listings for pills, casinos, or products you do not sell, that is SEO spam sitting in your database.
If you are comfortable in a terminal, use curl to request your homepage while pretending to be a mobile browser arriving from Google. Changing the user agent and referrer headers lets you reproduce the exact conditions that trigger the redirect.

If any of these show a redirect, your site is infected. Not “maybe.” It is.

Where the Malware Usually Gets In

Almost always through a plugin or theme. Not through WordPress itself.

The numbers on this are lopsided. According to Patchstack’s State of WordPress Security in 2026, plugins accounted for 91% of the 11,334 new vulnerabilities reported across the WordPress ecosystem in 2025. Themes made up nearly all of the rest. WordPress core itself had six low-priority issues in the entire year.

So the software people worry about updating is the safest part of the stack. The parts they forget about are the problem.

Outdated plugins

Roughly 250 new plugin vulnerabilities are disclosed every week in 2026. About 43% of them can be exploited without any login at all, and around 23% are still unpatched a month after being made public.

Public disclosure is a starting gun that fires for both sides. Security researchers report that attackers begin scanning for vulnerable installs within about four hours of a disclosure, while official patches often take a week or two to arrive. That gap is where most sites get hit.

Abandoned plugins

An estimated 35% of plugins in the WordPress.org repository have not been updated in over 12 months. Plenty of those still have hundreds of thousands of active installs.

An abandoned plugin does not stop working. It just stops getting fixed. Any vulnerability discovered after the developer walked away stays open permanently.

WordPress shows you a warning — “Not tested with the latest 3 major releases of WordPress” — and almost nobody acts on it.

There is a nastier version of this too. Attackers have been known to buy abandoned plugin projects outright and push a backdoored update to everyone still using it. Your site accepts it as a normal update, because technically it is one.

Not all plugin categories carry the same risk. A 217-plugin audit published in 2026 found the four highest-risk categories were page builders, WooCommerce extensions, membership and LMS plugins, and marketing or popup plugins — with 41% of marketing and popup plugins going more than a year without an update. The same audit found caching and security plugins scored among the lowest risk, which is the opposite of what most people assume.

Plugin category	Risk level	Why
Page builders	High	Huge codebase, deep site access, frequent CVEs
WooCommerce extensions	High	Handle payments and customer data, often small developers
Membership / LMS	High	Complex permission logic, many edge cases
Marketing / popup	High	41% abandoned, low maintenance incentive
Caching	Low	Small surface area, actively maintained
Security	Low	Actively maintained, scrutinized closely

Nulled themes and plugins

If you downloaded a premium theme for free from a site that was not the developer’s, assume it is compromised.

Nulled software is a cracked copy with the license check removed. Whoever removed the license check had full access to the code and no reason to be nice about it. Backdoors, obfuscated loaders, credential stealers, and hidden spam links are all common. The code is usually encoded so it does not look obviously wrong when you open the file.

And because nulled software never receives real updates, any vulnerability in it stays open forever. You get reinfected, clean it, and get reinfected again, because the door was never a hole in your security. It was a feature.

Where the Bad Code Actually Hides

Redirect malware rarely sits in one place. It usually installs a visible part and a hidden part, so that removing the obvious piece does nothing.

The common hiding spots:

Your active theme’s header.php, footer.php, or functions.php — often in the first or last twenty lines, where it blends in
The wp_options database table — especially the siteurl and home values, which should match your real domain exactly. Payloads also get stored here as long encoded blobs.
The .htaccess file — look for RewriteRule or Redirect lines you did not add
wp-config.php — a healthy one is roughly 3 to 5 KB. If yours is dramatically larger, something is in there.
The mu-plugins folder — must-use plugins load automatically and never appear in your normal plugins list. This location has become much more common.
wp-content/uploads/ — should only contain images, PDFs, and media. PHP files here with harmless-sounding names like social-icons.php or thumb-handler.php are backdoors.
The wp_users table — hidden administrator accounts added for later access
Core files like wp-blog-header.php or files inside wp-includes, which should be byte-identical to a fresh WordPress download

If you are comfortable with a terminal, searching your files for eval, base64_decode, gzinflate, and str_rot13 will surface most obfuscated payloads quickly. These functions have legitimate uses, so a match is a lead, not a verdict.

Why Deleting the Bad File Doesn't Work

This is the part that catches almost everyone.

You find the injected JavaScript in your theme’s header.php. You delete it. The site looks clean. Two hours later, it is back.

Here is why. The visible JavaScript was not the malware. It was the output of the malware. The actual loader is sitting encoded in your wp_options table with a scheduled WordPress cron job that rewrites the theme file on a timer. You removed the symptom and left the engine running.

Some newer campaigns go further. One documented variant stores its payload as an encrypted blob in the database and writes a temporary PHP file into the uploads folder only at the moment a request comes in, then deletes it immediately. Scanners that run once an hour almost never catch it in the act.

This is why partial cleanup is the most common failure mode in redirect infections — and why “I deleted the file and it came back” is one of the most common things people say when they finally ask for help.

How to Clean It Properly

If you are going to do this yourself, do it in this order. Skipping steps is what causes reinfection.

Take a full backup first — files and database, even though it is infected. You need something to compare against and roll back to if you break the site.
Put the site in maintenance mode. Stop serving redirects to real customers while you work.
Replace WordPress core. Download a fresh copy from wordpress.org and replace everything except wp-content and wp-config.php.
Delete and reinstall every plugin and theme from official sources. Do not clean them in place. Do not reinstall anything nulled.
Check the database. Verify siteurl and home, remove unknown wp_options entries and scheduled tasks, and check wp_users for administrator accounts you did not create.
Reset .htaccess to the default WordPress version.
Scan wp-content/uploads/ for PHP files and remove them.
Rotate every credential — database password, the security salts in wp-config.php, all admin passwords, hosting panel, SFTP.
Fix file permissions. Files at 644, directories at 755. Never 777.
Disable PHP execution in the uploads folder so a dropped file cannot run.
Retest properly using the incognito, from-Google, and mobile checks above. Then request a review in Google Search Console if you were flagged.

If you get partway through this and lose confidence, stop. A half-finished cleanup that leaves one backdoor behind is worse than not starting, because the reinfection will look like a new attack and you will chase the wrong thing.

Doing It Yourself vs. Getting It Handled

Both are reasonable. They fit different situations.

	Cleaning it yourself	Professional cleanup
Cost	Free, plus your time	Paid service
Time	Several hours to several days	Usually same-day
Database inspection	Often skipped, which is where reinfection starts	Standard part of the process
Finding every backdoor	Difficult — they are designed to be missed	Systematic search across files, database, and cron
Best when	Simple site, recent clean backup, comfortable with SFTP and phpMyAdmin	Store or business site, no clean backup, or it has come back before

If your site takes payments or stores customer information, the calculation changes. A redirect hack on a WooCommerce store is not just an annoyance — visitors are being sent to phishing pages from a domain that has your name on it, which becomes a customer trust problem and, depending on your market, a legal one.

Stopping the Next One

Cleaning the site fixes today. These habits fix next quarter.

Remove plugins you do not use. Deactivated is not removed. Deactivated plugin code still sits on your server and can still be reachable.
Check the “last updated” date before installing anything. More than a year is a warning sign. More than two years is a no.
Audit what you already have every few months. Anything abandoned needs replacing, not tolerating.
Never install nulled software. The savings are not real.
Run a firewall that virtual-patches. Services like Patchstack and Wordfence can block exploitation of a newly disclosed vulnerability before the developer ships a fix, which closes the four-hour-versus-two-week gap.
Set up file integrity monitoring so you find out when a file changes instead of when a customer complains.
Test your backups by actually restoring one. An untested backup is a guess.
Log out and check your own site from a phone, from a Google search, once a month. It takes ninety seconds.

Where WebFixOn Fits

We do WordPress maintenance, security hardening, and malware recovery for businesses in the US, UK, Canada, and Australia.

If your site is redirecting, we will find every part of it — files, database, cron jobs, hidden admin accounts, and the plugin or theme that let it in — rather than removing the piece you can see and hoping. If it has already been cleaned once and come back, that is usually a sign the loader was left behind, and that is a specific thing to go looking for.

For sites that are currently fine, ongoing maintenance means outdated and abandoned plugins get caught during a routine check rather than during an incident.

The redirect is not the problem. It is the receipt.

Web Fix On