Quick answer
WordPress malicious redirects usually happen when attackers inject JavaScript, PHP, database content, or server rules that send visitors to spam pages. To fix them, test the site as a real visitor, identify where the redirect is loaded, remove the malicious code, delete backdoors, patch the entry point, clear caches, and retest from mobile, desktop, and search-result visits.
Malicious redirects are one of the most frustrating WordPress infections because they are inconsistent by design. A site owner may open the homepage and see nothing unusual while customers are sent to fake CAPTCHA pages, gambling sites, adult pages, fake software updates, or browser notification scams. The redirect may appear once, disappear after a cookie is set, or trigger only on mobile devices.
This guide explains why WordPress redirect malware happens, where attackers hide it, how to investigate it, and what prevention steps reduce the chance of reinfection.
Why WordPress redirects are often hard to reproduce
Attackers do not always redirect every visitor. They may check whether the visitor is logged in, whether the referrer is Google, whether the device is mobile, whether the IP address is new, or whether a cookie has already been set. This helps the malware make money from real visitors while avoiding detection by the site owner.
That is why a single desktop test is not enough. Use a private browser window, mobile device, different network, and several landing pages. If users report that redirects happen after clicking search results, test that path too. For mobile-only infections, the mobile redirect malware removal service explains the issue more specifically.
Common causes of redirect malware
Redirect malware usually starts with an entry point. Common causes include outdated plugins, abandoned themes, weak administrator passwords, nulled premium plugins, compromised hosting accounts, exposed backup archives, and insecure file permissions. Once attackers gain access, they add redirect logic somewhere that loads on many pages.
The code may be small. A few lines of obfuscated JavaScript can load a remote script that controls the redirect. A PHP snippet can inject scripts into page output. A database option can add malicious content to the header or footer. A server rule can redirect traffic before WordPress even loads.
Where redirect malware hides
Start with the places that affect many pages. Theme files such as header.php, footer.php, functions.php, and template parts are common targets. Plugin files are also common, especially plugins that already load scripts on the front end. The uploads directory should be reviewed for PHP files, because normal media uploads usually do not need executable code.
Also inspect .htaccess rules, wp-config.php, mu-plugins, widgets, custom HTML blocks, database options, and recently modified files. If a redirect appears on every page, the source is often global. If it appears on only a few pages, check post content, Elementor or block content, and page-specific scripts.
When the redirect is JavaScript-based, review the malicious JavaScript removal service. If the redirect uses fake verification prompts, see the fake CAPTCHA malware removal service.
How to investigate without breaking the site
Before changing anything, take a full file and database backup. Redirect malware can be spread across multiple locations, and deleting the first suspicious file may remove evidence while leaving the persistence mechanism behind. Review server logs, file modification dates, active users, recently installed plugins, and Search Console warnings.
Use a structured checklist. Compare WordPress core files with clean originals. Review plugin and theme files for encoded code, remote script calls, unfamiliar domains, and suspicious redirects. Search the database for redirect domains, script tags, iframe tags, and encoded payloads. Check cron events and admin users. If the site has a CDN or cache plugin, remember that cached pages may still contain old malicious output.
Why one scanner is not enough
Automated scanners are helpful, but redirect malware often uses conditional logic and obfuscation. A scanner may miss a script that loads only for mobile visitors or only after a search click. It may also report a symptom without identifying the entry point.
Use scanners as one signal, not the full answer. Manual review is especially important when the redirect is inconsistent. The OWASP Top Ten is useful background for common web application risks, but WordPress cleanup also requires platform-specific review of plugins, themes, users, and database content.
Cleanup steps that actually reduce reinfection
- Remove injected scripts, PHP loaders, database injections, and malicious server rules.
- Delete hidden backdoors and unknown admin users.
- Patch or replace vulnerable plugins and themes.
- Rotate WordPress, hosting, SFTP, database, and email credentials.
- Clear page cache, object cache, CDN cache, and server cache.
- Retest as a logged-out visitor from multiple devices and paths.
If the site has already been flagged by Google, cleanup should happen before review. Redirects connected to search warnings often require both malware removal and blacklist recovery work.
How to tell whether the redirect is file-based or database-based
A file-based redirect often appears in many pages because a theme, plugin, or server rule loads it globally. Clues include recent file modification dates, suspicious code in header or footer files, or a redirect that appears before the page content loads. A database-based redirect may be stored in widgets, custom HTML blocks, Elementor content, posts, options, or injected scripts saved by a plugin setting.
Both types can exist at the same time. If you clean files but the redirect remains, search the database. If you clean the database but the redirect returns, look for a file backdoor that is rewriting the database. This back-and-forth is why a structured investigation is better than deleting the first suspicious item found.
What to document during redirect cleanup
Keep a simple record of the redirect destination, affected URLs, device type, referrer, suspicious files, changed database rows, and removed users. Documentation helps if a host, ad platform, or Google asks what was fixed. It also helps confirm whether a later redirect is the same infection returning or a new issue with a different source.
This record does not need to be complex. A short note with dates, URLs, and screenshots is usually enough to guide later review and avoid repeating the same unsuccessful cleanup steps.
Prevention after redirect cleanup
Keep WordPress core, plugins, and themes updated. Remove unused extensions instead of leaving them inactive for months. Avoid nulled software, use strong unique passwords, enable two-factor authentication for administrators, and keep offsite backups. Review admin accounts regularly and monitor file changes.
Prevention is not only about tools. It is also about reducing the number of ways attackers can write code to the site. The fewer unused plugins, weak accounts, and writable directories you have, the smaller the attack surface becomes.
FAQ
Why does my WordPress site redirect only once?
Some malware sets a cookie after redirecting a visitor so the same person is not redirected repeatedly. This helps hide the infection.
Can .htaccess cause malicious redirects?
Yes. Server rewrite rules can redirect visitors before WordPress loads, so .htaccess or server configuration should be checked.
Will deleting an infected plugin fix the redirect?
Sometimes, but not always. The same compromise may include database injections, backdoors, or hidden admin users.
What if the redirect is only on Google traffic?
That is common. The malware may check the referrer and redirect only visitors coming from search results.