A WordPress redirect hack on mobile only can be real even when the site looks normal on desktop. Attackers may show the malicious destination only to selected visitors so the owner and security scanner are less likely to see it.
I’m Ryohei Yokoyama, founder of SiteFixNow. I’ve worked as an IT engineer for over 20 years and have handled many WordPress malware removal, hacked site repair, and redirect hack cleanup cases. In this article, I’ll show you how to investigate a mobile-only redirect without hiding the evidence or making the infection harder to trace.
- Why redirect malware may target only phones, first visits, or search traffic
- How to reproduce the problem with a controlled test matrix
- How to compare mobile and desktop headers without following a dangerous URL
- Where conditional redirects hide in browsers, edge services, files, and the database
- How to prove the redirect is gone across devices and traffic paths
Why a WordPress Redirect Hack May Appear on Mobile Only
“Mobile only” is usually a condition, not a separate malware type. A compromised site can decide whether to redirect from the request, browser state, or visitor source.
Common conditions include a mobile User-Agent, a Google referrer, a new cookie, a logged-out session, a specific country, one landing page, or a particular time window. Malware may also exclude WordPress administrators and familiar IP addresses.
- You test while logged in, but the code excludes administrators.
- Your browser already has the attacker’s “shown once” cookie.
- Your desktop and phone receive different cached versions at the CDN.
- The redirect activates only after a search-result click or on mobile data.
- Injected JavaScript waits for a tap, timer, scroll, or specific screen size.
For the broader symptoms and emergency priorities, review WordPress redirect hack symptoms and first-response steps. The mobile-only investigation below adds the controlled comparisons needed when the behavior is selective.
Reproduce and Record the Mobile-Only Redirect Safely

Build a small test matrix before changing the site. Change one variable at a time so you can identify the trigger instead of producing a collection of contradictory screenshots.
- Desktop and phone, both logged out
- Private window and a normal returning session
- Wi-Fi and cellular data or another independent network
- Direct URL visit and a click from a real search result
- Homepage, reported landing page, and one unaffected control page
Use an isolated test browser or disposable profile. Do not ask customers to keep visiting a suspected malicious destination. Record the source page, final domain, timestamp and timezone, device, browser, network, login state, referrer, and whether it was the first visit.
You can compare HTTP responses with mobile and desktop User-Agent strings. The command below stops at the first server-side redirect instead of following the unknown destination.
# Replace example.com with your own affected page.
# --max-redirs 0 records the first response without following it.
curl -sS -D mobile-headers.txt -o /dev/null --max-redirs 0 \
-A "Mozilla/5.0 (Linux; Android 14; Mobile) AppleWebKit/537.36 Chrome/127 Safari/537.36" \
-e "https://www.google.com/" https://example.com/affected-page/
curl -sS -D desktop-headers.txt -o /dev/null --max-redirs 0 \
-A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/127 Safari/537.36" \
-e "https://www.google.com/" https://example.com/affected-page/
diff -u desktop-headers.txt mobile-headers.txtThe general WordPress redirect virus troubleshooting workflow helps distinguish malware from a redirect plugin, CDN rule, or ordinary configuration error.
Find Which Layer Creates the Mobile Redirect

Start with the layer indicated by your evidence, but inspect every persistence path before declaring the site clean. A redirect can be injected at more than one layer, and removing the first symptom may leave the attacker’s loader or access route intact.
In developer tools, compare scripts, network requests, cookies, storage, and service workers in a fresh disposable profile and the affected profile. At the edge, review CDN redirects, workers, cache variations, mobile optimization, origin selection, and DNS changes. Preserve the bad response before clearing caches.
Inspect WordPress, server files, and the database
Check .htaccess, Nginx configuration, wp-config.php, must-use plugins, active plugins, the active theme, uploads, cache folders, and modified core files. Search for mobile conditions and redirect functions, but treat a search hit as a lead rather than proof.
# Run from a verified backup or safe server shell.
find wp-content -type f -name '*.php' -mtime -14 -print
grep -RniE 'HTTP_USER_AGENT|wp_is_mobile|window\.location|document\.location|location\.replace|base64_decode|gzinflate|eval[[:space:]]*\(' \
wp-config.php .htaccess wp-content/mu-plugins wp-content/plugins wp-content/themes 2>/dev/null
# PHP inside uploads is unusual on most sites and deserves review.
find wp-content/uploads -type f \( -name '*.php' -o -name '*.phtml' \) -printUse a trusted database export for searching rather than running destructive replacements first. Then scan WordPress for malware and hidden backdoors across the entire account, including sibling sites that share credentials or hosting.
Fix the Mobile WordPress Redirect Without Hiding the Root Cause

Contain visitors, preserve the infected state, and clean from a known-good source. Editing one redirect line is not enough if the attacker can regenerate it through a backdoor, stolen password, vulnerable plugin, scheduled task, or compromised hosting account.
- Limit visitor exposure with a clean maintenance page or hosting-level protection.
- Preserve full files, database, logs, timestamps, and the bad response evidence.
- Replace WordPress core and commercial/open-source packages from verified sources.
- Remove injected code from custom files and clean malicious database content.
- Patch or remove the exploited component and close every persistence path.
- Rotate credentials from a clean device and invalidate old sessions and salts.
Follow a complete WordPress malware cleanup across files, database, and backdoors. If multiple sites share the same account, clean and patch them as one incident or the compromised neighbor may reinfect the repaired site.
Only purge browser, plugin, server, and CDN caches after the malicious source has been removed. Purging is part of deployment and verification; it is not a malware-removal method.
Verify the Mobile Redirect Is Gone Everywhere
Repeat the same pre-cleanup matrix after recovery. A single successful desktop visit proves very little. Use the same reported landing page, referrer, device type, login state, network type, and first-visit condition that originally triggered the redirect.
- No unexpected redirect on iOS and Android test devices.
- Direct, search-referrer, private, first-visit, Wi-Fi, and cellular tests match.
- No unknown outbound request, injected script, edge rule, or service worker remains.
- File and database scans match a reviewed clean baseline.
- The exploited component, account, or configuration path has been closed.
- Logs and monitoring show no repeat redirect or unauthorized change.
Finally, secure WordPress after malware removal and stop reinfection with updates, least privilege, multifactor authentication, protected backups, file-change monitoring, and a documented response process.
Frequently Asked Questions About Mobile-Only WordPress Redirects
Summary: Test the Condition, Clean the Source, and Verify Again
A mobile-only redirect report should be treated as credible until controlled testing proves otherwise. Selective malware can hide from logged-in owners, desktop browsers, familiar networks, and repeated visits.
Record the trigger matrix, preserve the infected state, trace the browser, edge, server, WordPress, and database layers, and clean every persistence path. Afterward, repeat the exact mobile tests and monitor for unauthorized changes before considering the incident closed.
If You Can’t Secure or Recover Your WordPress Site Yourself

If your website shows malware warnings, redirects to strange pages, or you are not sure whether it is secure,
SiteFixNow can help clean, repair, and recover your WordPress site.
- Your WordPress site may be infected with malware.
- Security warnings appear in Google or browser results.
- You found unknown admin users or suspicious files.
- The site redirects to spam or unknown websites.
- You need urgent WordPress hacked site repair.
- Reduce visitor risk and SEO damage.
- Find hidden malware and backdoors, not only visible symptoms.
- Recover the site safely without unnecessary data loss.
