You type your domain into the address bar, hit enter, and land somewhere else entirely, a pharmacy ad, a fake tech-support page, a gambling site in a language you don’t read, or sometimes just a blank page that redirects again before you can even read the URL. This is one of the more alarming things that can happen to a WordPress site because it usually means someone else has write access to your files or your database, and every minute it stays live costs you search rankings, visitor trust, and in the worst cases a manual action from Google that takes weeks to clear. The fix depends entirely on correctly identifying which layer the redirect is happening at, because “clean the malware” is not one action, it’s five or six different places to check, and most cleanup attempts fail because they only check one or two of them.
Start by establishing what kind of redirect you’re actually looking at
Not every unwanted redirect is malware. Before you assume the worst, separate the symptom into one of three categories, because they have completely different causes and completely different fixes.
Redirects everyone sees, every time, from every device. This points to something server-side and unconditional, a hijacked .htaccess file, a corrupted siteurl/home value in the database, or a DNS record pointed at the wrong place. It’s the easiest category to diagnose because it’s consistent and reproducible.
Redirects that only happen on mobile, or only for visitors coming from Google search, or only intermittently. This is the signature of conditional malware, malicious code deliberately written to check the user-agent string or the HTTP referrer header before deciding whether to redirect, specifically so the site owner checking from a desktop browser with no referrer sees nothing wrong while real search visitors get sent to a spam destination. This category is more dangerous precisely because it hides from casual inspection, and it’s the one that most often gets missed by a quick look at the homepage.
Redirects that only happen after login, or only in wp-admin. This usually points to a compromised admin account being used to inject malicious JavaScript into a specific area, or a malicious plugin/theme masquerading as a legitimate one.
Check the database first: siteurl and home
The single fastest thing to check, and the one most tutorials bury too far down the list, is the WordPress Address (URL) and Site Address (URL) fields under Settings → General, which map directly to the siteurl and home options in the wp_options table. If an attacker (or, just as commonly, an old un-fixed migration) changed either of these to point at a different domain, every single page load will redirect there because WordPress builds nearly every URL on the page from those two values. If you can’t reach wp-admin because the redirect happens before you get there, you can check and fix this directly via phpMyAdmin or WP-CLI without touching the admin UI at all:
wp option get siteurl
wp option get home
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'This single check resolves a surprising share of “my site is redirecting” reports that turn out to have nothing to do with malware at all, a botched staging-to-live migration, a broken URL-replace script, or a hosting move that didn’t fully complete.
Check .htaccess for injected rewrite rules
Apache-based hosting reads .htaccess on every request, and it’s one of the most common places attackers plant redirect logic because a single file edit affects the entire site instantly, no plugin or theme access required. Open the file via FTP, SFTP, or your host’s File Manager and look for anything above or below the standard WordPress block, which should read exactly:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressAnything outside that block, especially RewriteCond lines checking HTTP_USER_AGENT or HTTP_REFERER, or a bare Redirect / RewriteRule pointing at an external domain, is worth immediate suspicion. Malicious redirect rules in .htaccess very often specifically target search-engine bot user-agents differently from regular browsers, which is exactly the “looks fine to me, but Google Search Console shows a manual action” pattern. If you find anything unfamiliar, delete it, save, and WordPress will regenerate a clean default block the next time you resave permalinks under Settings → Permalinks.
Search the database for injected redirect scripts
If the file system checks out clean, the injection is probably living inside post content, widget content, or theme option fields stored as serialized PHP arrays in wp_options or wp_postmeta. This is trickier to search for by hand because serialized data includes length prefixes (s:14:"some string";) that break if you edit the string length without recalculating the prefix, so a manual find-and-replace inside phpMyAdmin can corrupt the row rather than fix it. A safer approach is WP-CLI’s search-replace command, which understands serialization and updates the length prefixes correctly:
wp search-replace 'malicious-domain.com' '' --all-tables --dry-runRun it with --dry-run first to see exactly what it would change before committing, then drop the flag once you’ve confirmed the matches are genuinely malicious content and not, say, a legitimate outbound link you actually want to keep. Also check widgets specifically, the classic Custom HTML widget and the older Text widget are common injection points because their content renders unescaped, and a single hidden <script> tag inside one can redirect the entire page after load.
Audit every plugin and theme file, not just the active ones
Inactive plugins and themes still sit on disk and, in some vulnerable configurations, their PHP files can still be reached directly and executed even while “deactivated” in the WordPress admin, deactivation only stops WordPress from loading the plugin’s hooks, it doesn’t remove the files or block direct access to them. Redirect malware frequently hides inside a plugin or theme that looks legitimate at a glance: a file named something like class-wp-cache.php sitting in an otherwise normal-looking plugin folder, injected via a vulnerability in a genuinely popular plugin that was outdated at the time of the breach. Compare your installed plugin files against a fresh copy from WordPress.org using a diff, or use a malware scanner that does file-integrity checking against known-good checksums, Wordfence and Sucuri’s free plugins both do this, and Sucuri additionally offers a free remote site check at sitecheck.sucuri.net that scans your live site from the outside without needing WordPress access at all, which is useful precisely because it sees what a real visitor sees, including any conditional cloaking based on referrer.
Pirated (“nulled”) themes and plugins are a leading cause, not a coincidence
If a premium theme or plugin was downloaded from anywhere other than the official developer, WordPress.org, or a legitimate marketplace, treat it as a prime suspect regardless of how long it’s been “working fine.” Nulled software is frequently redistributed with backdoors already baked in specifically so the distributor can later monetize every site that installs it, often by injecting exactly this kind of conditional spam redirect months after installation, timed to avoid an obvious cause-and-effect. There’s no safe way to clean a nulled file, the only reliable fix is deleting it entirely and replacing it with a legitimately licensed copy from the original source.
Weak credentials and how attackers actually get in
Redirect malware doesn’t appear out of nowhere; it requires the attacker to have gotten write access somehow, and the overwhelming majority of cases trace back to one of a small number of entry points: a reused or weak admin password caught in a credential-stuffing attack, a vulnerable outdated plugin with a known CVE, an exposed wp-config.php backup file left on the server by an old migration tool, or SFTP/hosting-panel credentials that leaked separately from WordPress itself. Checking Users → All Users for any admin account you don’t recognize, and cross-referencing the WordPress activity log (via a plugin like WP Activity Log, or your host’s raw access logs if you don’t have one installed) for login events at odd hours, will often show you exactly how and when the compromise happened, which matters because you need to close that specific door, not just clean the mess it let in.
DNS and domain-level redirects live entirely outside WordPress
If everything above checks out clean and the redirect still happens even when you load the site directly by IP address bypassing DNS, the problem isn’t WordPress at all, it’s your domain registrar or DNS provider. Check your domain’s nameservers and A/CNAME records against what your host actually expects; a compromised registrar account, an expired domain that’s been parked with an ad redirect by the registry, or a DNS provider account taken over via a weak or unprotected email login can all produce exactly this symptom while your WordPress installation itself is completely clean. Enable two-factor authentication at the registrar level specifically, since it’s frequently overlooked in favor of securing WordPress itself.
A concrete example: the Japanese keyword hack pattern
One of the most well-documented redirect campaigns over the past several years follows a specific and recognizable pattern often called the “Japanese keyword hack,” even though it now targets sites regardless of language. It works by creating hundreds of fake pages with Japanese-language spam content, indexing them in Google under the compromised site’s domain, and then redirecting anyone who actually clicks through from a search results page to an off-site destination, while the site owner, browsing normally, never lands on those fake pages and sees nothing wrong. The giveaway is usually a spike in Search Console’s Performance report showing thousands of new impressions for search queries in a language the site has never published in, paired with a click-through rate near zero because visitors immediately bounce to the redirect destination rather than staying on a results page. If you see foreign-language queries you don’t recognize appearing in Search Console performance data, that’s a strong signal to run the Security Issues check and a full malware scan even if the homepage looks completely normal.
Reverse proxies and CDN edge rules can also be the culprit
If your site sits behind Cloudflare, Sucuri’s firewall, or a similar reverse proxy, redirect rules can be configured at that layer entirely independent of WordPress or your server. A misconfigured Page Rule, a forgotten “Always Use HTTPS” redirect chain conflicting with a WordPress-level HTTPS redirect, or, in a genuine compromise scenario, an attacker who gained access to your CDN account dashboard specifically rather than your hosting account, can all produce site-wide redirects that no amount of WordPress-side cleanup will fix, because the request never actually reaches your server in a way WordPress can influence. Log into your CDN or firewall dashboard directly and check the Page Rules, Redirect Rules, or Workers sections for anything unfamiliar, and treat access to that dashboard with the same password hygiene as your WordPress admin account, since it’s frequently protected by a weaker, older password precisely because people forget it’s a separate login from hosting.
Staging sites and duplicate installs cause a specific, non-malicious version of this
Not every case is an attack. A staging subdomain (staging.yourdomain.com) or a leftover copy from a migration that still has search-engine indexing enabled can get crawled and ranked by Google independently of your live site, and if that staging copy has an outdated or misconfigured siteurl pointing back at production, visitors who land on the staging version from a search result can experience what looks identical to a malicious redirect but is actually just a configuration leftover. Check Google for site:staging.yourdomain.com or any other subdomain variant you’re aware of, and if you find an indexed staging copy, add a noindex meta tag and a password gate to it immediately, then request removal of the indexed URLs through Search Console.
After cleanup: verify with Google Search Console, not just your own browser
Because so much of this malware is conditional on referrer or user-agent, checking “it looks fine when I visit it” is not sufficient proof of a clean site. Google Search Console’s Security Issues report (under the Security & Manual Actions section) will show you exactly what Google’s crawler saw, including cloaked redirects your own browser never triggers, and it’s the closest thing to ground truth for how search visitors are actually being treated. If Search Console flags an issue, fix the root cause first, then use the “Request Review” feature once you’re confident the site is genuinely clean, requesting review before the fix is complete just burns your review allowance and delays real resolution.
When the redirect only happens after clicking an ad or affiliate link
A narrower variant worth ruling out separately: if the redirect only happens when visitors arrive through a specific ad network, affiliate link, or third-party embed rather than through organic navigation, the cause may not be your WordPress install at all but a compromised third-party script you’re loading, an ad network tag, an analytics snippet, or an embedded widget from an external service. Open your browser’s Network tab, reload the page, and look for any request to a domain you don’t recognize firing right before the redirect happens; that request, not your WordPress files, is very likely the source. Remove or replace the offending script and confirm the redirect stops before spending further time inside WordPress itself.
Locking the door after you’ve cleaned house
Once the redirect is gone, change every credential that touches the site, WordPress admin passwords, SFTP/SSH passwords, database passwords, and hosting panel logins, because you can’t be certain which one was the entry point, and reusing any of them risks a rapid reinfection. Update WordPress core, every plugin, and every theme to their latest versions, remove anything inactive that you don’t actively need (inactive plugins are still an attack surface sitting on disk), and consider a security plugin with file-change monitoring so a future injection gets flagged within hours instead of discovered by a customer complaint weeks later. Regular offsite backups matter here too, not as a redirect fix but as the fallback that turns “we have to rebuild the site from scratch” into “we restore yesterday’s known-good copy and re-apply today’s legitimate content changes.”
Building a monitoring habit so the next one gets caught in hours, not months
The gap between “got compromised” and “noticed the compromise” is where the real damage happens, search rankings erode gradually as Googlebot repeatedly crawls the cloaked redirect, and by the time a customer or a drop in traffic tips you off, weeks of accumulated ranking loss can take longer to recover than the cleanup itself. A handful of low-effort habits close that gap significantly. Set up an uptime and content-change monitor (many hosting control panels include one, or a free service like UptimeRobot can hit your homepage every few minutes and alert on unexpected redirect responses). Enable file-integrity monitoring through a security plugin so unauthorized changes to core, theme, or plugin files trigger an email the same day rather than being discovered during an unrelated troubleshooting session months later. And periodically, monthly is reasonable for most sites, run your own domain through Sucuri’s free external scanner and check Search Console’s Security Issues panel even when nothing seems wrong, precisely because the conditional, cloaked version of this problem is built to stay invisible to exactly the kind of casual check most site owners rely on.
None of this needs to be expensive or complicated. A basic security plugin, a scheduled reminder to glance at Search Console once a month, and the discipline to buy plugins and themes only from sources you can verify are worth far more than any single cleanup tool once the damage is already done. Redirect malware is unpleasant to deal with, but it is also one of the more mechanically understandable problems in WordPress maintenance once you know the short list of places it hides, database options.htaccess, serialized content, plugin and theme files, DNS, and third-party scripts, and working that list in order rather than guessing is what actually gets a compromised site clean the first time instead of the third.
Related reading:
Best Managed WordPress Hosting Providers