WordPress Site Hacked Redirect – Find And Remove It

Fix WordPress site hacked redirect issues that target logged-out or mobile
visitors by finding injected code in wp_options, .htaccess, plugins, and theme
files.

Your site looks fine when you are logged in as admin, but customers are
getting sent to casino pages, fake antivirus downloads, or random spam
domains. That exact pattern is why people search WordPress site hacked
redirect. It is not your imagination and it is not a browser glitch. Attackers
intentionally hide redirects from admins so you think cleanup worked while
normal visitors keep getting hijacked. Most owners already removed one
suspicious plugin and changed passwords, then watched the redirect come back
two days later.

When this keeps returning, it means the attacker left persistence in more than
one location. You removed a symptom, not the control point. Redirect malware
in WordPress is usually layered across database options, .htaccess rewrite
rules, compromised plugin or theme files, and sometimes cron-scheduled
reinjection code. If you clean only one location, another component writes the
payload back. That is why “we cleaned it last week” fails so often.

What A WordPress Site Hacked Redirect Usually Looks Like

Modern redirect infections are conditional. They check user agent, referrer,
device type, cookie state, and login status. If visitor is admin or known
crawler, they serve normal content. If visitor is a fresh mobile session from
organic search, they trigger a 302 or JavaScript redirect to a malicious
domain. This selective behavior keeps the infection under the radar and
reduces the chance of immediate host suspension.

Attackers also obfuscate payloads. You may see long base64 blobs, gzinflate
wrappers, eval chains, or seemingly harmless variables concatenated into
executable code. In database storage, payloads often hide in autoloaded
options where every request executes quickly. In file system attacks, they
drop in writable plugin folders, uploads with fake image extensions, or
modified theme include files that are expected to load on every page.

WordPress Site Hacked Redirect Diagnosis – Reproduce Like A Visitor

The first mistake is testing while logged in. Open an incognito browser with
no cookies and no WordPress session. Test from mobile network as well as
desktop. Use curl with a mobile user agent and follow redirects. Capture the
full redirect chain and target domains. This gives you proof and a time window
for logs.

Then inspect server access logs around those requests. Look for unexpected 301
or 302 responses, rewritten destinations, and suspicious query strings.
Compare logged-in vs logged-out requests to same URL. If redirects occur only
for anonymous traffic, focus on conditional code paths in theme templates,
init hooks, and early output buffering routines.

Check wp-content/debug.log and server PHP logs for include warnings or
execution paths touching unfamiliar files. Attack code often triggers warnings
when file permissions or include paths are inconsistent. Even when no fatal
appears, timestamps help correlate suspicious execution with redirect events.

Where Redirect Injections Hide – wp_options And Autoloaded Payloads

Database injections are common because they survive theme swaps and plugin
reinstall attempts. Attackers insert payloads into options like siteurl
clones, custom tracking options, or fake plugin settings, then mark them
autoload so every page request touches the data. If code in functions.php
reads and executes these values, redirect logic runs before templates render.

Inspect wp_options for suspicious long values, obfuscated strings, and
references to external script tags or unknown domains. Pay attention to
recently modified options and unusual option names that mimic legitimate
plugin prefixes. If you find encoded payloads, do not simply truncate rows
blindly. Export affected rows first for forensic trail, then remove malicious
entries and verify no loader code remains that can recreate them.

Also check wp_cron related option data for scheduled tasks pointing to unknown
callbacks. Reinfection often depends on scheduled execution that rewrites
cleaned options overnight.

Where Redirect Injections Hide – .htaccess Rules

.htaccess is a favorite because one malicious rule can reroute large traffic
segments quickly. Attackers add conditional RewriteCond blocks that trigger on
mobile user agents, certain referrers, or non-admin cookies. These rules are
easy to miss if you are only glancing at top and bottom of file.

Create a clean backup of current .htaccess, then review every rewrite block
line by line. Remove unknown redirects and restore a known-good minimal
WordPress rewrite section. If you use caching or security plugins, rebuild
their rules from plugin settings instead of preserving copied fragments from a
compromised file. After cleanup, lock down write access where your hosting
model allows it so random PHP processes cannot edit .htaccess silently.

Where Redirect Injections Hide – Plugin Files And Theme functions.php

Compromised plugin files are common when outdated plugins contain known upload
or file write vulnerabilities. Attackers inject small loader stubs into
existing files so they blend with legitimate code. Theme functions.php is
another prime target because it runs on nearly every request. If your theme
was edited directly in production, this file should be treated as high risk
during incident response.

Run a diff against known-good plugin and theme source. Any unexpected eval,
base64_decode, preg_replace with /e behavior, remote file_get_contents calls
to unknown domains, or obfuscated variable chains should be treated as
malicious until proven otherwise. Replace modified plugin files with clean
vendor copies from trusted sources. For theme code, restore from repository or
clean backup, then reapply known customizations manually.

Do not rely on one malware scanner plugin as sole validation. Many redirect
loaders are short and polymorphic enough to evade signature-only detection.

How To Remove It Completely Without Breaking The Site

Put the site in maintenance mode if possible and take a full backup snapshot
before cleanup. Rotate all credentials immediately: WordPress admin, database
user, hosting panel, SFTP, and API keys. If credentials stay exposed,
attackers can re-enter after cleanup. Update WordPress core, all plugins, and
theme to patched versions before reopening traffic.

Clean in this order: remove malicious .htaccess rules, replace compromised
core/plugin/theme files from clean sources, purge malicious wp_options
entries, remove rogue admin users, remove unknown scheduled tasks, then clear
caches and CDN. After each stage, test anonymous and mobile redirects again.
If redirect persists, continue forensic search for secondary loaders in
uploads and mu-plugins directories.

Finally, scan for recently modified files by timestamp and inspect anything
changed outside expected maintenance windows. Reinjection often leaves a small
backdoor script in uploads disguised as image or cache helper.

Why The Redirect Came Back After The Last Cleanup

It came back because persistence was left in place. Typical examples are a
hidden admin account, a forgotten backdoor file in uploads, or a database
loader option that repopulates malicious .htaccess rules. Another frequent
cause is restoring from a backup that already contained the compromise. Owners
think they rolled back to clean state, but they restored an already infected
snapshot.

The deeper issue is usually vulnerability management. Sites get hacked because
old plugins stay installed, unused extensions remain active, file editing is
enabled in dashboard, and there is no file integrity monitoring. Attackers
rarely need zero-day exploits when known vulnerabilities remain unpatched for
months.

Hardening After Cleanup So It Stays Clean

After incident recovery, harden the stack immediately. Remove unused plugins
and themes, enforce strong unique credentials and MFA where available, disable
built-in file editor, limit login attempts, and keep automatic security
updates enabled for minor core releases. Add monitoring for file changes in
critical directories and alert on new admin account creation.

Set up a repeatable patch cycle. If plugin updates are delayed indefinitely,
the same compromise path will be reused. Also keep offsite backups with
retention points so you can restore to pre-compromise state with confidence.
Test those backups, because untested backups are not a recovery plan.

Regaining Trust After A Redirect Incident

A WordPress site hacked redirect incident is not just a technical bug. It is a
trust event with customers and search engines. We handle these cleanups by
reproducing the redirect exactly as visitors see it, removing every
persistence layer, and validating the site from anonymous mobile sessions
before handoff. We also lock down the stack so the same redirect path does not
reopen next month. That is included in M Media’s flat-rate WordPress emergency
repair service.