WordPress Redirects Only on Mobile: How to Investigate

A customer reports that a particular WordPress page sends a phone to an unfamiliar domain, while you test it on a laptop and see nothing. Repeating the click from the same signed-in administrator session shows the normal site. Because a redirect can depend on user-agent, referrer, session, cache, or edge location, one desktop browser is not a complete test. A different mobile experience is not automatically malware, either; an ad campaign or intended rule may be involved.

The short answer: preserve the starting URL, time, device, network, first response status, and Location header; compare desktop and mobile requests on staging or a site you control, changing one variable at a time, and do not follow an unfamiliar destination. If the behavior is not approved, trace .htaccess/Nginx, CDN, plugins, theme, ad scripts, service workers, and logs before removing code. Google lists device-based redirects as one hacked-redirect pattern, but also recommends auditing third-party elements if the site does not appear hacked (Google Search spam policies, Manual Actions report).

This guide covers device-dependent behavior, not every redirect. If other conditions or paths are involved, record them as separate test cases and use our broader hacked-site response guide to expand the investigation. If files, accounts, or other content are suspicious, also review signs of WordPress malware.

Make the report specific enough to test

Ask the reporter for the starting page URL, not the unsafe destination. Record whether it happens on a direct visit, a search result click, a social app, or an internal link; the device and OS; browser; time; whether a new tab appears; and whether the user was signed in. Do not request passwords, cookies, screenshots with personal details, or repeated visits that could download harmful files.

Build a small test matrix. For example: same URL, same network, one desktop test and one mobile test; then compare direct access with a known referrer. Change one variable per run—user-agent, referrer, IP, and login state should not all change at once—or you will not know what caused the difference. Repeat in a private window after noting that CDN or browser cache can make results inconsistent. Only test sites you own or are authorized to audit.

If the destination is phishing, malware, illegal gambling, or a request for sensitive data, do not open it. Preserve the domain and headers, use a safe analysis environment only if your security team approves, and ask the host to reduce visitor exposure when risk is real. Do not forward the link to customers or public channels.

Compare requests without following the redirect

Start with a GET request so you can see the first response without running JavaScript. Curl does not follow a redirect by default; do not add -L or --location while the destination is unknown. On a staging site you control, compare:

curl -sS -D - -o /dev/null 'https://staging.example.test/path-under-test/'
curl -sS -A 'Mozilla/5.0 (Linux; Android 14; Mobile)' -D - -o /dev/null 'https://staging.example.test/path-under-test/'

Replace the example only with a domain you manage. Compare status codes such as 200, 301, 302, or 307, the Location header, Cache-Control, and approved intermediary headers. Do not copy tokens or cookies into a report. A curl -I HEAD request can behave differently from GET because a server or plugin may handle the methods differently; use browser devtools and access logs if you cannot reproduce the issue.

A user-agent string imitates part of a browser identity, not the whole phone. It does not reproduce viewport, touch, JavaScript, cookies, carrier IP, geolocation, cache, or the app that opened a link. Use an approved test device or browser emulator to inspect the render stage. Describe the result as “desktop 200 with no Location” or “mobile 302 to an unfamiliar host”, not “confirmed hack” before tracing the source.

Also distinguish a redirect in the first HTTP response from one that occurs after the page loads. If the initial headers already show a 3xx status, the source may be the web server, proxy/CDN, plugin, or PHP before the template finishes. If the first response is 200 and the browser moves later, inspect JavaScript, meta refresh, service worker, tag manager, ads, and third-party scripts. Use the browser Network panel with Preserve log so the first request and triggering script remain visible after navigation.

Check Google’s reports without conflating two issues

Open Search Console Security Issues to see whether Google identified hacked pages or other harmful behavior; check Manual Actions separately if there is a policy notice such as sneaky mobile redirects. A report may include examples but is not a complete URL inventory. URL Inspection shows indexed/live-test information and rendered output, but its live test follows redirects implemented by the page before testing. Record that limitation when comparing the result with server logs.

If Manual Actions reports an issue, follow the instructions for that action. Google advises owners who did not intentionally add a mobile redirect to check whether the site was hacked and audit third-party scripts or elements; remove uncontrolled elements one at a time on the affected pages and retest. Do not remove every analytics, chat, advertising, or widget tag from production at once. Identify the owner, preserve the configuration, and use staging so legitimate business functions do not disappear without evidence.

Trace the source from the outside in

CDN, proxy, and server configuration

Review redirect rules, page rules, workers, transforms, cache, WAF, load balancer, Apache/Nginx/LiteSpeed configuration, and .htaccess if the server reads it. Look for conditions on User-Agent, device class, referrer, cookie, IP, country, or first-visit flags. Compare edge logs with origin logs if the host provides both. Do not edit .htaccess or Nginx in production based on one line; back up the configuration, involve the host, and test one rule at a time.

WordPress, plugins, and themes

Inventory redirect, SEO, security, cache, consent, banner, popup, ad, and affiliate plugins. Review recent changes, path-specific rules, plugins that add conditional hooks, theme headers/footers, mu-plugins, drop-ins, custom code, and scripts inserted through a page builder. If you need to disable a component for diagnosis, do so on staging or during an approved maintenance window; preserve its configuration and test dependent features.

JavaScript and third-party elements

Use the browser Network/Console panels to identify requests or scripts that initiate navigation. Record the script origin, version, tag loader, timing, page that triggers it, and relevant requests. A script may be loaded through a tag manager or plugin without appearing in the theme files, so trace the loading chain. If a vendor manages it, ask the vendor to confirm the version and changes; do not send session secrets or customer data.

Database, accounts, and persistence

If you cannot find a clear rule, review content, options, custom fields, accounts, Application Passwords, cron, and files. Compare each finding with logs; do not delete data based on a generic keyword. Look for a process that can recreate a rule after cleanup. A redirect that returns suggests persistence or an incomplete deployment. If several compromise indicators exist, preserve evidence and use our hacked-website recovery guide as the incident workflow.

Fix the condition that triggers the redirect

Once you find the source, determine whether the rule was approved. For an advertising campaign or mobile landing page, the business owner should confirm the destination, end date, and audience. For an obsolete rule, remove only the unneeded entry and test the former URL and canonical. For a misused third-party script, restrict its access or replace the source, update configuration, and verify with the vendor. For a malicious redirect, preserve a copy, isolate the component, revoke unauthorized access, patch the entry point, and inspect related files, database records, and cron.

Do not redirect to a safe page just to conceal the symptom. Fix the path that generated the decision and record the approver. Purge cache after the origin or rule is repaired, not before evidence is saved. If visitors remain exposed, ask the host to restrict the affected URL, provide an approved maintenance page, or apply temporary containment appropriate to the architecture. Avoid a universal rule that blocks all mobile traffic; it can disrupt legitimate users while leaving malware active.

Prove the fix with the same visitor cohorts

Repeat the original matrix: same URL, desktop/mobile, relevant direct/referrer path, anonymous/login state when safe, network, and cache conditions. Confirm that mobile receives the expected response and no unapproved Location; verify the content after JavaScript runs; check origin and CDN; then test nearby paths to ensure the rule has no unintended effect. Ask the reporter to confirm from their device without visiting the suspicious destination.

Recheck Search Console Security Issues and Manual Actions if either report showed a finding. If a report asks for review, submit it only after the related issues are fixed and describe verifiable changes. Monitor access logs, customer reports, script changes, and test results to ensure the redirect does not return after cache expiry or a plugin update. Escalate to the host/vendor if you cannot access origin logs, CDN rules, or third-party script settings; guessing from a browser is not enough.

Prevention

Review advertising and third-party redirects with an owner list, destination, expiry date, and permitted pages. Limit tag-manager permissions and who can publish changes. Keep an approved baseline for script versions, monitor server/CDN rules, update supported WordPress components, and store logs somewhere the application cannot overwrite. Test mobile and desktop after a deploy or vendor change, not only the homepage while signed in as an administrator.

For general WordPress hardening and account controls, read our guide to securing a small-business WordPress site. Document how customers report the issue, who contacts the host, and how to collect the first response without opening a dangerous destination so the team can act quickly without spreading the link.

Frequently asked questions

Does a mobile-only redirect always mean malware? No. It may come from a business rule, ad script, plugin, cache, or third party. If the behavior is not approved, treat it as a risk and trace its source before making a final diagnosis.

Is changing the user-agent with curl enough to test a phone? No. User-agent is only one variable; mobile browsers also differ in JavaScript, viewport, cookies, IP, and cache. Combine it with an approved emulator/device, devtools, and logs.

Should I use curl -L to see the destination? No, not while the destination is unknown. Record the first response and Location header; do not follow a redirect that could reach phishing, malware, or a download.

When should I ask the host for help? Ask if the redirect comes from server/CDN configuration, origin logs are unavailable, visitors remain exposed, or behavior returns after cleanup. Provide the time, URL, status, sanitized headers, and test matrix.

If mobile visitors are still sent to an unfamiliar domain and you cannot identify the source, request urgent website help to isolate the rule, script, and access without disabling every service.