WordPress Hacked Redirect Fix Checklist: Detect, Clean, and Prevent Reinfection

Last reviewed: April 12, 2026

If your WordPress site is redirecting visitors to casino pages, fake CAPTCHA prompts, sketchy downloads, or unrelated landing pages, treat it as a compromise until proven otherwise. Redirect hacks are rarely just a cosmetic frontend problem. They are usually a symptom of deeper persistence in the stack: malicious rewrite rules, injected PHP or JavaScript, hidden admin access, rogue plugins, compromised credentials, or database payloads that only trigger under specific conditions.

The mistake teams make under pressure is removing the visible redirect and calling the incident closed. That is how reinfections happen. A WordPress hacked redirect fix needs a repeatable workflow: confirm the behavior, preserve evidence, clean the right locations, remove persistence, rotate access, and verify the result from both user and crawler perspectives. This guide focuses on that workflow.

Who this guide is for

This article is for WordPress administrators, agencies, hosting teams, and security operators dealing with a compromised WordPress site that redirects users or search traffic to malicious destinations. It is especially relevant when the redirect is inconsistent, only appears for certain user agents or referrers, or persists after you disable a plugin or clear cache.

Key takeaways

• A redirect infection is often conditional. Check browser, crawler, referrer, mobile, and non-www behavior before assuming the site is clean.
• High-yield inspection points include .htaccess, wp-cron.php, index.php, theme header and footer files, mu-plugins, and unexpected PHP inside wp-content/uploads.
• If you restore from backup without removing the intrusion path and rotating credentials, you have not finished the incident.

WordPress hacked redirect fix checklist

1. Confirm exactly when the redirect happens. Start by verifying whether the redirect affects all visitors or only specific conditions. Test the homepage, a normal post URL, login, and one non-www URL. Compare a regular browser request with a crawler-like request, and note whether the response is a direct 3xx redirect, injected JavaScript, or an iframe or script that rewrites the page after load. Google has documented cases where hacked rewrite rules only redirect traffic coming from search engines, which makes the infection easy to miss during casual testing.
2. Preserve a clean incident snapshot before making destructive changes. Take a filesystem backup, a database dump, and copies of web server access logs and error logs before you start deleting files. If the site is mission-critical, put it behind a maintenance page or temporary upstream block rather than performing ad hoc edits on a live compromised application. A restorable snapshot gives you rollback safety and also preserves evidence if you later need to understand the intrusion path.
3. Check the highest-yield redirect locations first. Review .htaccess for malicious rewrite conditions based on referrer, user agent, cookie, or mobile device checks. Review index.php, wp-cron.php, functions.php, header.php, footer.php, and any custom bootstrap files in the document root. WordPress documentation specifically calls out these files as common targets because code placed there can affect every request. Also inspect wp-content/mu-plugins, drop-in files, and any PHP files hiding in wp-content/uploads, which should normally contain media rather than executable application logic.
4. Inspect the database and administrative surface for persistence. Redirect malware is not always file-only. Review the options table for suspicious autoloaded values, unfamiliar domains, and injected script tags. Check widgets, post content, reusable blocks, and theme options if the redirect is rendered client-side. Then audit administrator accounts, recently modified users, application passwords, scheduled tasks, and plugin inventory. If an attacker still has a valid login or a hidden plugin can re-seed the infection, your cleanup will not hold.
5. Replace compromised code with clean copies, not partial edits. If WordPress core files fail checksum verification, replace core from a trusted source. Reinstall themes and plugins from known-good packages, and remove anything unused, abandoned, pirated, or unexplained. If you maintain your site in version control, compare the current state to the repository. If you do not, compare against a clean backup or fresh vendor copies. The goal is not to cosmetically repair one line; it is to restore a known-good code state.
6. Rotate every credential that could have enabled or preserved the intrusion. Change WordPress admin passwords, hosting control panel passwords, SSH or SFTP credentials, database passwords, and any API or application credentials tied to the site. WordPress’s own hacked-site guidance explicitly warns that a compromise may originate from the local workstation or a reused access path, not only from the application itself. Remove stale users, revoke old application passwords, and review whether your hosting account credentials were exposed.
7. Verify cleanup from both user and search-engine perspectives. After cleanup, test the same URLs and request types you used during triage. Confirm that normal visitors and crawler-like requests receive the same legitimate content. Review Search Console security issues and index samples if Google flagged the site. If the infection created spam or hacked URLs, verify those paths too. Cleanup is not complete just because the homepage stops redirecting.
8. Close the loop so the redirect does not return next week. Patch the root cause, not just the symptom. Update WordPress core, active plugins, and themes. Remove software you are not using. Enable MFA for administrator accounts. Tighten file permissions and hosting access. If the infection path is uncertain, assume the environment was broadly exposed and respond accordingly. Then schedule a restore test and document the incident while the details are still fresh.

Useful commands and validation steps

curl -I -A 'Mozilla/5.0' https://example.com/
curl -I -A 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' https://example.com/

wp core verify-checksums
find wp-content/uploads -type f -name '*.php'
find . -type f \( -name '.htaccess' -o -name 'wp-cron.php' -o -name 'index.php' -o -name 'functions.php' -o -name 'header.php' -o -name 'footer.php' \)
grep -RInE 'base64_decode|gzinflate|str_rot13|eval\(|document\.location|window\.location|fromCharCode|preg_replace.*/e' wp-content .

PREFIX=$(wp db prefix)
wp db query "SELECT option_name, LEFT(option_value,200) FROM ${PREFIX}options WHERE option_value REGEXP 'https?://|<script|base64_decode|eval\\(' LIMIT 30;"
wp user list --role=administrator

Do not treat any single command as proof by itself. A legitimate plugin can contain minified JavaScript or obfuscation-like patterns, and a malicious redirect can live in the database or server config even if checksums pass. The point of this block is to narrow the search quickly and force consistency in the cleanup process.

What often causes reinfection

• Only removing the visible redirect code. Attackers often place persistence in a second location such as wp-cron.php, a must-use plugin, a hidden admin account, or a compromised hosting credential.
• Restoring a backup without patching the original access path. If the site was compromised through a vulnerable plugin, weak credential, or exposed hosting account, the restored site can be reinfected immediately.
• Trusting one clean scanner result too early. WordPress support guidance and professional cleanup workflows both emphasize layered validation. One plugin scan is not enough to close the incident.
• Ignoring non-www, mobile, or search-engine-only behavior. Google has documented hacked sites where the malicious behavior was visible only on alternate hostnames or only to search-driven traffic.
• Leaving unused software and stale access in place. Cleanup should shrink the attack surface. If you keep the same forgotten plugins and dormant administrator accounts, you are preserving risk.

When restore is the better answer than manual cleanup

If you have a verified clean backup from before the compromise and a controlled way to reintroduce content changes, restore is often the faster and safer path. That is especially true when the infection scope is unclear, multiple files have been modified, or the site contains suspicious admin access and unknown plugin state. Restoring a known-good state is not a shortcut. It is often the most defensible response, provided you also patch the root cause and rotate credentials before reopening traffic.

If you are not confident that your backups are clean or your restore process is tested, fix that immediately after the incident. A redirect compromise is exactly the kind of event that exposes whether your backup policy is real or theoretical.

What to document before closing the incident

• which URL patterns redirected and under what conditions
• which files, database entries, users, or plugins were modified or removed
• what the likely intrusion vector was, even if it is only a best-supported hypothesis
• which credentials were rotated and which integrations were reauthorized
• what validation steps confirmed the site was clean
• what hardening or patch work was scheduled immediately after recovery

That record matters because redirect infections are rarely one-off events. They are operational failures with a recurrence path. Your job is not just to make the redirect disappear. Your job is to make the same incident harder to repeat.

Related reading

If the redirect followed a recently disclosed plugin flaw, pair this guide with WordPress Plugin Vulnerability Response Checklist: Patch, Verify, Contain. If you decide a clean restore is safer than hand-cleaning, use WordPress Backup and Restore Test Checklist: Verify Recovery Before an Incident. If your cleanup includes revoking machine credentials and tightening integration access, review WordPress Application Password Security Checklist: Create, Scope, Rotate.

References and further reading

• Google Search Central: Case Studies: Fixing Hacked Sites
• WordPress.org: FAQ My site was hacked
• Developer.WordPress.org: Hardening WordPress
• Wordfence: How to Clean a Hacked WordPress Site using Wordfence
• Wordfence: 2024 Annual WordPress Security Report
• Wordfence: Interesting WordPress Malware Disguised as Legitimate Anti-Malware Plugin