WordPress Malware Redirect: Why Your Visitors Are Being Sent to Spam Sites

The hack you cannot see from your own computer

Redirect hacks are the most frustrating type of WordPress malware because they are designed to be invisible to the one person who would fix them — you.

Your visitor clicks a Google result for your site. Instead of landing on your page, they are instantly redirected to a spam site selling counterfeit pharmaceuticals, a phishing page that looks like a browser warning, or a page that attempts to install malware. The entire redirect takes a fraction of a second. Your visitor never even sees your site.

But when you visit the same URL? Your homepage loads perfectly. Your blog works. Your checkout works. You cannot reproduce the problem no matter how many times you try. So you assume the customer was mistaken, or their device was compromised.

They were not mistaken. Your site is hacked. The redirect is just smart enough to know when to hide.

How conditional redirects work

Modern WordPress redirect malware does not redirect everyone. That would be obvious and get cleaned quickly. Instead, it uses conditional logic to target specific visitors while leaving the site owner unaware.

Condition 1: Mobile users only

The malicious code checks the user agent string of the browser. If it detects a mobile device — iPhone, Android, iPad — it triggers the redirect. Desktop visitors see the normal site. Since most site owners check their site from a desktop computer, they never see the redirect.

This is devastatingly effective for sites where the majority of traffic is mobile. Your analytics might show a sudden spike in bounce rate on mobile, but you attribute it to a slow page or a design issue. You do not realise that mobile visitors are being stolen from you entirely.

Condition 2: First visit only

The malware sets a cookie on the visitor's browser after the first redirect. Subsequent visits from the same browser are not redirected. This means the victim cannot reproduce the problem — they visit again and the site works fine, making them think they imagined it. And it means you, the site owner, will never trigger the redirect because you have already visited your own site hundreds of times.

Condition 3: Referrer from search engines only

The code checks the HTTP referrer header. If the visitor came from Google, Bing, or another search engine, they get redirected. If they typed the URL directly or clicked a link in an email, they see the normal site. Site owners almost always visit their own site directly — not through Google — so they bypass the condition every time.

Condition 4: Not logged-in administrators

The malware checks for WordPress admin cookies. If you are logged into wp-admin, the redirect is suppressed. This is the most targeted condition — it specifically excludes the person most likely to notice and fix the problem.

These conditions can be combined. A redirect hack might only trigger for mobile users, arriving from Google, on their first visit, who are not logged in. That is an extremely specific subset of your traffic — but it can represent the majority of your actual visitors.

Where the redirect code hides

The malicious code can be in multiple locations, and sophisticated hacks use several of them simultaneously.

In your .htaccess file

The .htaccess file is the most common location because it is processed before WordPress even loads. The attacker adds Apache rewrite rules that check the user agent and referrer, then redirect matching requests to an external domain. These rules are often obfuscated — buried among legitimate rules, using encoded characters, or spread across multiple lines to be less obvious.

What to look for: Any RewriteRule or RewriteCond that references an external domain, checks for specific user agents (Googlebot, iPhone, Android), or checks the HTTP referer for search engine domains. If you did not add it, it does not belong there.

In your theme files

header.php, footer.php, and functions.php are prime targets because they load on every page. The attacker injects a small PHP snippet or a JavaScript tag that handles the redirect logic. In header.php, it is often added just before the closing </head> tag. In functions.php, it is typically appended at the bottom of the file.

What to look for: Any <script> tag pointing to a domain you do not recognise. Any PHP code containing base64_decode, eval(, or gzinflate. Any code that checks $_SERVER['HTTP_USER_AGENT'] or $_SERVER['HTTP_REFERER'] and then calls header('Location: ...').

In the WordPress database

Some redirect hacks do not modify files at all. Instead, they inject JavaScript into the database — in post content, widget text, or custom fields. The most dangerous variant changes the siteurl or home values in the wp_options table to a malicious domain, which causes WordPress itself to redirect every request.

What to look for: Check wp_options for the siteurl and home rows — they should contain your actual domain. Search the wp_posts table for <script tags or <iframe tags that reference external domains. Check widget content in wp_options under widget_text entries.

In JavaScript files

The attacker appends malicious JavaScript to a legitimate JS file — often jQuery or a popular plugin's script file. The injected code uses window.location or document.location to perform the redirect on the client side. Because the redirect happens in JavaScript, it is invisible to server-side scanning tools that only inspect PHP files.

What to look for: Check the modification dates of JavaScript files in your theme and plugin directories. Any JS file modified recently that you did not change is suspicious. Open it and scroll to the bottom — injected code is almost always appended rather than mixed into the existing code.

How to clean a WordPress redirect hack

Step 1: Take a full backup

Back up everything — files and database — before you start cleaning. Store the backup off-server. You need it in case cleaning goes wrong, and you may need it later to identify how the attacker got in.

Step 2: Check and clean .htaccess

Download your .htaccess file and read every line. Remove any rules you did not add. If in doubt, replace it entirely with the default WordPress rules and add your known-good custom rules back one at a time. Also check for .htaccess files in subdirectories — the attacker may have created additional ones in /wp-content/, /wp-includes/, or /wp-admin/.

Step 3: Check your database

Open phpMyAdmin or connect to your database directly. Verify that siteurl and home in wp_options contain your actual domain. Search for <script in wp_posts.post_content and wp_options.option_value. Any external script tag you did not add should be removed.

Step 4: Scan and clean theme files

Compare your theme files against a fresh copy from the developer. Pay special attention to header.php, footer.php, functions.php, and index.php. Look for injected code at the very top or very bottom of each file. If you use a premium theme, download a fresh copy and compare file sizes — a significantly larger file indicates injected code.

Step 5: Replace WordPress core files

Download a fresh copy of your WordPress version from wordpress.org and replace the entire wp-admin and wp-includes directories. This eliminates any malware hidden in core files without affecting your content in wp-content.

Step 6: Scan plugin files

Check every plugin for files that do not belong. Compare against fresh copies from the WordPress plugin directory. Delete any plugin you do not actively use. For plugins you keep, delete and reinstall them from the official source.

Step 7: Reset all credentials

Change your WordPress admin password, FTP password, database password (update wp-config.php), and hosting panel password. Replace the security salts in wp-config.php with fresh values from the WordPress salt generator. This forces all existing sessions to expire.

Step 8: Install security and harden

Install a reputable security plugin. Enable two-factor authentication. Disable the file editor. Set correct file permissions. Consider a web application firewall from Sucuri or a similar service that can block known malware patterns before they reach your server. The WordPress hardening guide covers additional measures.

How Uptrue HTTP monitoring detects redirect hacks

Uptrue's HTTP monitoring is particularly effective against redirect hacks because of how it makes requests. The monitor comes from outside your network, with no WordPress admin cookies, no browsing history, and a standard user agent. It looks exactly like the type of visitor that triggers the redirect.

Step 1: Set up an HTTP monitor with redirect detection

1. Sign up at uptrue.io/signup (free plan available)
2. Click Add Monitor from your dashboard
3. Select HTTP/HTTPS as the monitor type
4. Enter your homepage URL
5. Set expected status to 200
6. Set the check interval to 1 minute
7. Configure alerts — Slack, email, or Microsoft Teams

If your site redirects the monitoring request to a different domain, the final URL will not match the expected domain. Uptrue detects this as a failure and alerts you immediately. A redirect that sends visitors to spam-pills-site.com is caught within 60 seconds.

Step 2: Add keyword monitoring for JavaScript-based redirects

1. Add a Keyword monitor for your homepage
2. Set the keyword to your site name or a phrase that always appears on your homepage
3. Set the check type to "Page must contain"
4. Set the interval to 1 minute

Some redirect hacks use JavaScript that executes after the page loads. The server returns a 200 with your page content, but JavaScript immediately redirects the browser. Server-side HTTP monitoring catches the initial response. If the page content has been replaced or modified with injected scripts, keyword monitoring detects that your expected content is missing.

Step 3: Monitor your highest-value pages

Redirect hacks do not always affect every page. Sometimes only specific pages are targeted — your most-visited pages, your Google Ads landing pages, or your checkout page. Set up individual monitors for:

• Homepage — the most common redirect target
• Landing pages receiving paid traffic — redirects here cost you money on every click
• Checkout page — redirects here directly cost you sales
• Contact page — redirects here lose you leads
• Top organic pages — redirects here lose you Google traffic and rankings

Step 4: Configure alerts for maximum speed

A redirect hack is an active attack. Every minute it runs, visitors are being sent to a malicious site that may be phishing for their credentials or installing malware. Speed matters.

• Slack — instant notification in a dedicated incident channel
• Microsoft Teams — immediate visibility
• Email — written record and backup alert
• Webhook — trigger your incident management workflow automatically

Preventing redirect hacks

Update everything, always

Outdated plugins and themes with known vulnerabilities are the primary entry point. Update the day patches are released. Delete anything you are not using. Every inactive plugin is attack surface with zero benefit.

Use strong, unique passwords

Brute-force attacks on wp-login.php are constant. Use passwords that are at least 16 characters, randomly generated, and unique to each site. A password manager is not optional — it is essential.

Enable two-factor authentication

Two-factor authentication stops credential-based attacks even when the password is compromised. There is no excuse not to use it on every admin account.

Limit login attempts

Use a security plugin that limits failed login attempts and temporarily blocks IPs that exceed the threshold. This slows down brute-force attacks from seconds to days.

Use file integrity monitoring

Security plugins like Wordfence can compare your core files against the official WordPress repository and alert you when a file has been modified. This catches .htaccess modifications and injected code in theme files.

Back up daily

If the worst happens, a recent backup means you can restore a clean version of your site within minutes. Store backups off-server. Test your restore process before you need it in an emergency.

Your visitors might be getting redirected right now

That is the entire problem with redirect hacks. You cannot see them. You visit your site and it works. You test on your phone and it works — because you have visited before and the cookie is set. You ask a colleague to check and they say it works — because they visited directly instead of through Google.

Meanwhile, every new visitor arriving from a Google search on a mobile device is being sent to a spam site. Your bounce rate is climbing. Your conversions are dropping. And if the redirect destination is malicious enough, Google will flag your site with a "This site may be hacked" warning that suppresses your search results entirely.

Uptrue checks your site every 60 seconds from outside, with no cookies and no admin session — exactly like a new visitor from Google. If your site redirects to a domain that is not yours, you know in under a minute. Before your ad budget is wasted. Before Google flags your site. Before your customers lose trust.

Frequently asked questions