When a WordPress site redirects to a spam site, the redirect is often conditional rather than constant. It may happen only on mobile, after clicking from Google, or once per visitor after malware sets a cookie, which is why the site can seem normal to its owner. Reproduce the condition, locate the redirect at the WordPress or server layer, remove all persistence, and then close the access route that allowed the compromise.
Why the redirect can be hard to see
Attackers want the redirect to catch ordinary search visitors without being noticed by the site owner, host, or security scanner. They commonly test the browser's user agent, whether the visitor arrived from Google, a language setting, IP address, or the presence of a cookie. The code may set a cookie after redirecting so the next visit looks normal.
For example, a desktop owner who types the domain directly into a browser can get the legitimate home page. A new mobile visitor who reaches the same page from a Google result might be sent to a gambling, pharmacy, or fake update page. Both observations can be true at the same time.
Treat the symptom as evidence of a compromise, not merely a browser cache issue. Begin by preserving the current files, database, and relevant access logs. A backup made before edits can help trace how the redirect was inserted and lets you compare suspicious changes later. It should not be considered a clean restoration source until it has been reviewed.
Reproduce the redirect safely
The key point is to test like the affected visitor. Start in a private or incognito browser window where you are not logged into WordPress. Use a phone or a browser's mobile device mode, then search Google for your business or an affected page and click your own result. Note the exact page, the search query, the initial URL, and any destination domain.
Repeat from a fresh private session between tests. Closing one private tab may not clear every cookie, so use a new window or clear site data. Compare these scenarios: a direct visit, a visit from a Google search result, mobile and desktop, and a logged-out versus logged-in visit. Do not visit suspicious destination sites beyond what the redirect does automatically.
If the redirect happens only after a short delay, keep the browser open long enough to observe it. View page source and the browser's developer tools only if you are comfortable doing so, because an injected script can run after the initial HTML loads. Record whether the original page returns a redirect response or whether JavaScript changes the location after rendering.
Ask anyone who reported the issue for the device type, browser, page they clicked, time, and the destination they saw. One useful report can reveal an exact condition, such as an Android phone arriving from a Google search. That detail narrows the investigation substantially.
Check WordPress URL settings first
The WordPress Address and Site Address settings are legitimate redirect sources, so check them before hunting malware. In the dashboard, open Settings, then General, and confirm the two URLs are your expected domain, protocol, and path. At the database level, the values usually live in the siteurl and home rows of wp_options, or the equivalent table with your custom prefix.
Do not change these values casually on a multisite or a site with a deliberate subdirectory setup. If the values point at an unknown domain, preserve evidence, correct them carefully, and determine who changed them. A configuration change can be the visible symptom of stolen credentials rather than the only malicious change.
Also review wp-config.php for WP_HOME or WP_SITEURL definitions. These constants override the database values and can cause a redirect even when wp_options looks correct.
Find injected JavaScript and PHP
Client-side redirects often come from injected JavaScript in posts, widgets, the theme, or a plugin. Review recent post and page changes, HTML or Custom HTML widgets, header and footer injection settings, theme header.php, footer.php, and functions.php. Search for unfamiliar script tags, remote script URLs, window.location, location.href, delayed timers, obfuscated strings, and code that checks referrers or user agents.
Do not assume the first suspicious script is the whole infection. A small loader can fetch the real payload from another domain, and database content may restore it later. Compare your active theme and plugins with clean copies from their trusted sources. Reinstalling a known-good component is generally safer than attempting to hand-edit a modified copy.
Server-side PHP can redirect before a page is sent. Check core integrity with wp core verify-checksums, then inspect unexpected PHP in wp-content/uploads, wp-content/mu-plugins, the active theme, and plugin folders. Review index.php, wp-config.php, and any files recently changed without a planned deployment. Files with innocent names can still be malicious, so compare their contents and origin rather than trusting the filename.
The database needs equal attention. Check wp_options for unfamiliar autoloaded values, URL settings, injected script, and settings from plugins you do not recognize. Review widgets, post content, and user accounts. A compromised administrator can install a plugin or inject code through the editor without leaving an unusual file in the root directory.
Check redirect rules above WordPress
WordPress is not the only layer that can send a visitor away. Inspect .htaccess in the site root and relevant subdirectories for unfamiliar RewriteRule directives, redirects, conditions based on a referrer or user agent, and odd references to PHP files. Save a copy before editing it so you can compare the previous rules.
Then review the active Apache virtual-host or Nginx server configuration, if you control it or can ask the host to inspect it. Redirect directives, includes, and conditional rules there run outside WordPress. Check the hosting control panel for domain forwarding, parked domains, CDN rules, and edge redirects too. A clean WordPress installation will not override a malicious redirect rule at one of these layers.
If a redirect is coming from a CDN, DNS record, web-server configuration, or hosting account you cannot administer, involve the provider with your test evidence. Ask them to identify the active rule and preserve relevant logs, rather than asking them to make broad changes without a target.
Clean the redirect and close the door
The fix needs to remove the redirect code and the way it is restored. Follow a complete sequence rather than changing a single setting and stopping when the test looks better.
- Take a complete copy of files, database, and logs, then restrict access to known administrators.
- Change WordPress, hosting, SFTP or SSH, database, and control-panel credentials. Rotate application credentials or keys that could be exposed.
- Remove unfamiliar WordPress administrators, hosting users, scheduled tasks, deploy keys, and unknown Search Console users.
- Replace WordPress core, plugins, and themes with clean files from trusted sources. Remove inactive and unused extensions and themes.
- Remove malicious JavaScript, PHP, database records,
.htaccessrules, and server or CDN rules after identifying their role. Check for a cron task or second payload that could recreate them. - Update all retained WordPress components and correct the original vulnerability or credential problem.
- Retest from new private browser sessions under the conditions that previously triggered the redirect.
Do not rely on a redirect plugin to mask the symptom. The hidden code remains risky even if a new rule sends visitors back to the right place. If you are unsure whether an unfamiliar file is an active backdoor, review how to find hidden WordPress admin users and investigate before declaring the site clean.
Prevent spam redirects from returning
Reduce the opportunity for an attacker to write code or change settings. Keep core, plugins, and themes updated, and remove extensions you no longer use. Use unique passwords, enable multi-factor authentication where available, and give administrator access only to people who need it. Do not share a single admin account between an agency and a business owner.
Keep tested backups outside the production hosting account. Review administrator accounts, file changes, cron jobs, domain forwarding, and WordPress settings after any incident. The WordPress hardening checklist provides a practical set of recurring checks.
If your site has been cleaned once but redirects return, assume an entry point or persistence method was missed. A WordPress security audit can inspect the application, server configuration, and access controls together.
When to get help
Get help if you can reproduce a conditional redirect but cannot locate it, if the host configuration is involved, or if the redirect returns after cleanup. West Oakbridge offers WordPress malware removal and WordPress hardening for a complete response and follow-up protection.