WordPress Site Redirecting Visitors to Spam? Here’s the Exact Fix

Your Google Analytics shows visitors landing on your homepage and then immediately bouncing. Your bounce rate has shot up overnight. Someone messages you to say your website “sent them to a dodgy site.” You test it yourself in a private browser and sure enough, within seconds of landing on your site, you’re redirected somewhere else entirely.

This is a malicious redirect hack one of the more visible (and more embarrassing) WordPress infections, because it actively harms every single person who visits your site.

Why You Might Not See the Redirect Yourself

A frustrating characteristic of this hack is that it often only fires under certain conditions:

• Only for visitors arriving from Google or other search engines (not direct visitors)
• Only for users on mobile devices
• Only on first visit (cookies are set to prevent the same user being redirected twice making it harder for you to reproduce)
• Only for users who are not logged into WordPress

This is why site owners sometimes dismiss reports from visitors they can’t reproduce it themselves. Always test in a completely fresh incognito window, and ideally from a mobile device using mobile data (not your home WiFi).

Where the Redirect Code Lives

Malicious redirects can be implemented in several places:

1. The .htaccess File

This is the most common location for redirect hacks on Apache servers. Attackers add redirect rules that fire before WordPress even loads. Connect via FTP, download your .htaccess from the root directory and open it in a text editor. Look for RewriteRule or Redirect lines pointing to external domains particularly anything conditional on user-agent, referrer, or device type.

2. WordPress Core Files

Particularly wp-includes/js/jquery/jquery.js, wp-blog-header.php and index.php. These files are loaded on every page request, making them ideal places to plant redirect code that fires every time.

3. Your Active Theme

The functions.php file in your active theme is a prime target. Hackers inject code that outputs a redirect header or JavaScript redirect at the top of every page.

4. JavaScript Injections

Rather than a PHP redirect, some hacks inject JavaScript code that executes in the browser. This might be in wp-includes/ JS files, or injected as inline script into your page output. JavaScript redirects often look like: window.location = "https://spamsite.com"

5. Rogue Plugins

Check your plugin list carefully. Attackers sometimes install a plugin that does nothing but redirect traffic, naming it something innocent like “Analytics Helper” or “Cache Booster.”

Step-by-Step Fix

Step 1: Clean Your .htaccess

Replace your .htaccess with a completely clean version. A standard WordPress .htaccess contains only the WordPress rewrite rules (you can generate a fresh one from Settings → Permalinks by just saving).

Step 2: Check Modified Files

Connect via FTP and sort all files by modification date. Find everything modified around the time the redirect started. Examine each one.

Step 3: Search for Redirect Functions

If you have SSH access, run:

grep -r "header(" /path/to/wordpress/ --include="*.php"
grep -r "window.location" /path/to/wordpress/ --include="*.js"
grep -r "document.location" /path/to/wordpress/ --include="*.js"

Step 4: Scan for Malware

Run a full Wordfence scan. Redirect hacks often come with additional malware the redirect itself is sometimes just the visible part of a larger infection.

Step 5: Check and Clean the Database

Some redirect hacks store their code in the database. In wp_options, look for any option values containing JavaScript with redirect functions, or PHP redirect code.

Step 6: Remove Rogue Plugins

Delete any plugin you don’t recognise. When in doubt, delete it legitimate functionality can always be replaced.

Step 7: Close the Entry Point

Update everything. Check your WordPress user list for accounts you don’t recognise. Review your server error logs to find when and how the attacker got in.

After Cleanup: Test Properly

Test the cleanup using a fresh incognito window. Test from mobile. Test by clicking a link to your site from a Google search result (you can do this by searching your own site name and clicking the result).

Wait 24–48 hours and test again some redirects fire on second or third visits, not the first.

If you’ve been through this process and the redirect keeps coming back, there’s almost certainly a backdoor involved. Get in touch persistent redirects are something we deal with regularly and we know exactly where to look.