Practical guides on websites, online stores, and getting found on Google — written for business owners, not developers.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
Your WordPress site is redirecting to spam for visitors but looks fine to you. Here is how to prove it, find where the code hides, remove it, and confirm it is gone.
When your WordPress site is redirecting to spam, your visitors do not think your website has been hacked. They think this is who you are.
Someone clicks your link, lands on a gambling page, and closes the tab. They do not stop to wonder whether you knew about it. They do not come back a week later to check if you fixed it. You lost that person, and you will never see it happen.
So this is not a small technical problem. It reaches visitor trust, sales, and the growth you have spent years building.
The harder part is that you probably cannot see any of it. You open your site, click through a few pages, and everything looks the way it should. Redirect malware is written to hide from the person who owns the site. It checks whether you are logged in, where you arrived from, and what device you are on. You fail those checks, so you get served the clean version.
This guide covers how to prove the redirect is real, find where the code is hiding, remove it, and confirm it is gone.
Not every redirect is malware. Three ordinary problems look identical from the outside, and each one takes about two minutes to rule out.
Your site address is wrong. Go to Settings, then General, and read the WordPress Address and Site Address fields. If they point at an old staging domain or the wrong protocol, a migration or a plugin rewrote them. If they point at a domain you have never owned, that is not a configuration error. That is the hack, and you can skip ahead.
A plugin is doing it. SSL plugins, force-HTTPS tools and redirect managers all rewrite traffic. One bad rule sends every visitor somewhere unintended. Deactivate them one at a time and test between each.
Something is cached. Your CDN and your host both keep their own page cache. Either can serve a redirect rule that was removed hours ago. Purge both before you conclude anything.
Now the line that separates the two situations. A configuration problem redirects everyone, every time, in the same way. Malware redirects some people, sometimes. If the site behaves differently on your phone than on your laptop, or differently for a visitor than for you, stop checking settings. You have malware.
Redirect malware does not fire for everyone. It runs a series of checks first and only redirects visitors who pass them. That is why the most common sentence we hear on these jobs is some version of "I checked and it looked completely normal to me."
Run these five tests in order. Open your browser developer tools first and turn on Preserve Log, or the page will navigate away before you see the redirect happen.
Test | If it redirects here | The malware is checking |
|---|---|---|
Incognito window, URL typed directly | yes | whether you are logged in |
Search your brand on Google, click the result | only here | the referrer |
Real phone, mobile data, arriving from search | only here | the user agent |
Visit a second time in the same browser | no, it stops | a first-visit cookie |
VPN set to another country | only there | geolocation |
Most live infections stack two or three of these together. Logged-out plus referrer plus mobile is the combination we see most often, and it is worth sitting with what that leaves you. The only people who get redirected are new mobile visitors arriving from a search result. Those are the visitors least likely to know how to contact you and least likely to bother.
Here is why the answer matters beyond curiosity. The condition that fires tells you roughly where the code lives.
Referrer and user agent checks are cheap to write as server rules, so start with .htaccess and check for a second one in your subdirectories.
Cookie logic and login-state checks need PHP to run. That points at your theme files, functions.php, header.php, and the index.php in your site root.
If the redirect survives replacing your files with clean copies, it is not in a file. Look at the database and at scheduled tasks.
This narrows the search. It does not replace it. But knowing which two locations to open first saves you from reading through every file on the server.
Redirect malware is easy to delete, and that is the problem. Most people find the injected code, remove it, and lose the only record of how it got there.
Do two things first.
Take a full copy of the files and the database. Not a clean backup, a copy of the infected state exactly as it is. You will need it if the cleanup goes wrong or the redirect comes back next week.
Then download your server access logs, seven days at minimum. Most hosts rotate them within a few days and some keep only forty eight hours. Once they are gone, the request that planted the code is gone with them.
It is also worth knowing what cleanup costs you. File modification times are usually the fastest route to the entry point, and replacing files resets them. Working out how the attacker got in is the job of a security audit, and it gets much harder once the evidence has been overwritten.
Start with the two locations your test results pointed at. If the tests were inconclusive, work down this list in order. It is roughly the order we find things in.
.htaccess. Look for rewrite rules containing HTTP_USER_AGENT or HTTP_REFERER. Then check your subdirectories, because a second .htaccess sitting in /wp-content/ or /uploads/ is common and easy to walk past.
Theme header.php and functions.php. Injected code usually sits at the very top of the file, above the opening comment block. If you run a child theme, check both.
index.php in your site root. Normally this file is short. One long encoded line is often the only thing in it that does not belong. Compare it against a fresh WordPress download.
wp_options. Check siteurl and home first. Then search the option_value column for script tags and encoded strings, and look for recently added options with random names.
wp_posts. Script tags injected into post content or widget content. The table is large and nobody reads it, which is exactly why attackers use it.
WP-Cron. A scheduled task that rewrites the infected files after you remove them. If the redirect returns a few hours after a clean removal, this is usually the reason.
One honest caveat. Searching for strings like base64_decode or eval will find the simple variants. It will not find code that pulls the redirect from an external server, or a payload split across several files so that no single piece matches. If you clean the obvious hits and the redirect continues, assume there is a second piece you have not found yet. Our manual WordPress malware removal guide covers the deeper search.
Replace rather than repair. Download fresh copies of WordPress core, your theme and every plugin from their original sources, then overwrite what is on the server. Editing infected files one at a time is slower and you will miss one.
The database has to be done by hand. There is no clean copy to overwrite it with, so work through the locations above and remove the injected entries yourself.
Then close the doors the attacker already holds. Rotate the salts and security keys in wp-config.php, which invalidates every active session on the site including any the attacker is sitting on. Change passwords for WordPress, hosting, FTP and the database, and do it from a device you trust rather than the one you have been troubleshooting on. Delete administrator accounts you do not recognise.
Now the part that matters more than any of those steps. Removing the redirect is not fixing the site. If the backdoor is still in place, or the vulnerable plugin is still installed, the redirect comes back. Usually within days. We see the same site a second time more often than we would like.
Doing this on a live site under pressure is genuinely difficult, and if yours is taking orders while you work, emergency malware removal exists for that situation.
Go back to the diagnosis table and run every test again. Not just the one you managed to reproduce the first time. Infections often carry more than one payload, and removing the piece you found does not tell you anything about the piece you did not.
Then check from outside WordPress. A security plugin scanning from inside a compromised installation is asking the compromised system whether it is compromised. Use an external scanner that requests your pages the way an ordinary visitor would, and test on a real phone as well as a desktop.
Check Search Console under Security Issues, but read it carefully. It reports what Google saw on its last crawl, not what is on your site right now, so it will keep showing warnings for days after a successful cleanup. Do not request a review until your own tests come back clean, because a failed review costs you more time than waiting did.
One more thing to expect. A clean site is not a recovered site. If the redirect was running for a while, there is separate work waiting on the search side.
Reinfection is the normal outcome, not the unlucky one. Four things decide whether it happens to you.
Patch the entry point. If you never worked out how they got in, nothing else on this list matters much.
Sweep for backdoors before you call the job finished. A single uploaded PHP file in a folder nobody looks at will undo everything.
Turn on file change monitoring. The next injection announces itself as a modified file, hours before anyone notices a redirect.
Rotate credentials everywhere, not only in WordPress. Hosting panel, FTP, database, and any account that shares that password.
Most of that is ongoing work rather than a one time fix, which is what website security and maintenance is for. Our WordPress hardening checklist covers the rest.
Because the malware is reading your device type and only firing for phones. Attackers do this deliberately. They know site owners check their own sites from a laptop, so excluding desktop buys the infection weeks of extra life.
The code is checking your referrer, which is the page you arrived from. Arriving from a search result marks you as a real visitor rather than the owner. Typing the address directly leaves the referrer empty, so the redirect never triggers.
Yes. Google can flag the site with a warning in search results, and in serious cases apply a manual action. Both are reversible once the site is clean, but the review process takes time and only starts after you request it.
Nobody can give you a reliable number, and be careful with anyone who does. It depends mostly on how long the redirect was live and whether Google flagged the site. What you can control is the gap between cleanup and recovery work, since the search side does not start healing on its own.
SEO & Security Expert, AppDeel
Azizul Hakim is an SEO and website security specialist at AppDeel, the agency he founded and where he still handles client work himself. For more than ten years he has helped business owners and eCommerce brands get found in search and keep their websites secure.
Read more posts by Md Azizul Hakim →How to work out how long your site has actually been compromised, and why that answer decides everything else.
A breakdown of the fake Cloudflare verification scam hitting WordPress sites — how it hides from site owners, why security scanners miss it, and how we remove it.
How to remove malware from a WordPress site: hidden backdoors, database spam, rogue admin accounts, and a fake Cloudflare verification page.
Most landing page advice assumes you bought the traffic. Where the button goes, what it says, and how much to explain first, when nobody clicked an ad.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
