My WordPress site is redirecting to spam — how to fix it

What a redirect hack actually does

Your site loads normally for you, but visitors — or a slice of them — get bounced to a spam or scam site. That’s a redirect hack. It’s especially damaging because it steals the traffic you worked to earn and, once Google notices, it can flag your site and tank your rankings.

Why it hides from you

These hacks are usually conditional. The injected code checks who’s visiting: it might only redirect people coming from Google, only mobile users, or only logged-out visitors. So you log in, see a perfectly normal site, and assume nothing’s wrong — while your customers are being sent elsewhere.

Where the code lives

The redirect is typically injected into one or more of: the .htaccess file, wp-config.php, your theme’s header or footer, a plugin file, or rows in the database. Sophisticated ones spread across several of these so removing one doesn’t stop it.

Cleaning it

Scan those locations, remove the malicious code, and replace any compromised core/plugin/theme files with clean copies. Reset all passwords and regenerate salts. Then clear your WordPress cache, any server-level cache, and your CDN. The old redirect is often cached, and it keeps firing even after the code is gone.

What this means for you

If your WordPress site is redirecting to spam, treat it as urgent — every hour it’s live is lost traffic and eroding trust with Google. Find every injection, not just the first, and close the entry point. This is one of the most common hacks I clean, and the ones that come back are always the ones where a second injection was missed.

Why you can't just look and see it

Most site owners open their homepage, see nothing wrong, and close the ticket. That's the trap. A WordPress site redirecting to spam almost never redirects for the person checking it. The hacker built it that way on purpose. Logged-in admins, and often anyone hitting the site directly by typing the URL, get served the normal page.

The redirect only fires under specific conditions. Maybe it's search traffic only. Maybe it's mobile only. You have to stop checking the way you normally browse your own site. Instead, you need to recreate the exact conditions a real victim would hit. That means new sessions, different devices, and traffic sources you don't normally use yourself.

Testing your site the way Google sees it

A lot of WordPress redirecting to spam cases specifically target search engine traffic. The malicious code checks the referrer header. If it sees Google, Bing, or another search engine sending the visitor, it fires the redirect. Direct visits and bookmarked links pass through untouched.

You can approximate this with a "fetch as Googlebot" style tool, or by searching your own site on Google and clicking the actual result instead of typing the URL. Don't test from a link you already have open. Start cold, from a real search results page, exactly like a customer would.

Some infections go further and check the user agent string itself, redirecting anything claiming to be a crawler. That version is nastier because it can quietly poison how Google indexes and ranks your pages, on top of hijacking human visitors. If you run any paid search campaigns, this pattern is worth checking first.

Use a private, logged-out browser session

Your regular browser is full of WordPress cookies. If you're logged into wp-admin in another tab, some infections detect that and skip the redirect entirely, just for you. It's a simple check on their end, and it's remarkably effective at hiding the problem from the one person capable of removing it.

Open a fresh private or incognito window. Clear cookies first if you've logged into the dashboard recently. Then load the site as a total stranger would, with no history, no cookies, and no session tied to your account. This alone catches a surprising share of WordPress redirecting to spam cases that "can't be reproduced."

Check from an actual phone, not just desktop

Mobile-only redirects are common because mobile traffic converts better for the scam pages hackers are pushing. Weight-loss pills, fake software alerts, adult content, gift card scams — these pages are built and tested for phone screens, so the injected code often targets phones specifically.

Resizing your desktop browser window isn't enough. The check is usually done by reading the user agent string, not by measuring screen width. Grab an actual phone, turn off WiFi so you're on mobile data, and visit the site cold. If you have access to a second phone on a different carrier, test that too. Some infections narrow the redirect down to specific mobile browsers or carriers to stay under the radar even longer.

What to look for inside .htaccess

The .htaccess file controls how your server routes requests, which makes it a favorite hiding spot. In a clean WordPress install, this file is short and mostly generated automatically by WordPress itself. Anything unfamiliar sitting above or below the standard WordPress block deserves a close look.

Watch for rewrite rules that reference conditions like HTTP_REFERER or HTTP_USER_AGENT, especially ones checking for "google," "bing," or "yahoo." Also watch for blocks of text that look encoded or scrambled rather than readable. Legitimate .htaccess rules are almost always plain and readable. Dense, obfuscated strings are a strong signal something was injected.

Compare your current file against a backup from before the problem started, if you have one. Even a rough diff will surface additions instantly. If you don't have a backup, a fresh copy generated by WordPress's default permalink settings is usually safe to fall back on.

What to look for inside wp-config.php

This file loads before almost anything else on your site, which is exactly why attackers like it. Malicious code placed here runs on every single page load, before WordPress even finishes booting. It's also rarely opened by site owners, so it can sit there undisturbed for months.

Look for PHP code blocks that don't belong: anything referencing base64, eval, or long strings of random-looking characters. Legitimate wp-config.php files are short. They define database credentials, security keys, and a handful of standard constants. If you see chunks of unfamiliar code wedged between those sections, that's worth investigating immediately.

Don't stop at wp-config.php once you find something. This file is often just one piece of a WordPress site redirecting to spam. The same actor frequently drops a matching payload in a theme file or a rogue plugin, so the two work together and one alone won't fully explain the behavior.

How the redirect actually gets onto your site

Nobody wakes up with a WordPress site redirecting to spam for no reason. There's always an entry point, and in my experience cleaning these, three causes show up again and again. The first is nulled or pirated premium plugins and themes, downloaded from outside the official marketplace to skip a license fee.

Those "free" premium plugins often ship with the malicious code already baked in. It sits dormant until it's ready to activate, or it phones home for further instructions. The second cause is outdated plugins and themes with known, published vulnerabilities. Attackers scan the web constantly for sites still running old versions of popular plugins.

The third cause is compromised credentials, usually FTP, hosting panel, or WordPress admin logins reused from another breached site or caught by a phishing email. Once an attacker has valid login details, they don't need a vulnerability at all. They just walk in the front door and place the code exactly where they want it.

The business cost that goes beyond lost traffic

Lost visitors are the visible damage, but they're rarely the most expensive part. If you run Google Ads or Facebook Ads pointing at your domain, a redirect hack can trigger an account suspension. Ad platforms treat WordPress redirecting to spam as a policy violation, and getting an ad account reinstated after that is a slow, frustrating process.

Affiliate and partner relationships take a hit from WordPress redirecting to spam too. If you send traffic to partners, or partners send traffic to you, a WordPress site redirecting to spam breaks that trust fast. Partners notice when their referred visitors land somewhere unexpected, and rebuilding that confidence takes far longer than the fix itself does.

Then there's the browser-level flagging. Chrome, Firefox, and Safari all maintain blocklists for known malicious redirects. Once your domain lands on one, visitors see a bright red warning page before they ever reach your site, regardless of whether you've already cleaned the infection. Getting removed from those lists is its own separate process, on top of the technical cleanup.

Confirming the fix actually holds

Removing the code you found isn't the finish line. You need to prove WordPress redirecting to spam is genuinely gone, under every condition that triggered it before. That's the real, final test of whether WordPress redirecting to spam is genuinely and completely fixed, not just quiet for now. Repeat every test you ran during diagnosis: fresh incognito session, real mobile device, and a cold click from actual Google search results.

Clear every layer of caching before you test, not just once. WordPress page caches, server-level caching, and CDN edge caches can all keep serving the old, infected response for hours after the underlying code is gone. A clean site can still appear infected simply because a cached copy hasn't expired yet.

Check your server logs for any outbound connections to unfamiliar domains too. Some infections don't just redirect. They also phone home to a command server for fresh instructions. If that traffic is still happening after cleanup, there's a piece you haven't found yet, and it will likely resurface soon.

Preventing this specific hack going forward

Preventing WordPress redirecting to spam starts with the entry point you actually had. If a nulled plugin got you here, replace every non-official plugin and theme on the site, not just the one you suspect. If it was an outdated version, put updates on a schedule instead of waiting for a problem to force your hand.

Rotate every credential connected to the site: WordPress admin, FTP, hosting panel, and database. Reused or old passwords are how a huge share of these infections start in the first place, and a redirect hack is exactly the moment to break that habit for good.

File integrity monitoring is worth setting up too. It flags unexpected changes to core files, themes, and plugins the moment they happen, instead of weeks later when a customer complains. I've cleaned WordPress redirecting to spam infections on well over 10,000 sites at this point, and the ones that never come back are always the ones where monitoring catches the next attempt early.

What a repeat infection usually means

If WordPress redirecting to spam comes back after a clean-up, the first attempt missed something. Usually a second injection sitting somewhere the first scan didn't reach. Sometimes a backdoor left behind specifically to restore the redirect once the obvious code is gone.

Treat a repeat case differently from a first one. Widen the scan to cover every plugin and theme file, not just the ones that looked suspicious the first time. Check scheduled tasks too. Some redirect hacks reinstall themselves on a schedule, which is why removing the visible code alone rarely holds for long. This is exactly the kind of pattern a full clean-up is built to catch, not just the visible symptom. That pattern shows up often enough that it's worth planning for from the start, not treating as a surprise if it happens.