Your site looks perfect on your laptop — but real visitors on phones get thrown to a casino, gift-card scam, or “You won an iPhone” page. That’s a conditional mobile redirect: a script that reads the visitor’s User-Agent, fires only for iPhone/Android, and hides from you because you test on desktop. We find the cloaking code in your .htaccess, theme files, database, and rogue plugins, strip it, and close the backdoor that re-adds it.
Last updated: June 2026 · Reviewed by the FixHackedWordPress malware response team
Sound Familiar?
Fix-First, Pay-Later Guarantee
We confirm and clean the mobile redirect first. If we can’t secure your site, you pay nothing.
Quick Answer
A mobile-only redirect hack is malware that inspects each visitor’s User-Agent string and only hijacks smartphone traffic (iPhone, iPad, Android), while serving the normal site to desktop browsers and logged-in admins. Because almost every owner checks their site from a computer, the infection can run for weeks before it’s noticed — usually only after customers complain. Many variants also redirect each device just once per day (using a cookie or WordPress transient), which is why it feels impossible to reproduce.
Removing it isn’t about restoring a backup — it’s about finding the exact User-Agent condition (in .htaccess, functions.php, the database, or a rogue plugin), deleting it, removing the cookie/transient cloaking logic, and closing the backdoor that re-injects it. We then re-verify on real iOS and Android devices, not just a desktop scan.
~60%+
Of web traffic is mobile — the traffic attackers monetize
Once/day
Per-device cloaking that hides the redirect
User-Agent
The condition we hunt, not just a file
$0
If we can’t fix it
Prove It’s Mobile-Only
A desktop visit will tell you nothing — that’s the whole point of this malware. Use any of these to force the mobile condition and confirm what your customers are seeing before you call anyone.
Method 1 — Real device, real network
Open your site on an actual iPhone/Android using mobile data, not Wi-Fi, in a private/incognito tab. Some campaigns whitelist known IP ranges (like your office), so cellular is the truest test. If it redirects once and then stops, that’s the per-device cloaking — try a second device.
Method 2 — Spoof the User-Agent
In Chrome, open DevTools → Device Toolbar and pick an iPhone, or set a custom mobile User-Agent. Hard-refresh. If a desktop machine suddenly redirects only when it claims to be a phone, you’ve confirmed User-Agent sniffing.
Method 3 — curl, two ways
From a terminal, request your homepage twice — once with a desktop User-Agent and once with an iPhone/Android one — and watch the status code. A clean site returns 200 both times. An infected one returns a 301/302 with a Location: header pointing to a spam domain only for the mobile request.
Method 4 — Logs & Search Console
In your raw access logs, filter for 302 responses tied to mobile User-Agent strings. In Google Search Console, watch for Security Issues, “deceptive content,” or a sudden drop in mobile impressions — Google’s crawlers can hit the redirect before you do.
Confirmed it’s mobile-only? Send us your URL — we’ll pinpoint the exact condition and clean it. Not sure if it’s mobile-only or something broader? See the routing table further down.
How The Cloak Works
Every mobile-only redirect comes down to one decision: is this visitor on a phone? The malware answers that in one of three layers, then sends mobile users to an ad or traffic network for money while you see nothing.
An Apache RewriteCond tests HTTP_USER_AGENT against a list of mobile identifiers — Android, iPhone, iPad, BlackBerry, Windows Phone — and a matching RewriteRule issues a 302 to an external spam URL. This runs before WordPress even loads, so plugins never see it.
Code in functions.php, wp-config.php, or an injected header.php runs a preg_match on the User-Agent for mobile|android|iphone|ipad, then calls header('Location: …'). It’s usually obfuscated with base64_decode, str_rot13, or gzinflate so a plain text search misses it.
An obfuscated script checks navigator.userAgent or screen width and runs window.location only on small/touch devices. It’s slipped into header.php, a widget, or a database field — and often loaded from a remote domain so the payload can change without touching your files.
The stealth trick that fools everyone
On top of the device check, most modern variants set a cookie or WordPress transient so each visitor is redirected only once per day. That’s why you might catch it once, then “confirm it’s fixed” five minutes later when it simply isn’t firing again on your device. It isn’t gone — it’s waiting for the next fresh visitor. We always clear this logic and re-test from clean devices.
A mobile redirect can live in any layer that runs before your visitor sees the page. Automated scanners check the obvious files; we inspect every one of these by hand, specifically for User-Agent logic.
A clean WordPress .htaccess is ~10 lines. We flag any RewriteCond %{HTTP_USER_AGENT} listing mobile devices paired with a RewriteRule pointing off-site — the most common mobile-redirect home.
PHP that sniffs the User-Agent and fires a header('Location') redirect. Because wp-config.php loads on every request, it’s a favorite for obfuscated eval(base64_decode(...)) payloads.
A navigator.userAgent / screen-width check that runs window.location only on phones, hidden in header.php, footer.php, or a file disguised as jQuery.
Injected mobile-ad or redirect scripts inside wp_posts, widget options, and theme settings in wp_options — plus the transients that enforce “redirect once per device.”
A fake plugin (or one dropped into wp-content/mu-plugins) that performs the device check silently on every load and never appears normally in your plugin list.
PHP shells in wp-content/uploads and rogue admin accounts — the persistence layer that quietly rewrites your .htaccess and re-adds the mobile redirect after a naive cleanup.
Simple Pricing
No tiers, no upsells. One price to remove the mobile-only redirect and secure your site.
$75 flat, to start
Complete mobile-redirect removal and hardening — one site.
Fix-first, pay-later · you only pay once it’s clean
Mobile is the majority of most sites’ visitors, and mobile ad, pop-under, and push-notification networks pay per redirected user. Phones are also harder to defend: smaller screens hide the flicker, browser warnings are easier to dismiss, and “click Allow” push-permission scams work better on touch. Targeting only mobile maximizes the attacker’s payout while minimizing the odds the owner — testing on desktop — ever notices.
Most scanners crawl from a desktop/server context and present a desktop User-Agent, so the malware’s device check simply doesn’t trigger for them. Add the once-per-day cookie and a signature-evading obfuscation layer, and a “no issues found” report is meaningless here. Only deliberate verification with mobile User-Agents — exactly what your visitors send — proves a site is actually clean.
Make Sure It’s Actually Mobile-Only
“Mobile-only” is a specific condition. If your redirect fires on desktop too, or only from Google, or your URLs work but search listings are poisoned, a different page is your faster fix. Match your symptom to the right row.
| What you’re seeing | Most likely cause | Get the right fix |
|---|---|---|
| Redirects only on phones; desktop is fine | User-Agent sniffing (conditional mobile redirect) | You’re on the right page |
| Redirects on any device, or only from Google clicks, or whole site | Broader redirect infection (referrer / sitewide) | General redirect malware removal |
| “Click Allow” / fake CAPTCHA before redirect | Push-notification / browser-permission hijack | Fake CAPTCHA removal |
| URLs work, but spam/Japanese pages are indexed | SEO-spam injection (cloaked to crawlers) | SEO spam removal |
| “Deceptive site ahead” red screen / Search Console flag | Google blacklist after detection | Blacklist removal |
| Mixed or intermittent symptoms | Could be more than one infection | Free infection check |
A mobile redirect and an SEO-spam or backdoor infection often come from the same break-in. We scan for all of them during a mobile cleanup so you don’t fix one and leave another live.
Methodology
The hard part of a mobile redirect isn’t deleting one line — it’s reproducing a hack built to hide, then making sure it can’t re-arm tomorrow. Here’s our protocol.
We trigger the redirect with real iOS/Android User-Agents and over cellular, then go straight to raw access and SSL logs to find the exact 302s, the destination domain, and the first request that injected it.
We strip the device check from .htaccess, theme/config files, and the database, de-obfuscate hidden payloads, and clear the cookie/transient cloaking so the redirect can’t quietly fire on the next fresh visitor.
We find the vulnerability that let them in, remove backdoors and rogue admin users, rotate security keys, fix file permissions, and lock down login — so the same hole can’t re-add the mobile redirect.
We confirm a clean 200 across desktop and multiple mobile User-Agents, recheck Search Console, and if Google flagged you or your host suspended the account, we file the review requests to restore traffic.
The malware reads the visitor’s User-Agent string before the page renders. If it sees a desktop browser — or that you’re a logged-in admin — it serves the normal site. If it sees iPhone, iPad, or Android, it fires the redirect. It’s deliberately built around the fact that owners check their site on a computer.
Almost certainly not. Most mobile variants set a cookie or a WordPress transient so each device is redirected only once per day. It’s still live for every new visitor — it’s just skipping you. We clear that logic and re-test from clean devices to be sure.
Some campaigns whitelist known or repeat IP addresses, so the network you usually browse from is excluded. Testing on mobile data, in a private tab, from a device that hasn’t visited recently gives you the most honest result.
It can. Google indexes mobile-first, so a redirect that hits mobile users (and sometimes crawlers) can trigger a “deceptive site” warning and a drop in mobile impressions. Once the code is removed and the site is secured, indexing recovers; a warning typically clears within roughly 72 hours of a successful review request. Acting fast limits the damage.
Because most scanners check from a desktop context, the User-Agent condition never triggers for them. Combined with once-per-day cloaking and obfuscation, a clean scan proves nothing here. Verification with real mobile User-Agents is the only reliable check.
If you’re comfortable with server files, removing the obvious RewriteCond rule can stop the symptom. The risk is reinfection: if there’s a backdoor in your uploads folder, a rogue admin, or the same payload also sits in the database or a mu-plugin, your .htaccess gets rewritten within days. A clean fix means closing every entry point, not just the visible rule.
We treat active redirects as emergencies — diagnostics usually begin within an hour and most sites are fully cleaned and hardened within 4 to 12 hours. We work fix-first, pay-later: if we can’t eradicate the mobile redirect and secure your site, you pay nothing. Send us your URL for a quote.
Every hour the mobile redirect runs, real customers get bounced to spam and your mobile traffic bleeds. We start immediately — and if we can’t eradicate it and secure your site, you pay absolutely nothing.
100% risk-free · Fix-first, pay-later