How to Fix a Hacked WordPress Site: A 9-Step Emergency Recovery Guide

If you’re Googling “fix hacked wordpress site,” you’re probably seeing something scary: weird redirects, new admin users, spam pages showing up in Google, or a browser warning that kills trust fast. And yes, you can fix this. Take a breath—most WordPress hacks are recoverable, but the order of operations matters. The biggest mistake is jumping straight into deleting files or restoring a random backup without first stopping the attacker and preserving what you need to diagnose the entry point.

This guide uses a simple three-phase approach: contain → clean → harden. First, you’ll contain the damage (maintenance mode, access lockdown, and a full snapshot) so the hack doesn’t keep spreading while you work. Next, you’ll clean the infection (remove backdoors, replace compromised files, purge injected database junk, and audit users) until scans and spot checks agree you’re actually clean. Finally, you’ll harden the site (updates, strong authentication, least privilege, backups, and monitoring) so the same vulnerability doesn’t bite you again next week, and you get alerts before customers do.

Before you start, try to collect WordPress admin access, hosting/SFTP credentials, database access, and any recent backups. Most cleanups take 30–120 minutes, depending on scope. If you’re missing access, don’t panic—we’ll note workarounds and the exact point where it’s smarter to escalate to your host or a security pro. If your goal is to fix hacked wordpress site issues fast and safely, start with containment and follow the steps in order.

Signs your WordPress site is hacked

Fast symptom checklist

If something feels “off,” trust that instinct. Most compromises aren’t dramatic—they’re sneaky. Here are the most common red flags:

• Unexpected redirects (especially mobile-only) to gambling, pharma, crypto, or “prize” pages
• New admin user you didn’t create, or your admin email/password suddenly changed
• Spam pages or strange URLs indexed in Google (often with random slugs or foreign language keywords)
• Site warnings in Chrome/Safari (“Deceptive site ahead,” malware warning)
• Hosting alerts about malware, resource abuse, or suspicious scripts
• Sudden SEO drop or traffic crash that doesn’t match seasonality
• Popups/ads appearing when you didn’t install an ad plugin
• Slow site / CPU spikes (could be injected miners, bot traffic, or spam generation)
• Unknown plugin/theme files or modified core files (wp-includes/wp-admin changes)
• Emails being sent from your domain (password resets you didn’t request, spam complaints)

One big clue: the site looks normal to you, but visitors see something different. That often means conditional malware (device, location, referrer-based).

Confirm with Search Console + logs

Next, validate with evidence—not guesses.

• Google Search Console: check Security issues and Manual actions. Also review Pages/Indexing for a spike in “Indexed” URLs you don’t recognize and query Search Results for spam keywords tied to your domain.
• Server access logs: look for repeated hits to wp-login.php, xmlrpc.php, wp-admin/admin-ajax.php, or odd POST bursts to unknown endpoints.
• Error logs: scan for suspicious PHP warnings tied to unfamiliar files in /wp-content/uploads/, /mu-plugins/, or random new directories.
• File changes: if your host provides “modified files” lists, check what changed recently—especially core files and .htaccess.

If two or more signals show up, treat it as a real compromise and move to containment immediately.

Contain the damage before cleanup

Maintenance/safe mode

Before you touch files or run “cleanup” tools, stop the bleeding. Your goal is to prevent visitors (and Googlebot) from getting redirected or served malware while you work. Put the site in maintenance mode or a simple “We’ll be back soon” page. If your host supports it, temporarily enable a WAF / firewall rule set or “under attack” mode to reduce bot traffic. Avoid changing too many things at once—containment should be quick, reversible, and focused on limiting exposure.

If the hack is actively redirecting users, consider temporarily restricting access by IP (allow only your IP) or password-protecting the site at the server level while you clean. This isn’t the final fix—it’s a safety barrier.

Freeze access (passwords/keys)

Assume credentials are compromised. Immediately rotate the essentials:

• WordPress admin passwords (and force reset for all admins if possible)
• Hosting control panel, SFTP/SSH, and database passwords
• Any SMTP / transactional email credentials tied to WordPress
• API keys stored in plugins (forms, payment, analytics, integrations)

Also log out all sessions, remove unknown admin users, and enable 2FA if available. If you reuse passwords anywhere, change those too.

Snapshot/backup for recovery + evidence

Now take a full snapshot before cleanup: site files + database. This protects you if a cleanup step breaks the site, and it preserves evidence to identify the entry point (so you don’t get reinfected). Label it clearly with date/time. If possible, export logs around the suspected compromise window. That snapshot is your “undo button” and your forensic reference—don’t skip it.

How to fix hacked wordpress site fast: the 9-step emergency playbook

Step 1 — Stop the bleeding (maintenance mode + block obvious bad traffic)

Get users out of harm’s way immediately. Turn on maintenance/safe mode, then add a temporary server-level block if redirects are active (password-protect the site or allowlist your IP). If you have a WAF/firewall, enable it now to cut bot noise while you work.

Step 2 — Secure access (hosting, WP admin, DB, SFTP/SSH, email)

Rotate credentials in this order: hosting panel → SFTP/SSH → database user → WordPress admins → email/SMTP/API keys. Log out all sessions and remove unknown access. If you can, enable 2FA for admin accounts before moving on.

Step 3 — Take a clean snapshot (full backup + note timestamps)

Create a full backup of files + database and label it with the exact time. This is your rollback point if cleanup breaks the site. Also note the first time you noticed symptoms and any recent updates/installs (those timestamps matter for root-cause).

Step 4 — Scan + identify infection scope (files vs DB vs users)

Run a reputable scan (security plugin + host scanner if available). You’re not just looking for “malware found”—you’re mapping where it lives: infected files, injected database content, rogue users, or malicious redirects in .htaccess/web server rules.

Step 5 — Remove rogue admin/users + reset roles

Audit all users for new admins, changed emails, or unfamiliar usernames. Delete suspicious accounts, reset passwords for all privileged roles, and confirm role assignments (no “Editor” quietly upgraded to “Administrator”). Check for hidden “application passwords” or API tokens too.

Step 6 — Clean/replace compromised files (core/theme/plugin integrity)

Don’t “hand-edit” core files unless you must—replace WordPress core with fresh copies from WordPress.org. Reinstall themes/plugins from trusted sources. Remove anything nulled, abandoned, or unknown. Pay special attention to /wp-content/uploads/, mu-plugins, and odd new PHP files.

Step 7 — Clean database injections (options table, posts, redirects)

Search for injected scripts/links in wp_options (siteurl/home, autoloaded options), spam posts/pages, and widget content. Remove malicious redirects, base64 blobs, and hidden iframes. If spam URLs were created, plan to noindex/remove them and clean up sitemaps later.

Step 8 — Close entry points (update, remove nulled plugins, perms, keys)

Update WordPress, plugins, and themes. Regenerate salts/keys in wp-config.php. Fix file permissions (no world-writable dirs), disable file editing in wp-admin, and lock down high-risk endpoints if needed (e.g., XML-RPC). The goal: stop reinfection.

Step 9 — Verify clean + monitor (rescan, logs, uptime, WAF)

Rescan after cleanup and confirm symptoms are gone (no redirects, no rogue users, no new files appearing). Review access logs for repeated attack patterns, enable uptime + change monitoring, and keep a WAF/security baseline running. If anything reappears within 24–48 hours, escalate to root-cause (often hosting or a persistent backdoor).

Malware removal (hands-on): files, database, users, and backdoors

File cleanup hotspots (uploads, mu-plugins, wp-config, temp dirs)

Most WordPress malware hides where people don’t look—or where it blends in. Start with /wp-content/uploads/. Uploads should mostly be images and media, not PHP. If you find .php, .phtml, strange .ico files, or folders with random names, treat them as suspicious. Next, check /wp-content/mu-plugins/ (must-use plugins). Many site owners forget this folder exists, which makes it a favorite hiding place for persistent code.

Then inspect wp-config.php and .htaccess (or your Nginx config). Common signs include unfamiliar include() calls, long obfuscated strings, weird rewrite rules, or redirects that only trigger for mobile/referrer traffic. Also look for new files in the WordPress root that shouldn’t be there (random .php files alongside wp-login.php). Finally, scan temp/cache directories created by plugins and hosts—malware sometimes drops payloads there because it gets less scrutiny.

Cleanup best practice: replace, don’t patch. Reinstall WordPress core from a trusted source. Reinstall themes/plugins from official or vendor sources. Delete anything “nulled,” abandoned, or unknown. If a file looks obfuscated and you didn’t put it there, remove it and verify nothing depends on it.

DB cleanup patterns (base64 blobs, injected scripts, rogue options)

A “clean” file system can still leave your site compromised if the database is injected. Focus on three areas:

1. wp_options: Look for rogue values in home, siteurl, active_plugins, and large “autoload” entries. Malware often stores payloads in autoloaded options so it runs on every page load.
2. wp_posts / wp_postmeta: Search for injected <script> tags, hidden iframes, spam outbound links, or weird shortcodes. Spam campaigns sometimes create hundreds of draft/private pages.
3. widgets + menus: Some injections land in widget text, header/footer blocks, or menu items.

Red flags: base64-encoded blobs, eval(), gzinflate(), str_rot13(), or long strings that don’t match normal settings. When in doubt, compare with a known-good backup or staging copy and remove the malicious entries.

Backdoor detection + integrity checks

Backdoors are why sites get reinfected. After initial cleanup, run integrity checks:

• Compare core files against official checksums (or just replace core entirely).
• Use a security scanner that can detect modified core files and suspicious functions.
• Review recently modified files by timestamp (anything changing after cleanup is a huge clue).
• Search the codebase for common backdoor patterns: eval, base64_decode, preg_replace with /e, assert, system, shell_exec, passthru.

If the same files keep reappearing, stop and investigate the entry point (compromised hosting user, stolen credentials, vulnerable plugin, or a hidden mu-plugin backdoor). This is where “cleaning harder” won’t help—you need to eliminate the reinfection source.

Fix Hacked WordPress site checklist: restore + verify you’re clean

Restore from known-good backup (when it’s the best move)

Restoring a backup is often the fastest path—if you can confirm the backup predates the compromise. “Known-good” means: no weird redirects at that time, no spam URLs indexed, no suspicious admin changes, and ideally a clean scan result from that snapshot. If your backup is from last week but the infection has been quietly running for a month, a restore just brings the malware back.

Use restore when:

• You have a recent backup from before symptoms started
• The hack impacted many files and manual cleanup would be messy
• You can immediately patch the vulnerability after restoring (updates, password resets, removing the vulnerable plugin/theme)

After restoring, still do the hardening steps (credentials, updates, keys, WAF). A restore without hardening is how you get rehacked the same day.

Clean reinstall approach (core/themes/plugins from trusted sources)

If you don’t have a safe backup—or you don’t trust what’s been modified—do a clean reinstall approach:

1. Replace WordPress core with fresh files from WordPress.org (don’t overwrite wp-config.php until you’ve audited it).
2. Reinstall your theme from the official source or vendor download (no “bundled” zip from random sites).
3. Reinstall plugins from the WordPress repository or vendor accounts only. Remove anything nulled, abandoned, or unused.
4. Keep uploads/ media, but purge any PHP or suspicious files inside it.
5. Reset salts/keys in wp-config.php and ensure file permissions are sane.

This approach reduces the chance you miss hidden backdoors because you’re rebuilding from known-clean components instead of trying to surgically edit every infected file.

Verification checklist (redirect tests, user audit, file diff, rescan)

Before you take the site out of maintenance mode, verify you’re truly clean:

• Redirect tests: Check homepage + top pages on desktop and mobile, incognito, and from a different network. Confirm no conditional redirects.
• User audit: Confirm only expected admins exist; verify emails; reset passwords; log out all sessions.
• File diff / modified files: Review recently modified files after cleanup—nothing should keep changing without you touching it.
• Rescan: Run your security scan again and confirm no critical alerts remain.
• Search Console spot check: Look for new spam pages, manual actions, or security warnings.
• Uptime + change monitoring: Turn on monitoring so you know fast if something returns.

If any step fails (redirects return, files reappear, new admins show up), pause and move to root-cause analysis—reinfection is still happening.

SEO + blacklist recovery (Google, browsers, hosts)

Remove spam URLs + fix redirect chains

After a hack, “being clean” isn’t the same as “being trusted again.” First, identify any spam URLs the attacker created (often hundreds). In Google, search site:yourdomain.com plus spam keywords you noticed. In WordPress, check Pages/Posts for junk content, and scan your database for injected URLs. Delete spam pages and make sure they return 410 (Gone) or 404 (preferred over redirecting everything to the homepage). If you use an SEO plugin, regenerate sitemaps after cleanup so those spam URLs aren’t still being advertised.

Next, fix redirect chains and malicious rules. Review .htaccess (or Nginx rules) for strange rewrites, especially those that redirect only for mobile, only for certain referrers, or only when Googlebot visits. Also check for injected JavaScript that does client-side redirects. Your goal is: no unexpected 301/302s, no cloaking, no “shadow” redirects.

Search Console security issues steps

In Google Search Console, check Security issues and Manual actions. If Security issues are present, Google will usually outline the problem category (malware, deceptive pages, hacked content). After you’ve cleaned the site and removed the hacked content, use the request review flow (where available) and be specific in your notes: what you cleaned, what you replaced, and what you changed to prevent reinfection (updates, password resets, removed vulnerable plugins, WAF).

If browsers are still warning users (Chrome/Safe Browsing style warnings), confirm you removed the exact infected payload that triggered it, then follow the relevant review process through Search Console or your host/security provider.

Reindex + monitor crawl errors

Once you’re clean and spam URLs are gone, submit your updated sitemap in Search Console and use URL Inspection on key pages to request reindexing. Then monitor:

• Coverage/Indexing reports for lingering spam URLs
• Crawl errors (sudden spikes can signal leftover bad links or blocked resources)
• Search results queries for spam keywords tied to your domain
• Performance trends (expect recovery to take days to weeks depending on severity)

Keep an eye on this for at least 2–4 weeks—SEO recovery is often the slowest part of the fix, but steady improvement is the goal.

Hardening + monitoring so it never happens again

2FA + least privilege

Most rehacks happen because the original entry point is still open—usually weak credentials, too many admins, or a plugin with more access than it needs. Start by enabling 2FA for every administrator account (and any account that can install plugins). Then shrink the “blast radius”:

• Keep admin accounts to the minimum possible (1–2 real admins).
• Give everyone else the lowest role that still lets them do their job (Editor ≠ Admin).
• Use unique, long passwords via a password manager and disable password reuse across hosting/WP/email.
• Remove unused accounts, old contractors, and “just in case” logins.
• If you allow plugin installs for clients or staff, stop. Make installs a controlled process.

Also lock down WordPress settings that attackers love abusing: disable file editing in wp-admin (DISALLOW_FILE_EDIT), consider limiting wp-admin access by IP (if your workflow allows), and ensure your database user has only the privileges it needs.

WAF/security plugin baselines

A security plugin alone won’t save a site, but a good baseline dramatically reduces noise and catches common attacks. Pick one reputable security plugin and configure the essentials:

• Enable login protection (rate limiting, brute-force blocks, CAPTCHA if appropriate)
• Turn on file change detection and core integrity monitoring
• Block PHP execution in uploads (where possible)
• Enable malware scans on a schedule and immediate alerts for critical findings

Pair that with a WAF (Web Application Firewall) if you can—either at the DNS/CDN layer or through your host. A WAF helps filter bot traffic, exploit attempts, and known malicious patterns before they hit WordPress. If you run an ecommerce or lead-gen site, the WAF is usually worth it for risk reduction alone.

Don’t forget the basics at the server level: correct file permissions (no world-writable directories), keep PHP updated, and remove unused software/accounts on the hosting environment.

Backups + alerting + update discipline

Your best defense is being able to recover fast—and knowing early when something’s wrong. Set up:

• Automated backups (daily database + daily/weekly full backups, retained 30–90 days)
• Off-site storage (not only on the same server)
• A tested restore process (practice once—seriously)

Then add alerting that catches problems before customers do:

• Uptime monitoring (pings your site and alerts on downtime)
• Security alerts (new admin created, files changed, malware detected)
• Performance monitoring (sudden CPU spikes can signal abuse)

Finally, adopt update discipline: keep WordPress core, plugins, themes, and PHP current. Remove plugins you don’t need. Avoid “free premium”/nulled downloads entirely. If you treat updates and monitoring as routine maintenance—not a panic response—you massively reduce the odds you’ll be back here fixing the same mess again.

If it keeps coming back: root-cause analysis

Persistent backdoors

If the malware returns after you “cleaned everything,” assume a backdoor is still present or your credentials are still compromised. The most common culprits are hidden PHP files in uploads/, malicious code in mu-plugins, or injected payloads stored in the database (often in autoloaded options). Watch for this pattern: you clean it, it’s fine for a few hours, then the same redirects or spam reappear—and “modified files” timestamps update without you touching anything. That’s not bad luck; that’s persistence.

At this point, stop doing random edits. Re-check for obfuscated code patterns (eval, base64_decode, gzinflate, suspicious preg_replace) and track what files change after cleanup. The file that keeps reappearing is usually being regenerated by another hidden script.

Hosting compromise signals

Sometimes WordPress isn’t the main problem—your server user or hosting environment is. Red flags include: multiple sites on the same account getting infected, unknown cron jobs, unauthorized SSH/SFTP logins, new system users, or malware returning immediately after a clean reinstall. If you’re on shared hosting, cross-account contamination can happen. Ask your host for: recent login history, malware scan reports, suspicious processes, and whether they can isolate/quarantine the account.

When to rebuild vs repair

Repair makes sense when the scope is limited and you can identify the entry point. Rebuild is smarter when: you can’t trust the codebase, reinfection persists, the host can’t provide clean isolation, or the site has been hacked multiple times. A clean rebuild typically means fresh WordPress + theme/plugins from trusted sources, migrating only verified content/media, rotating all credentials, and moving to a more secure hosting setup if needed. If time and trust are on the line, rebuilding is often the fastest “true fix.”

You can recover from a hacked WordPress site without guessing—just follow the same three-phase model every time: contain → clean → harden. Containment stops the damage and protects visitors. Cleaning removes malware, rogue users, and injected database junk. Hardening closes the door so the same exploit doesn’t bring the problem back tomorrow.

Your next step is simple: work through the verification checklist, then keep monitoring turned on for at least a few weeks. If you want hands-on help, link readers to your internal support page (add your internal “WordPress help & troubleshooting” link here) so they can get expert eyes on the site fast.

If you’re stuck, seeing reinfection, or dealing with hosting-level issues, escalate: contact your host for isolation/logs or bring in a WordPress security specialist to finish the cleanup safely.