Your website redirects customers somewhere else but works fine for you

A customer rings to say your website took them to a page selling something strange. You open the site on your laptop while they are still on the phone, and it is completely fine. Homepage loads, everything where it should be.

So you tell them it must be their browser, or their phone, or something at their end. Then a second person mentions it. Then a third.

They are not imagining it, and your site is not fine. This is one of the most common WordPress compromises there is, and the entire design of it is to keep you convinced that nothing is wrong.

Why it works for you and not for them

A redirect hack that fired for everybody would be found and fixed within the hour. Whoever wrote it knows that, so the code makes a decision about every visitor before it does anything.

Typical conditions we find:

• Only visitors arriving from a search engine. If you type the address directly, nothing happens. Click a Google result and you are gone.
• Only mobile devices. Desktop users see a normal site. Phone users get redirected, which is most of your traffic on many sites.
• Only visitors who are not logged in. You are logged in as an administrator almost all the time, so you are exempt.
• Only once per visitor. The code sets a cookie, so it fires once and then behaves. If you do test it and catch it, trying again looks like it fixed itself.
• Only outside your office hours or your IP address. Less common, but we have seen it.
• Sometimes it is not a redirect at all. Some variants leave the page alone and instead trigger browser push notification prompts, so visitors end up subscribed to spam alerts that keep arriving long after they have left your site.

Loading your own homepage while logged in on your own laptop is the least reliable test available. It is the exact scenario the malware is written to survive.

Reproducing it on purpose

Before you can fix it you need to see it. Work through these until it happens. No technical skill required for the first three.

1. Use your phone on mobile data, not the office wifi, and search for your business in Google rather than typing the address. Click the result.
2. Use a private or incognito window on your computer, so you are not logged in, and again arrive via a Google search.
3. Ask someone who has never visited the site to try it from their own phone. A fresh visitor with no cookies is the ideal test subject.
4. Use the browser developer tools. Open them, switch to the device toolbar to emulate a phone, tick “Preserve log” in the Network tab so the redirect chain is not wiped, and reload. The Network tab will show you the redirect happening and where it goes.

Do not visit the destination and start clicking things. Note the address and leave.

Where the code is hiding

There are five usual homes for this, and a thorough cleanup checks all of them rather than stopping at the first one found.

The .htaccess file

The classic location, because it runs before WordPress does. Look for rewrite rules referencing a domain you do not recognise, or conditions checking the referrer for search engines. Attackers often pad the file with blank lines so the malicious block sits far below what you see on opening it, or hide a second .htaccess inside a subfolder.

The theme files

Usually functions.php or header.php. This is where we found it on our own site in August, as an injected script in the theme header that redirected bots. Look for long strings of encoded characters, or anything using base64_decode, eval, gzinflate, str_rot13, strrev or preg_replace. Those functions all have legitimate uses, so treat them as a reason to look closely rather than as proof on their own.

The database

Frequently missed, and a common reason cleanups fail. Injected JavaScript often lives in the wp_options table, particularly in fields holding header or footer scripts, in theme_mods, or in custom CSS. It also turns up in wp_posts, and specifically in the post_content_filtered column, which almost nobody thinks to check because it is invisible in the editor. A file-only cleanup leaves all of that running happily.

The mu-plugins folder

Short for “must use plugins”. Anything placed here loads on every request and does not appear anywhere in the WordPress plugins list. There is no toggle, no version number, nothing to see. Most site owners have never opened this folder, which is exactly why it gets used. We found a backdoor here on a client site recently and wrote up exactly how it worked.

The uploads folder

Your media library lives in wp-content/uploads and should contain images, PDFs and video. It should never contain a single .php file. If there is one in there it is not yours. This is one of the fastest checks available and one of the most reliable, because a normal WordPress site simply does not put executable code in the uploads folder.

The wp-includes folder, and your site address settings

wp-includes holds WordPress core machinery that nobody has any business editing, so anything added or modified in there is suspect.

Separately, check Settings then General in WordPress, or the siteurl and home rows in the wp_options table. If either has been pointed at a domain that is not yours, that alone redirects your entire site, and it is a two second fix once you know to look.

A plugin that should not be there

Sometimes the redirect arrives as a real, installed plugin with a plausible name, added by an administrator account the attacker created. Check your plugins list for anything nobody remembers installing, and check the Users list while you are there. Filenames we see repeatedly include mplugin.php and wp-zzz.php, though the name is whatever they felt like on the day, so judge it on whether you recognise it rather than on whether it looks sinister.

Removing it so it stays removed

The redirect is the symptom. The backdoor is the problem. Sites that get cleaned and reinfected within a week have almost always had the symptom treated and the cause left alone.

1. Take a full copy of files and database first, as evidence rather than as a restore point.
2. Narrow the search by modification date. Over SSH, find . -type f -mtime -7 -ls lists everything changed in the last week, which usually puts the malicious files at the top of a very short list.
3. Remove the redirect code from wherever you found it, and keep looking after you find the first one. Multiple copies are normal.
4. Replace WordPress core files with clean originals rather than trusting a visual inspection.
5. Search the database for the injected snippet and remove it there too.
6. Delete administrator accounts you did not create, and check for scheduled tasks that reinstall the payload.
7. Identify the way in, which is usually an out of date plugin, and close it.
8. Rotate all passwords and the security keys in wp-config.php, which logs out any session the attacker still has.
9. Clear every layer of cache: the caching plugin, the host cache, and any CDN in front of the site. A cleaned site served from a stale cache still redirects, and this is a common reason people believe a cleanup failed when it did not.
10. Reinstall plugins and themes from official sources rather than trusting the copies already on the server, and delete anything you are not actively using.
11. Retest using the reproduction steps above from a device that has never loaded the site, then confirm with an outside scanner such as Sucuri SiteCheck or VirusTotal.

If that list reads like a fortnight of your life, it is the job our WordPress malware removal service exists to do, usually within a few hours.

Then deal with Google

A redirect hack that has been running for any length of time has usually attracted attention. Check Search Console for security issues, and check whether a browser warning has appeared. If it has, we have written a full guide to what each Google warning means and how to get it lifted.

Request the review only once the site is genuinely clean. Requesting it early and failing is the most common way people add a week to their own recovery.

Frequently asked questions

Could this be a plugin conflict rather than a hack?

A redirect to another domain you have never heard of is a hack. Redirect loops, or being sent to your own homepage unexpectedly, can be a misconfigured plugin, a site address setting or an SSL rule. If the destination is somebody else’s website, stop looking for an innocent explanation.

Can I just restore a backup from before it started?

You can, and it often works for about a week. The backup contains the same vulnerable plugin that let them in, so unless you update everything immediately afterwards you have restored the door along with the site. You also lose any legitimate content published since.

My security plugin scanned and found nothing. Am I clear?

Not necessarily. Scanners are good at recognising known malicious files and much weaker at database injections, at heavily obfuscated code, and at files in mu-plugins. A clean scan alongside customers reporting redirects means the scan missed something, not that the customers are wrong.

How much traffic am I losing while this runs?

Potentially most of it. If the condition is “arrived from a search engine”, every organic visitor is being handed to somebody else, and your analytics will show the sessions starting and then nothing. A sudden drop in pages per session alongside stable session counts is a strong hint.

Will my rankings recover?

Usually, yes. The longer it ran, the longer the recovery. Google noticing that your pages send visitors somewhere else is not a good look, and reversing that impression takes a few weeks of clean crawling rather than a switch being flipped.

---

Customers seeing a different site to the one you built?

Send us the site and we will tell you whether it is a redirect hack within the hour, usually for nothing. If it is, we will give you a fixed price to clean it and close the way in.

Marketing the Change is a digital marketing agency based in Liverpool. We manage WordPress sites for clients across the UK, which means we occasionally find things like this. When we do, we write about it.

\n\n