A redirect hack is the most frustrating kind of infection to report, because you usually cannot see it yourself. A customer says your site sent them to a fake prize page. You try it on your laptop and nothing happens. You ask them to try again and now it works fine for them too. Meanwhile, enquiries have slowed down and you have no proof anything is wrong.
That is not bad luck. Modern redirect malware is written to be selective, and the selection rules are designed around the site owner’s habits. This page explains how we track those redirects down and remove them for good. It sits within our wider service for repairing hacked websites, and if you would rather attempt it yourself first, our step-by-step article on a WordPress site redirecting to spam is the place to start.
The three redirect patterns we see most
Nearly every redirect we handle falls into one of three families, and often a site has more than one running at the same time.
Mobile-only redirects
The code looks at the visitor’s device and only acts on phones and tablets. Desktop visitors see the normal site. Since most owners update their website from a computer, the infection can run for weeks before anyone with admin access sees it. Mobile visitors, meanwhile, are less likely to notice that the address bar has changed before the scam page loads.
Search-only redirects
Here the trigger is where the visitor came from. Someone who clicks your listing in Google, Bing or another search engine gets redirected. Someone who types your address, uses a bookmark or follows a link in your newsletter sees your real site. Owners almost never reach their own site through a search result, so they rarely trigger it.
First-visit-only redirects
This version redirects each visitor once and then remembers them, usually with a cookie or by noting their IP address. A customer who reports it and tries again sees nothing. You test from the same office network as yesterday and see nothing. It creates the impression that the customer imagined it.
Many infections combine these rules. A redirect might fire only for logged-out mobile visitors arriving from Google, and only on their first visit that day. Each extra condition makes it harder to catch and easier to dismiss.
Why a quick scan often misses it
Owners who suspect a redirect usually install a security plugin and run a scan. Sometimes it finds the problem. Often it reports a clean site, and the redirect carries on.
There are a few reasons. The code may live in the database rather than in a file, tucked inside a widget, a post or a theme setting that file scanners do not read in full. It may be added to the end of a legitimate JavaScript file so that the file still looks familiar. It may be loaded from an outside domain only at the moment a page is viewed, so nothing suspicious sits on your server at all. Or it may be written fresh by a hidden backdoor every time someone removes it.
A scan is a useful first step, and our guide on scanning a website for malware and what scanners miss explains how to get the most from one. But a redirect that hides from you will usually hide from an automated check too.
How we hunt down a redirect
We reproduce it first
Before changing anything, we try to see the redirect with our own eyes, because a fix you cannot test is just a guess. We visit the site the way the targeted visitors do: as a phone browser, arriving from a search result, logged out, with no cookies from previous visits, and from a network that has never visited before. We record what happens and where the visitor ends up.
Seeing the redirect fire tells us which conditions it uses, and that narrows down where the code can be hiding.
We take a snapshot
With the behaviour recorded, we copy the entire site, every file and the whole database, to safe storage. That protects your site if a cleanup step goes wrong, and it preserves the evidence.
We trace it to the source
Then we follow the redirect back through every layer it could come from. Server rules in .htaccess, including copies in subfolders. Code added to WordPress core files or the theme. Scripts stored in the database. Plugins that appear in the file system but not in the dashboard. JavaScript loaded from outside domains. Server settings outside WordPress entirely. When the database is involved, our hacked database cleanup work covers removing the injected script safely without damaging your posts and settings.
We find what keeps putting it back
The redirect itself is only the visible part. Somewhere on the server, there is usually a backdoor that lets the attacker return, and sometimes a scheduled task that rewrites the redirect if it is removed. Removing the redirect without finding that mechanism is the main reason these infections return a few days after a cleanup. Our dedicated backdoor removal service explains how we search for that hidden access.
We test it again, under every condition
After cleaning, we repeat the original tests. Phone and desktop. From search and directly. Logged in and logged out. First visit and repeat visit. Only when the redirect does not fire under any of them do we treat the job as done.
When the redirect is not on your website at all
Occasionally the trail leads away from WordPress. A domain’s DNS records may have been changed at the registrar, so some traffic is sent to a server the attacker controls. A compromised account elsewhere on a shared server may be interfering with requests. A third-party script you added years ago, such as an old chat widget or a visitor counter, may have been taken over by someone else and started serving redirect code.
These cases are less common, but they explain why a site can look spotless from the inside and still misbehave. When we find one, we tell you exactly where the problem sits and who has to change it, whether that is you at the registrar, the host, or a script you can simply remove.
What the redirect does to your search presence
Redirects are bad news for your listings as well as your visitors. Google can detect that search users are being sent to harmful pages, and it may add a warning to your result or show a full-page browser warning. Sites with these warnings lose visitors quickly, even after the code is gone.
If Google has already flagged the site, clearing that flag is part of finishing the job. We request a review once the cleanup is confirmed, and our page on removing Google warnings from a website explains that process in more detail. When the redirect pointed to a page imitating a bank or login screen, the warning you see may be the red full-screen kind, which we cover in our article about the deceptive site ahead warning.
What you can do before we start
- Ask the customer for details. Which device they used, whether they came from Google, and roughly what time. A screenshot of the page they landed on is ideal.
- Try it yourself on mobile data. Use your phone, switch off Wi-Fi, open a private browsing tab, search for your business name and tap the result.
- Note recent changes. Anything installed, updated or moved in the weeks before the first report is a useful clue to where the trouble started.
- Leave the files alone. Deleting a suspicious-looking file can destroy the trail we need, and if a backdoor is still in place, the redirect will return anyway.
When the redirect keeps coming back
A redirect that returns after you, your host or another provider removed it means something was missed the first time: the original way in, or a backdoor. That situation needs a different starting point, because we have to look at what the earlier cleanup did and did not catch. Our page on a WordPress site that keeps getting reinfected explains how we approach it.
Whichever pattern you are dealing with, the core cleanup follows the same method we describe on our WordPress malware removal page, with extra testing to catch the selective behaviour that makes redirects hard to pin down.
If customers are being sent somewhere they should not be, write HACKED at the top of a WhatsApp message, then add your domain and whatever you know about the device the customer used and how they reached you.