WordPress Malicious Redirect Removal &
Injected Script Cleanup

conditional evasion
before detection

Your WordPress website is redirecting visitors to external scam destinations, adult portals, or deceptive software downloads. Yet when you test the site yourself as an administrator, it often loads normally.

This behavior is not an accident. Modern WordPress redirect intrusions are engineered with conditional execution logic designed specifically to deceive site owners. By inspecting incoming HTTP headers—such as user-agent signatures, referrer origins, and session cookies—the malicious script triggers only for mobile visitors, search engine traffic, or first-time users while staying completely invisible to logged-in administrators. We systematically isolate the execution point, de-obfuscate injected handlers, rebuild server rewrite rules, and sanitize database hooks to restore legitimate traffic flow.

Read Forensic Guide: WordPress Malicious Redirects Cleanup → ← Back to Recovery Hub

Mobile Hijack Isolation .htaccess Rewrite Cleaning Obfuscated JS De-obfuscation Database String Sanitization Header Verification Testing

Mobile-Only Traffic Hijacking

Visitors on iOS Safari or Android Chrome are redirected to spam, gambling, or phishing domains, while desktop visits continue to load the regular website. Attackers check the HTTP_USER_AGENT string to isolate mobile devices.

Search Engine Referrer Redirection

Typing your domain directly into the browser displays your site correctly, but clicking your organic link in Google or Bing search results immediately routes the visitor to an unauthorized external URL. For detailed analysis on how server-side cloaking and search-referer discrimination operate, read our Japanese keyword hack and cloaking guide.

Admin Session Evasion

The malicious code checks for standard WordPress cookies such as wordpress_logged_in_*. If present, the redirect code remains dormant, preventing site administrators from noticing the compromise during routine dashboard tasks.

Single-Session Tracking via Cookies or LocalStorage

The script sets a temporary client-side cookie or localStorage flag upon the first redirect. Subsequent page loads appear normal to the visitor, making reproduction and manual verification challenging without private browsing windows.

Google Safe Browsing & Warning Screens

Google flags the domain in Search Console under "Security Issues" for social engineering or deceptive pages, displaying full-screen red warning interstitials to prospective visitors.

Severe Mobile Analytics Discrepancies

Google Analytics or Search Console metrics show abrupt, catastrophic drops in mobile session duration and conversion rates, while search click counts remain high as visitors bounce before page load.

A malicious redirect is rarely a single static line of code. Intrusions can occur at any layer of the web request lifecycle, from server rewrite rules down to client-side DOM execution.

1. Server Rewrite Rules (.htaccess / Nginx)

Attackers append conditional RewriteCond blocks to the .htaccess file. These rules intercept HTTP requests before PHP even boots, evaluating referrers and user-agents at the web server level and sending 301 or 302 HTTP redirect headers.

2. Obfuscated Theme JavaScript

Encoded scripts (using eval, String.fromCharCode, or hex encoding) are injected into active theme templates like header.php, footer.php, or bundled JS libraries. When parsed by the browser, they dynamically manipulate window.location.href.

3. PHP Core & Plugin Hooks

Compromised files like wp-config.php, wp-load.php, or rogue files inside wp-content/mu-plugins/ execute PHP-based redirects via header("Location: ...") or hook into template_redirect and init actions. For techniques used to identify persistent droppers, read our analysis of WordPress backdoors and stealth web shells.

4. Database Injections (wp_posts & wp_options)

Malicious script tags and external CDN loader URLs are injected into the post_content column of the wp_posts table or stored inside serialized transients in wp_options, triggering redirects on specific article views.

STAGE 01

Multi-Agent Traffic Emulation

We simulate HTTP requests via terminal tooling across diverse user-agent and referrer combinations (iPhone Safari, Android Chrome, Googlebot, direct desktop) to reproduce the conditional redirect and identify the response headers.

Diagnostics

STAGE 02

Filesystem Checksum & Diff Analysis

Compare core WordPress binaries and official plugin releases against WordPress.org cryptographic checksums. Scan .htaccess, index.php, and theme templates for appended rewrite rules or obfuscated script tags.

Forensic

STAGE 03

Payload De-obfuscation & Removal

De-obfuscate base64, eval, and hex-encoded JavaScript handlers. Remove malicious PHP redirect loaders from core files, must-use plugins, and active theme functions, restoring pristine source files.

Remediation

STAGE 04

Database Record Sanitization

Execute targeted SQL queries to identify and purge injected redirect scripts, rogue iframes, and malicious external URLs from wp_posts, wp_postmeta, and wp_options transients.

Database

STAGE 05

Configuration Lockdown & Verification

Rebuild clean .htaccess rules, apply strict file permissions, rotate authentication salts in wp-config.php, and verify that HTTP response headers across all simulated profiles return clean 200 OK statuses.

Validation

End-to-End Injected Script Eradication

Complete removal of malicious JavaScript, eval handlers, and external script links from theme files, plugin binaries, and core WordPress directories.

Rewrite Rule & Server Config Reconstruction

Purging appended malicious redirect directives and rebuilding standard, secure .htaccess or Nginx rewrite configurations.

Database Script & Iframe Purging

Deep SQL-level cleaning of injected redirect URLs, rogue iframe tags, and compromised autoloaded transients across the MySQL database.

Multi-Profile Emulation Verification

Automated testing of key landing pages across mobile user-agents, search engine referrers, and clean browser headers to confirm zero lingering redirects.

Search Review Submission Assistance

Preparation of technical remediation notes and assistance submitting a formal security review request in Google Search Console where deceptive site warnings exist.

To diagnose and eradicate redirect code across all server and application layers, we require access to the following components:

SFTP or SSH Access

Direct filesystem access to inspect .htaccess, compare core checksums, de-obfuscate theme JS, and replace compromised binaries.

MySQL Database Access

Access via phpMyAdmin or database credentials to inspect and clean injected script tags and autoloaded transients.

WordPress Administrator Access

An admin account to review active plugins, installed themes, user privilege layers, and core configuration settings.

Observed Symptoms & URLs

Sample redirect destination domains, affected landing pages, and whether the issue was observed on mobile, desktop, or search clicks.

Our malicious redirect remediation focuses strictly on application-level and web server-level code within your WordPress environment. Understanding these boundaries ensures transparent recovery expectations:

DNS & Registrar Interception

If an attacker gained access to your domain registrar (such as GoDaddy, Namecheap, or edge security layers) and altered your authoritative DNS A/CNAME records, the redirect occurs before traffic ever reaches your server. We inspect DNS settings during diagnosis, but registrar credentials remain under your direct control.

Third-Party Advertising Networks

If your site runs programmatic advertising banners from third-party ad networks, malicious redirects can occasionally be served directly through compromised ad creatives rather than your site's codebase. We isolate whether the redirect originates from your filesystem or an embedded third-party script tag.

// 01 Why do malicious redirects only happen on mobile devices or from Google search?

Attackers deliberately program redirect scripts with conditional logic. They inspect the HTTP_USER_AGENT header to target mobile visitors and the HTTP_REFERER header to target visitors arriving from Google, Bing, or social networks. They also check for WordPress administrator session cookies and suppress the redirect for logged-in users, keeping the compromise hidden from site owners during normal browsing.

// 02 Where is malicious redirect code usually stored in a WordPress site?

Redirect code can hide in multiple locations: within .htaccess or Nginx rewrite directives, injected as obfuscated JavaScript in active theme header.php or footer.php files, embedded inside legitimate plugin binaries, loaded via must-use plugins (mu-plugins), or stored directly in the MySQL database within the wp_posts content or wp_options autoloaded transients.

// 03 Can clearing my browser or site cache fix a malicious redirect?

Clearing the cache will not remove the underlying infection. While server-side or CDN caching can cause redirects to linger temporarily, the redirect logic itself is generated by malicious files, server rewrite rules, or database entries that will continue to trigger until forensically removed from the environment.

// 04 Could the redirect be caused by my domain registrar or DNS rather than WordPress?

Yes, in some cases. If your domain registrar account was compromised or if your DNS records (such as A records or CNAME aliases) were altered, visitors may be directed to a malicious server before ever reaching your WordPress installation. During our initial diagnosis, we inspect your DNS resolution alongside the WordPress filesystem to identify the exact point of interception.

// 05 How do you verify that all malicious redirects have been completely removed?

We execute automated HTTP requests using command-line tools across dozens of simulated profiles, including mobile user-agents (iOS Safari, Android Chrome), search engine referrers (Google, Bing), and clean session headers. We verify that all key entry pages return standard 200 OK responses with clean HTML and zero secondary 301, 302, or JavaScript location redirects.

// 06 How does redirect cleanup affect Google Search Console warnings?

Once all injected redirect scripts and rogue rewrite rules are eliminated, we compile a verification log of remediated files and assist with submitting a security review request in Google Search Console. Google automated crawlers re-test the site, and upon confirming that the deceptive behavior is resolved, Google removes the warning screen.

ISOLATE & RECOVER

Is Your WordPress Site
Redirecting Visitors?

ENGINEERED RECOVERY

Send us your site URL, where the redirects occur (mobile, search, or all traffic), and your hosting setup. We will assess the injection vector and plan containment.