If your WordPress site is redirecting to spam for some visitors but appears normal when you check it, do not assume the report is mistaken. The redirect may be conditional: it can depend on how someone arrived, the device or browser they use, or the specific page they open. An infection is one possible cause, but a plugin, advertising code, or other third-party script can also be involved.
A direct visit to the homepage is only one test. Before changing files or removing plugins, try to reproduce the reported behavior and record what you observe. That evidence can help you narrow down the cause and avoid erasing clues that matter during recovery.
Why would a WordPress site redirect some visitors?
Some unwanted redirects are designed to appear only under particular conditions. For example, a visitor may be redirected after arriving from a search result, while someone who types the address directly sees the expected page. The behavior may also vary by mobile device, browser, user agent, or requested URL. A site owner who is logged in may see a different result from a logged-out visitor.
These patterns can make a problem difficult to spot during a quick check. A redirect may happen only once in a session, appear after a delay, or send visitors to different destinations. Caching layers can also make the site respond differently to different visitors. The pattern is useful evidence, but it does not by itself establish that WordPress has been compromised.
Other possible causes include a recently added plugin, an advertising tag, an analytics or marketing script, or code loaded from an external service. A change to server or hosting configuration may also affect how requests are handled. The investigation should consider both WordPress files and services that load into the site.
Test the reported behavior, not just the homepage
Start with the exact URL where the visitor saw the redirect. Use a clean browser session and, when practical, a separate device. Avoid entering passwords or other sensitive information on a destination you do not recognize. If a suspicious site opens, close it rather than interacting with its content.
Keep a simple test record for each attempt. Note:
- Affected URL: Record the full page address, not only your site's domain.
- Device and browser: Include whether the test was on mobile or desktop and which browser was used.
- Visitor state: Note whether you were logged in, logged out, or using a fresh private browsing session.
- Referrer: Record whether the visit began from a search result, a direct address, or another site.
- Time: Save the time and timezone for each attempt.
- Result: Note whether a redirect occurred, the destination, and any intermediate addresses you could observe.
Repeat tests carefully, changing one condition at a time. If the redirect only happens from a search result or on a mobile device, that detail is valuable. A command-line request that records response headers and the redirect chain can provide another comparison, but it may not reproduce behavior that depends on browser scripts, cookies, or a particular referrer. Treat it as one test, not a definitive clean bill of health.
Check more than the homepage
Test the URLs people reported and other important paths, such as product pages, contact forms, or landing pages. A problem can affect one template, a subset of pages, or content that is not linked from the homepage. Search engine results can also point visitors to a page you would not normally open during a routine check.
Review the site's plugins, theme, and recent changes, then consider scripts and services added outside WordPress. Look for unfamiliar code or unexpected changes, but avoid deleting files based only on a hunch. Also review server configuration and any available access or security logs for requests around the times reported. A clean homepage does not rule out a problem elsewhere on the site.
Google's Search Console Security Issues report can show security problems Google has detected and affected examples, but the absence of a warning does not prove that every page and visitor path is clean. Google's guidance on how to recognize a hacked site can also help you understand signs that warrant investigation.
Preserve evidence before cleanup
When the redirect is reproducible, capture the details before making changes that could remove traces or alter the behavior. Preserve:
- Screenshots or a screen recording showing the page and redirect, if safe to capture.
- The affected URLs, destination addresses, test conditions, and timestamps with timezone.
- The redirect chain or response details from any browser or command-line test.
- Relevant web server, hosting, security, or application logs that are available.
- A record of recent plugin, theme, content, account, or hosting changes.
- A site snapshot, including relevant files and database data, stored securely before cleanup.
Keep original evidence separate from working copies, and limit access to people involved in the investigation. NIST's guide to forensic techniques in incident response discusses collecting and preserving information as part of an investigation. For a practical overview of the cleanup process after a warning, see our guide to what to do about a Google malware warning on a WordPress site.
Plan investigation and recovery carefully
Once you have recorded the behavior, investigate the likely source rather than treating the visible redirect alone. Compare affected and unaffected pages, review recent changes, and assess WordPress components as well as third-party scripts and server settings. If you find signs of unauthorized changes, prioritize restricting access to the site and having a qualified person assess the environment before making broad edits.
Cleanup may need to address more than the page a visitor saw. Removing a suspicious snippet without finding how it was added can leave the underlying access or modified component in place. After remediation, repeat the original test matrix and check the affected URLs again. Continue monitoring for the same behavior and review the site's security status in Search Console.
For ongoing oversight, our article on WordPress malware monitoring explains the role monitoring can play in detecting and responding to suspicious changes.
Frequently asked questions
Can malware redirect visitors from Google search results only?
Yes, a redirect can be conditional on a visitor arriving from a search result. That behavior is a reason to investigate, but it is not enough by itself to confirm malware. Test the same URL through different paths and check for scripts, plugins, and other possible causes.
Why does my website redirect on mobile but not desktop?
The behavior may depend on the device, browser, or user agent, or on scripts that load differently in a mobile browser. Compare the same URL and referrer across devices, and record the result rather than relying on a desktop-only check.
Could an ad, plugin, or third-party script cause a spam redirect?
Yes. A third-party script or a recent plugin or advertising change may be involved. Review recent changes and test components methodically so you can distinguish a site infection from code or behavior introduced by an external service.
Can checking only the homepage miss a WordPress infection?
Yes. Redirects may affect only specific URLs, page types, or visitor conditions. Check reported pages and important site paths, and compare results across different visitor scenarios.
Conclusion
A WordPress site redirecting to spam deserves a careful investigation, even if the owner cannot reproduce it on a direct visit. Record the conditions, preserve evidence, and examine affected pages and third-party code before cleanup. Zevonix Cloud provides WordPress management and malware removal. If you need help investigating a redirect, contact Zevonix Cloud at (904) 658-0777.