Website Redirects to Spam Only on Mobile? How to Fix It

By Glenn Lyvers · Updated September 28, 2026 · 7 min read

If your site redirects to spam only on mobile, the redirect is almost certainly deliberate: the injected code checks who is visiting and only fires for phones, for people arriving from Google, or for first-time visitors — and it stays quiet for you. That is why it “works fine” on your desktop while customers land on a scam page. The fix is to reproduce it the way the malware expects, find the condition, and remove the code together with whatever keeps putting it back.

Why you can’t reproduce it

Conditional redirects are built to survive the owner. The person most likely to notice and delete them is you, so the code is written to skip you. The conditions I find most often, sometimes stacked three or four deep:

• User-agent. Only Android and iPhone browsers are redirected. Desktop traffic, and often Googlebot, gets the normal page.
• Referer. Only visitors arriving from a search engine or social link are sent away. Typing the address in yourself sends no referer, so you never trigger it.
• Once per visitor. A cookie or a record of the IP address is set on the first redirect. Every later visit from the same phone looks clean, which is why the customer who complained can’t show you twice.
• Logged-in exclusion. Anyone carrying a wordpress_logged_in_ cookie is skipped. You are logged in; your visitors are not.
• Time and rate windows. Some variants only fire at certain hours or for a percentage of traffic, so you get intermittent reports that sound like user error.

None of this is exotic. It is the standard toolkit behind the WordPress redirect hack and most cloaking infections. The mobile condition is simply the most common filter, because phone users are less likely to notice the address bar and more likely to tap through a fake prize or “virus detected” page.

How to reproduce it safely

Don’t test with your own phone on your own Wi-Fi more than once — after the first hit the once-per-IP rule will hide it from you. Use a method you can repeat and log.

From a terminal, ask for the page the way a phone coming from Google would, and look at the response headers and any script in the HTML rather than following the redirect:

curl -s -D - -o page.html \
  -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Mobile/15E148 Safari/604.1" \
  -e "https://www.google.com/" \
  https://example.com/

A 301 or 302 with a Location: header you don’t recognise means the redirect is server-side — .htaccess or PHP. A 200 is not a clean bill of health: open page.html and search for window.location, location.replace, document.referrer, atob(, fromCharCode and any <script src> on a domain you don’t know. That points at a JavaScript redirect, which curl will never follow. Run the same request without -A and -e and compare the two files; the difference is the malware.

In a browser, use a private window that is logged out of WordPress, switch devtools to device mode with a phone profile, and arrive by clicking your own result in a Google search. Keep the Network panel open with “Preserve log” ticked so you capture the hop before the page disappears. If you want to know whether a site is serving different content to different visitors without doing this by hand, my free site scanner fetches it several ways and flags the differences.

Where the redirect code usually lives

Location	What to look for
.htaccess (root and subfolders)	RewriteCond %{HTTP_USER_AGENT} (android|iphone|mobile) or %{HTTP_REFERER} (google|bing|yahoo) followed by a RewriteRule to an outside domain
Theme header.php / functions.php	PHP reading $_SERVER['HTTP_USER_AGENT'] or wp_is_mobile() before a header('Location: ...') or an echoed script
Database (wp_options, wp_posts)	Script tags in widget options, theme settings or post content; a rewritten siteurl/home
Injected JavaScript files	Legitimate theme or plugin .js files with an obfuscated block appended at the end
Fake or nulled plugins, mu-plugins	A plugin you didn’t install, or code in wp-content/mu-plugins/ that never appears in the plugin list
Third-party tags	A tag added in Google Tag Manager, or a compromised widget or ad script you embedded

The .htaccess case is covered in detail in my guide to a hacked .htaccess file. The JavaScript variants are usually the ones owners miss, because the file is part of a real plugin and only its last few lines are hostile — see injected JavaScript in the WordPress header. If the redirect is not in your files or database at all, check your tag manager: malicious code loaded through Google Tag Manager survives every file cleanup because it never touches your server.

When it isn’t a redirect at all

Two look-alikes are worth ruling out. The first is a malicious service worker or push-notification subscription: visitors who clicked “Allow” once keep getting spam notifications and pop-ups even after the site is clean, because the service worker lives in their browser. The second is ad-network redirects: a legitimate ad slot serving a malicious creative can bounce mobile users to scam pages without any code on your site being modified. Pausing the ad code for a day and seeing whether reports stop is a quick way to separate the two.

Cleaning it up so it stays gone

1. Take a backup of the infected state first. You will want it if you need to work out how they got in. My guide on preserving evidence covers what to keep.
2. Remove every instance, not the first one you find. These campaigns plant the same redirect in several places so that deleting one copy changes nothing visible. Search the whole install for the destination domain and for the condition strings above.
3. Replace core, theme and plugin files with fresh copies rather than hand-editing them, and compare what is left with WordPress checksum verification.
4. Find the persistence. A redirect that returns within a day is being rewritten by a backdoor, a cron job or a rogue admin. Check for hidden admin users and scheduled tasks before you declare victory.
5. Close the way in — usually an outdated plugin or reused password — then clear every cache layer, including any CDN, so the old response stops being served.
6. Re-test the way you reproduced it, with the phone user-agent and Google referer, from a fresh IP address.

Your access logs will tell you when the injection happened and often how: look for a POST to an odd file just before the first redirect was reported. Reading access logs after a hack walks through what to filter for.

When it’s worth handing over

If you have found the redirect, removed it, and it came back, stop deleting copies. That pattern means the code writing it is still on the server, and every round you play costs you another day of mobile visitors sent to a scam page and another chance of a Google warning. That is the point where I would rather you hand me the cleanup: I trace the persistence, remove it, close the entry point, and re-test from the mobile-and-Google angle before I call it done. If Google or an antivirus vendor has already flagged you, the blacklist recovery is handled in the same job.

After the fix: search and trust

Mobile redirects hurt twice. Visitors who were bounced don’t come back, and Google may already have seen the redirect and labelled the site. Check Search Console’s Security Issues report, request a review once you are clean, and watch the mobile search traffic over the following weeks. Ranking recovery after a hack explains what to expect and how long it usually takes.

Common questions

Why does my website redirect to spam only on mobile?

Because the injected code checks the visitor's user-agent and only redirects phones. Attackers target mobile users because they are less likely to read the address bar and more likely to tap through scam pages. The same code usually also skips logged-in administrators and repeat visitors, which is why the owner rarely sees it on their own devices.

Why can't I reproduce the redirect my customers are seeing?

Most redirect malware fires only once per visitor or IP address, only for visitors arriving from a search engine, and never for logged-in WordPress users. Test from a logged-out private window, arrive by clicking a Google result, use a phone user-agent, and switch to a different network after the first attempt, because the first hit can hide it from you.

Is a mobile-only redirect always malware on my site?

Usually, but not always. A malicious ad creative in a legitimate ad slot can bounce mobile users without any code on your site changing, and a malicious push-notification subscription can keep spamming visitors after cleanup. Pausing ad code briefly and checking for unfamiliar service workers helps separate those cases from a genuine site infection.

Where is the mobile redirect code usually hidden?

The most common places are .htaccess rewrite rules that match mobile user-agents, PHP in the theme's header.php or functions.php, script tags stored in the database, obfuscated code appended to legitimate JavaScript files, must-use plugins, and tags added through Google Tag Manager. Most infections plant several copies, so check all of them.

The redirect came back after I removed it. Why?

Something on the server is rewriting it: a backdoor file, a malicious scheduled task, a hidden admin account, or an unpatched plugin being exploited again. Removing the visible redirect without removing that persistence only buys a few hours. Find and remove the code that recreates it, then close the original entry point.

Will a mobile redirect hurt my Google rankings?

It can. If Google sees the redirect it may label the site as hacked or deceptive, and mobile visitors who bounce off a scam page send poor engagement signals. Clean the site, check the Security Issues report in Search Console, request a review, and expect mobile search traffic to take some weeks to recover.