Interactive Troubleshooter

Published: Oct 14, 2026

WordPress Redirecting to Spam Websites: How to Fix It

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

This interactive diagnostic tree resolves WordPress websites redirecting visitors to malicious spam websites, phishing pages, or rogue ad networks. It guides webmasters through locating base64-encoded eval injections in theme header/footer files, cleaning compromised database option tables, sanitizing .htaccess redirection rules, and patching vulnerable plugin backdoors.

Full Diagnostic Tree & Step-by-Step Overview

When and how do visitors or administrators experience the unwanted redirects on your WordPress website?

Visitors arriving via search engine results (Google/Bing) get redirected, but typing the URL directly works normally.
Every visitor (including logged-in admins) gets redirected immediately upon landing on the homepage or clicking internal links.
Redirects occur only on mobile devices, or when users click anywhere on the page (clickjacking/malicious JS injection).
Attempting to log into /wp-admin/ redirects to an external spam site or throws database connection errors.

Where is the search engine redirect mechanism embedded within your WordPress file or database structure?

Malicious RewriteEngine rules or conditional User-Agent checks injected into the root `.htaccess` file.
Obfuscated base64 PHP `eval()` strings injected into active theme `header.php` or `functions.php` files.
Malicious JavaScript code loaded dynamically via compromised plugins or injected into `wp_options` table.
Rogue backdoor script hiding inside the `wp-includes` or `wp-content/uploads` directory.

Cleaning Malicious Rewrite Rules in Root .htaccess Files

Solution:

Root Cause: .htaccess User-Agent Conditional Redirection Injection

Attackers often gain FTP or WordPress dashboard access to inject custom Apache RewriteCond rules into the root .htaccess file. These rules check the visitor's HTTP_USER_AGENT header: if the request originates from a search engine crawler (Googlebot, Bingbot), the server serves legitimate content for SEO indexing, but regular human visitors are intercepted and redirected to spam or scam websites via 301/302 redirects.

Diagnostic Verification:

Access your web hosting file manager or SFTP, navigate to your WordPress root directory (public_html), and open .htaccess. Look for unrecognized RewriteRule lines referencing external domains or conditional bot checks.

Step-by-Step Fix:

1Open .htaccess in cPanel File Manager or SFTP client.

2Back up clean WordPress Default Rules:

Replace the entire contents of .htaccess with standard default WordPress rules:

# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

3Save File Permissions:

Set file permissions for .htaccess to 644 to prevent unauthorized modification.

4Clear server cache and test browsing in an incognito window.

Prevention & Long-Term Monitoring:

Restrict write permissions on .htaccess and monitor file modification timestamps regularly.

Purging Base64 Eval Injections from Theme Header and Functions Files

Solution:

Root Cause: Base64 Obfuscated PHP `eval()` Payload Execution

Theme header (header.php), footer (footer.php), or functions (functions.php) files are frequent targets for script injection. Malware authors inject obfuscated base64-encoded strings wrapped in eval(base64_decode(...)) functions. When executed by PHP, this decodes into a live script that checks referrer headers and redirects human users to spam domains while remaining invisible to administrators browsing while logged in.

Diagnostic Verification:

Open your active theme directory (wp-content/themes/your-active-theme/) and inspect header.php or functions.php. Look for long blocks of randomized alphanumeric text enclosed in eval(base64_decode()).

Step-by-Step Fix:

1Open theme directory via cPanel File Manager or SFTP.

2Edit header.php and remove any unauthorized PHP blocks, especially eval(), base64_decode(), or gzinflate() functions.

3Reinstall Fresh Theme Copy:

Download a fresh, uncompromised copy of your active theme from the official developer repository and overwrite the infected files.

4Scan Theme Files:

Install Wordfence Security or Sucuri Security plugin to run a deep malware signature scan across all theme templates.

Prevention & Long-Term Monitoring:

Avoid downloading nulled or cracked premium themes from untrusted third-party websites.

Sanitizing Malicious Serialized Scripts in the Database wp_options Table

Solution:

Root Cause: Database Option Table Script Injection (`wp_options`)

Advanced malware injects malicious JavaScript URLs or PHP redirection snippets directly into the wp_options table (specifically under options like siteurl, home, active_plugins, or custom serialized transients). Because WordPress loads autoloaded options on every page request, these database injections execute instantly without needing physical file modifications.

Diagnostic Verification:

Open phpMyAdmin in cPanel > select your WordPress database > open wp_options. Search option_value fields for suspicious external URLs or base64 strings.

Step-by-Step Fix:

1Access phpMyAdmin via your hosting control panel.

2Open wp_options table and search for suspicious external domains or javascript snippets in option_name or option_value.

3Check Site URL and Home URL:

Ensure siteurl and home point strictly to your genuine domain name (e.g., https://example.com), not an external spam redirect.

4Clean Autoload Options:

Run a database query to audit autoloaded options or use a trusted security plugin like Wordfence to scan database tables for malicious injections.

Prevention & Long-Term Monitoring:

Protect database credentials in wp-config.php and use strong, unique database passwords.

Locating and Eradicating Hidden Backdoor Scripts in Uploads and Includes

Solution:

Root Cause: Hidden PHP Backdoor Droppers in Uploads and Core Directories

Attackers exploit vulnerable plugins to upload disguised PHP scripts (e.g., image.php.suspected, wp-class.php, or random alphanumeric .php files) inside media upload folders (wp-content/uploads/2026/10/) or core directories (wp-includes/). Apache servers are often misconfigured to execute PHP code inside upload directories, allowing these backdoors to run independently.

Diagnostic Verification:

Scan wp-content/uploads/ for files ending in .php, .ico.php, or .jpg.php using your file manager search utility.

Step-by-Step Fix:

1Audit Upload Directory for Executable Files:

In cPanel File Manager, navigate to wp-content/uploads and search for .php files. Delete every single PHP file found in the uploads directory.

2Disable PHP Execution in Uploads via .htaccess:

Create a new .htaccess file inside wp-content/uploads/ containing:

<Files *.php>
Deny from all
</Files>

3Reinstall Fresh WordPress Core Files:

Download a fresh WordPress zip archive, extract it, and overwrite wp-admin and wp-includes directories via SFTP.

Prevention & Long-Term Monitoring:

Restrict PHP execution privileges across all non-system directories on your web server.

What specific file or server configuration is triggering universal redirects for all visitors and administrators?

Compromised index.php in the WordPress root directory containing injected script headers.
Malicious code snippet injected into the top or bottom of `wp-config.php` configuration file.
Infected mu-plugins (Must-Use plugins) executing silently without appearing in the standard dashboard plugin list.
Compromised server-wide Nginx/Apache virtual host configuration or DNS hijacking at registrar level.

Replacing Compromised Root index.php and Core Entry Files

Solution:

Root Cause: Root `index.php` Binary Tampering

The root index.php file is the primary entry point for all frontend WordPress traffic. When malware overwrites index.php with malicious include statements or redirect headers, every visitor landing on the domain is intercepted before WordPress bootstrapping even begins.

Diagnostic Verification:

Open the root index.php file in cPanel File Manager. Standard WordPress index.php contains only a few lines referencing wp-blog-header.php. If it contains eval(), base64, or external URLs, it is compromised.

Step-by-Step Fix:

1Open root directory (public_html) via file manager or SFTP.

2Delete compromised index.php.

3Upload Fresh Core index.php:

Download a fresh copy of WordPress core and upload the official, pristine index.php file.

4Verify File Permissions:

Set file permissions for index.php to 444 (read-only) to prevent automated malware modification.

Prevention & Long-Term Monitoring:

Implement strict file integrity monitoring (FIM) via security plugins to alert on core file changes.

Sanitizing wp-config.php Database and Initialization Redirection Hooks

Solution:

Root Cause: Malicious Auto-prepend or Database Redirection in wp-config.php

wp-config.php loads before any other file during WordPress initialization. Attackers frequently append malicious auto_prepend_file directives or custom database hook overrides to the bottom of wp-config.php, forcing every page load to execute external redirection scripts.

Diagnostic Verification:

Open wp-config.php and inspect the bottom of the file below database credentials. Look for unverified require_once, auto_prepend_file, or base64 strings.

Step-by-Step Fix:

1Open wp-config.php via cPanel File Manager or SFTP.

2Review and Clean File Contents:

Keep only standard database definitions (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST), security salts, and the ABSPATH declaration. Remove any stray PHP code blocks.

3Set Strict File Permissions:

Change file permissions for wp-config.php to 400 or 440 so web processes cannot modify it.

Prevention & Long-Term Monitoring:

Lock down wp-config.php permissions and restrict SFTP access credentials.

Purging Malicious Must-Use Plugins (mu-plugins) and Hidden Backdoors

Solution:

Root Cause: Silent Execution via Must-Use Plugins (`mu-plugins`)

Must-Use plugins (mu-plugins) located in wp-content/mu-plugins/ execute automatically on every WordPress load and cannot be deactivated or deleted through the standard WordPress admin dashboard plugins menu. Malware authors frequently drop malicious PHP scripts here so they remain active even if all standard plugins are uninstalled.

Diagnostic Verification:

Navigate to wp-content/mu-plugins/ via file manager. If this directory exists, inspect every .php file inside it for hidden redirection logic.

Step-by-Step Fix:

1Open wp-content/mu-plugins/ via file manager or SFTP.

2Review and Remove Malicious Files:

Delete any unverified PHP scripts or loader files inside mu-plugins/ (unless specifically required by your hosting provider, such as Kinsta or Pantheon system MU-plugins).

3Audit standard wp-content/plugins/ directory for rogue folders.

Prevention & Long-Term Monitoring:

Periodically inspect the mu-plugins directory during security audits.

Fixing Server-Level Nginx/Apache Virtual Host Redirects and DNS Hijacking

Solution:

Root Cause: Server Virtual Host Misconfiguration or Domain Registrar DNS Hijacking

If cleaning WordPress core files and database tables does not stop redirects, the compromise may exist outside WordPress at the server configuration level (Nginx nginx.conf, Apache httpd.conf) or your domain registrar account (DNS A/CNAME records hijacked to point to spam server IPs).

Diagnostic Verification:

Check domain DNS records using a public lookup tool (e.g., DNSChecker) to verify that your domain points directly to your genuine hosting server IP address.

Step-by-Step Fix:

1Audit Domain Registrar DNS Records:

Log into your domain registrar account (Namecheap, GoDaddy, Cloudflare) and verify A, CNAME, and NS records.

2Audit Web Server Configuration:

Contact your web hosting support team to verify that Nginx/Apache virtual host configurations do not contain unwanted server-block redirect rules.

3Enable Cloudflare Proxy / Web Application Firewall (WAF) to filter malicious traffic at the edge.

Prevention & Long-Term Monitoring:

Enable Multi-Factor Authentication (2FA) on your domain registrar and hosting accounts.

When do the mobile-only or user-interaction redirects trigger on your WordPress site?

Redirects occur exclusively on mobile devices (smartphones/tablets), serving spam pop-ups or app installation offers.
Clicking anywhere on the webpage body opens an external spam tab (invisible clickjacking JavaScript overlay).
Malicious code is injected dynamically via a compromised third-party Google Tag Manager or external tracking script.
Browser extension or third-party ad network script injects redirects into specific visitor geographic regions.

Removing Mobile-Specific User-Agent Redirection Scripts

Solution:

Root Cause: Mobile User-Agent Cloaking and Device-Targeted Malware

Malware scripts often inspect the incoming HTTP_USER_AGENT string to detect mobile operating systems (iOS, Android). If a mobile device is detected, the script injects an iframe or meta-refresh tag redirecting the user to adult websites, survey scams, or fake app installs, while desktop visitors see a normal website to evade detection by site owners.

Diagnostic Verification:

Browsing the site on a desktop works fine, but viewing it on a smartphone triggers immediate unwanted tab redirects.

Step-by-Step Fix:

1Search for Mobile Detection Code:

Use a security scanner (Wordfence) to search theme and plugin files for wp_is_mobile(), Android, iPhone, or base64 mobile redirect strings.

2Clean Theme Footer/Header:

Remove injected JavaScript snippets from footer.php or header templates that check screen width or user agent.

3Clear Cloudflare / Server Page Caching:

Purge all server and CDN caches so cached mobile redirect pages are cleared.

Prevention & Long-Term Monitoring:

Test your live website periodically using mobile user-agent switchers in desktop browsers.

Eliminating Clickjacking and Invisible DOM Overlays

Solution:

Root Cause: Invisible DOM Clickjacking Overlays (`z-index` Injection)

Injected JavaScript creates an invisible, transparent <div> or <iframe> overlay spanning 100% of the viewport width and height (z-index: 999999). Because the invisible element sits on top of all page content, the user's very first click anywhere on the page registers on the overlay, triggering an instant pop-under window to an advertiser's spam site.

Diagnostic Verification:

Inspect page source or use browser Developer Tools Elements tab to look for rogue, absolute-positioned transparent divs covering the document body.

Step-by-Step Fix:

1Audit JavaScript Files in Plugins and Themes:

Scan custom JS files in wp-content/themes/ and wp-content/plugins/ for obfuscated eval() or dynamic DOM element creation.

2Reinstall Clean Plugins:

Delete and reinstall all installed plugins from official ZIP packages to replace corrupted script files.

3Implement Content Security Policy (CSP):

Add a strong CSP header to .htaccess to restrict unauthorized script loading from external domains.

Prevention & Long-Term Monitoring:

Monitor custom JavaScript inclusions and avoid installing unverified plugins.

Auditing Google Tag Manager and External Tracking Script Injections

Solution:

Root Cause: Compromised Google Tag Manager Container or Analytics Scripts

If site owners grant administrative access to third-party marketers via Google Tag Manager (GTM) or Google Analytics, attackers can compromise the GTM container and inject arbitrary JavaScript tags that fire on every page view, redirecting visitors to spam networks without touching server-side WordPress files.

Diagnostic Verification:

Server file scans show 100% clean WordPress core and theme files, yet visitors experience live browser redirects.

Step-by-Step Fix:

1Audit Google Tag Manager Workspace:

Log into Google Tag Manager (tagmanager.google.com) and review all active Tags, Triggers, and Variables.

Delete any unfamiliar custom HTML tags or external script injections.

2Review User Access Permissions:

Remove unauthorized user accounts from your GTM container and Google Analytics properties.

3Check Theme Header for Injected GTM/Tracking Snippets:

Verify that tracking codes in header.php match your official account IDs.

Prevention & Long-Term Monitoring:

Audit marketing container permissions and review GTM version history logs regularly.

Resolving Geo-Targeted CDN and Edge Worker Script Redirections

Solution:

Root Cause: CDN Edge Worker / Cloudflare Worker Compromise

When a website uses a Content Delivery Network with edge computing capabilities (such as Cloudflare Workers or CloudFront Functions), attackers who compromise CDN account credentials can deploy malicious worker scripts at the edge. These scripts intercept regional traffic (e.g., visitors from specific countries) and inject spam redirects before requests even reach the WordPress hosting server.

Diagnostic Verification:

Redirects occur only for visitors from specific geographic regions, while server logs show no evidence of file tampering on the origin server.

Step-by-Step Fix:

1Secure CDN Account:

Log into your CDN provider account (Cloudflare, Fastly), change your password immediately, and enable hardware-based 2FA.

2Audit Edge Workers and Page Rules:

Check for unauthorized Workers scripts, routing rules, or Page Rules redirecting traffic.

3Pause CDN Proxy Temporarily:

Switch Cloudflare DNS records to 'DNS Only' (grey cloud) to bypass edge workers and verify if redirects stop on the origin server.

Prevention & Long-Term Monitoring:

Protect CDN control panel credentials with strict multi-factor authentication.

What specific error or redirection behavior occurs when attempting to access the WordPress login portal (`/wp-admin/`)?

Attempting to visit `/wp-admin/` redirects to an external spam site, preventing dashboard login.
Logging into `/wp-admin/` succeeds briefly, but backend files show rogue administrator accounts created by hackers.
Database connection errors or white screen of death (WSoD) occur when accessing backend files.
XML-RPC brute-force attacks or REST API injection loops are spamming server resources.

Restoring Backend Access by Cleaning wp-login.php and Login Redirection Hooks

Solution:

Root Cause: Compromised `wp-login.php` or Login Filter Hook Injections

Malware frequently overwrites core wp-login.php or injects custom redirection functions into functions.php targeting wp_login actions. This intercepts administrator login attempts and redirects them away from the dashboard, locking out site owners while attacker scripts continue executing backend spam.

Diagnostic Verification:

Visiting yourdomain.com/wp-login.php immediately redirects to an external spam or phishing domain.

Step-by-Step Fix:

1Replace wp-login.php with a Clean Core Copy:

Download fresh WordPress core files and upload a pristine wp-login.php via SFTP, overwriting the compromised file.

2Check functions.php for Login Redirect Hooks:

Open active theme functions.php and search for hooks like wp_redirect or filters on login_url pointing to external domains.

3Emergency Admin Access Recovery via phpMyAdmin:

If locked out of wp-admin, create a new administrator account directly in the database using phpMyAdmin (wp_users and wp_usermeta tables).

Prevention & Long-Term Monitoring:

Hide or change default login URLs using security plugins (e.g., WPS Hide Login) to prevent automated login attacks.

Purging Unauthorized Administrator Accounts and Backdoor Users

Solution:

Root Cause: Unauthorized Administrator Account Creation via Compromised Rest API

Once attackers gain execution privileges, they often create hidden administrator user accounts (often named with generic admin handles or masked as system bots) via the WordPress REST API or direct database injection to maintain persistent backend access even after cleaning file backdoors.

Diagnostic Verification:

Navigate to WordPress Dashboard > Users. Audit the administrator user list for any unrecognized accounts with recent login timestamps.

Step-by-Step Fix:

1Audit WordPress Users Table:

Go to Users > All Users and delete any unauthorized administrator accounts.

2Audit Database Users Directly (If Dashboard is Inaccessible):

Open phpMyAdmin > check wp_users and wp_usermeta. Delete rows corresponding to unauthorized user IDs.

3Force Global Password Reset:

Force all legitimate users to reset their passwords and invalidate active authentication cookies (wp_auth_cookie expiration).

Prevention & Long-Term Monitoring:

Limit user registration permissions and monitor user creation notifications.

Fixing Database Connection Errors and White Screen of Death (WSoD)

Solution:

Root Cause: Database Connection Loss or Fatal Memory Exhaustion from Malicious Loops

When malware creates infinite redirection loops or heavy background database spam queries, PHP worker limits are instantly exhausted, throwing the White Screen of Death (WSoD) or database connection errors. Additionally, compromised database passwords in wp-config.php break database connectivity.

Diagnostic Verification:

Check error logs (error_log in your hosting file manager) to locate fatal PHP out-of-memory errors or syntax errors in core files.

Step-by-Step Fix:

1Enable WordPress Debug Logging:

Open wp-config.php and define debug flags:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);

Check wp-content/debug.log to identify the exact file and line number causing fatal errors.

2Increase PHP Memory Limit:

In wp-config.php, add: define('WP_MEMORY_LIMIT', '512M');

3Restore clean core files and database backups if necessary.

Prevention & Long-Term Monitoring:

Maintain automated daily backups of both website files and MySQL databases.

Securing XML-RPC and REST API Endpoints Against Brute-Force Injection

Solution:

Root Cause: XML-RPC and REST API Vulnerability Exploitation

Attackers exploit legacy xmlrpc.php endpoints or unauthenticated REST API routes to execute brute-force attacks, execute remote file inclusions (RFI), or inject malicious payloads into database options and post contents.

Diagnostic Verification:

Check server access logs (access.log) for thousands of POST requests targeting /xmlrpc.php or /wp-json/ endpoints.

Step-by-Step Fix:

1Disable XML-RPC Completely via .htaccess:

Add the following block to your root .htaccess file:

<Files xmlrpc.php>
Order allow,deny
Deny from all
</Files>

2Secure REST API Endpoints:

Install a security plugin (e.g., Wordfence or Solid Security) to restrict REST API access to authenticated users only.

3Implement Rate Limiting:

Configure rate-limiting rules at your CDN or firewall to block IP addresses exceeding failed login thresholds.

Prevention & Long-Term Monitoring:

Keep WordPress core, plugins, and themes updated to their latest security patches.

Related Diagnostic Guides

System Interrupts High CPU Usage 100% Fix Tree

NVMe SSD Not Showing Full Speed In CrystalDiskMark: PCIe Lane Diagnostic

Windows 11 File Explorer Slow To Load Green Bar Fix

Mechanical Keyboard Some Keys Double Typing: Debounce Diagnostic

AirPods Connected to Windows But Sound Is Low Quality: Hands-Free Profile Fix

Subscribe to StepDiag

Embed Guide on Your Website