How to Recover a Hacked WordPress Site: 9-Step Fix

Quick answer: To recover a hacked WordPress site, put it in maintenance mode, back up the infected files, reset every password and security key, scan for malware, replace core files with fresh copies, reinstall plugins and themes from trusted sources, delete unknown admin users, clean the database, update everything, and then ask Google to review the site. Skip the cause analysis and the hack comes back.

Finding out your site has been hacked is stressful: a red browser warning, visitors redirected to spam, or a stranger sitting in your admin users list. The good news is that most WordPress hacks follow predictable patterns, and with a clear order of operations you can clean them up yourself.

This guide is a field runbook. It goes beyond the usual “install a scanner” advice and gives you the exact checks, WP-CLI commands, database queries and server rules we use when a site lands on our desk. If your site is currently clean and you only want to stay that way, read our WordPress security checklist instead.

How to Tell if Your WordPress Site Is Really Hacked

Confirm the hack before you start deleting things. Some “hacks” are just a broken plugin or a server problem, such as a 500 internal server error or one of the common WordPress errors. These symptoms, however, point to a real compromise:

Symptom	What it usually means
Red “Deceptive site ahead” page or “This site may be hacked” in Google	Google Safe Browsing or a security review flagged malware or spam
Visitors redirected to pharma, casino or adult sites (often only on mobile or from Google)	Injected JavaScript, or rewrite rules added to .htaccess or theme files
Unknown administrator in Users	Backdoor account created for repeat access
Thousands of strange pages indexed (Japanese text, pills, “cheap” products)	SEO spam injection
Host suspended your account or emailed an abuse notice	Site is sending spam or serving malware
CPU spikes, slow admin, unknown cron jobs	Crypto-miner or bot script running
Files or plugins changed that you did not touch	Direct file-level compromise

Tip: Always test in a private window and from a phone on mobile data. A lot of malware hides from logged-in admins and only attacks first-time visitors who arrive from search engines.

You can also check your domain’s reputation for free at Sucuri SiteCheck and Google’s Safe Browsing site status page.

The 9-Step Recovery Plan at a Glance

The order matters. Restoring a backup before you know how the attacker got in just hands them the same door again.

Step 1: Isolate the Site and Take a Forensic Backup

Every minute online means more infected visitors, more spam sent from your server and more damage to your search reputation.

1. Enable maintenance mode at the host level if you can (a temporary 503 page), or use a maintenance plugin if wp-admin still works. Search engines read a 503 as “temporary”, so it protects your rankings.
2. Contact your host. Many hosts run their own malware scans and can show access logs, which are the best evidence of how the attacker got in.
3. Make a full backup of the infected site (files and database) and download it. This is your forensic copy. Do not clean it; you will use it to work out the entry point and to recover any content missing from older backups.
4. Check every other site on the same hosting account. On shared hosting, one infected site can spread to its neighbours. Scan them all.
5. Write down what you notice: when the problem started, recent plugin or theme changes, and any new users or files.

Do not start deleting files at random. You need to see the whole picture first.

Step 2: Reset Every Credential and Security Key

Attackers rarely rely on a single login. If you only change your WordPress password, they can walk back in through FTP or the database.

• WordPress: reset passwords for every user, administrators and editors first. If you are locked out, follow our guide to resetting a WordPress admin password.
• Hosting panel (cPanel, Plesk or your host’s dashboard), SFTP/FTP and SSH users and keys.
• Database user password, then update DB_PASSWORD in wp-config.php.
• API keys and application passwords: payment gateways, mail services, CDN, backup services.
• Security keys and salts. Generate new ones from the official WordPress salt generator and paste them into wp-config.php. This logs out every active session, including the attacker’s. With WP-CLI: wp config shuffle-salts.
• Use a password manager to generate unique 20+ character passwords, and check whether your email appears in known leaks at Have I Been Pwned.

Do this from a clean computer. If your own machine is infected with a keylogger, the new passwords are compromised as well.

Step 3: Scan for Malware and Backdoors

A partial cleanup that misses one backdoor means you will be hacked again within days. Use several methods, because each one catches different things.

3.1 Use scanners

• Wordfence or MalCare: scan files inside WordPress and compare them against known-good copies.
• Sucuri SiteCheck: external scan for injected scripts and blacklist status.
• Your host’s built-in scanner, if it has one.

3.2 Verify checksums with WP-CLI

If you have SSH access, WP-CLI can compare your files against the official copies. This is much more reliable than eyeballing folders.

# Core files vs. wordpress.org checksums
wp core verify-checksums

# Every plugin hosted on wordpress.org
wp plugin verify-checksums --all

# List all administrators
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

See the official docs for wp core verify-checksums.

3.3 Hunt manually with SSH

# PHP files hiding in uploads (there should be none)
find wp-content/uploads -type f -name "*.php"

# Files changed in the last 7 days
find . -type f -name "*.php" -mtime -7 -not -path "./wp-content/cache/*"

# Common malware functions
grep -rlE "eval\(base64_decode|gzinflate\(base64|str_rot13\(|preg_replace\(.*/e" wp-content wp-includes

Remember that legitimate plugins sometimes use base64_decode, so treat matches as leads to inspect, not automatic proof.

3.4 Check the usual hiding spots

• wp-config.php (extra code above the “That’s all, stop editing” line)
• .htaccess in the root and in sub-folders (unknown rewrite or redirect rules)
• functions.php and header.php / footer.php in your active theme
• wp-content/mu-plugins/ (must-use plugins load silently and don’t show in the normal plugin list)
• Plugins with odd names, or plugins you never installed
• Scheduled tasks: wp cron event list shows unknown jobs that re-infect the site

Step 4: Clean Files: Core, Plugins, Themes and Uploads

The safest rule is replace, don’t repair. Hand-editing infected files is how backdoors survive.

4.1 Replace WordPress core

Download a fresh copy from wordpress.org, delete wp-admin and wp-includes, then upload the clean folders. Also replace the loose files in the root (index.php, wp-login.php and so on) but keep your own wp-config.php and wp-content. With WP-CLI:

wp core download --force --skip-content

4.2 Reinstall plugins and themes

• Delete every plugin folder, then reinstall only the ones you need from the official repository or the vendor’s site.
• Never reinstall from “nulled” or pirated copies. They are one of the most common infection sources.
• Delete inactive plugins and themes. Inactive code can still be exploited.
• For a custom or child theme, compare it against your Git history or a clean copy. If you don’t use version control yet, now is the time to start.
• If your theme is compromised, a clean reinstall is faster than diagnosis. See how to install a WordPress theme, or pick a lightweight, well-coded option from our list of the fastest WordPress themes or free WordPress themes.

4.3 Sweep the uploads folder

Remove any .php, .phtml or oddly named file from wp-content/uploads. Images and PDFs belong there; executable code does not.

4.4 Check .htaccess

Replace it with the default WordPress rules, then re-save permalinks. The standard block is:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

On Nginx there is no .htaccess, so review your server block for injected rewrite or location rules. Our Nginx optimization guide shows a clean baseline.

Step 5: Clean the Database and Remove Rogue Users

Malware loves the database because file scanners never look there. Take a database export first, then run these checks in phpMyAdmin, Adminer or WP-CLI. Adjust the wp_ prefix if you use a custom one.

-- Newest users first: look for accounts you don't recognise
SELECT ID, user_login, user_email, user_registered
FROM wp_users ORDER BY user_registered DESC LIMIT 20;

-- Injected scripts or iframes in posts and pages
SELECT ID, post_title, post_status
FROM wp_posts
WHERE post_content LIKE '%<script%' OR post_content LIKE '%<iframe%';

-- Suspicious autoloaded options
SELECT option_name, LEFT(option_value, 120)
FROM wp_options
WHERE autoload = 'yes' AND (option_value LIKE '%<script%' OR option_value LIKE '%base64_decode%');

-- Make sure site URL and home URL are yours
SELECT option_name, option_value FROM wp_options
WHERE option_name IN ('siteurl','home');

Then:

• Delete unknown administrators. Check wp_usermeta for leftover capabilities.
• Remove spam posts, hidden pages and injected comments.
• If siteurl or home were changed, fix them using our guide to changing the URL in the WordPress database.
• Review your WP-Cron entries and delete tasks you did not create.

Running a store? Also review orders, coupons and payment gateway settings. A common attack on shops is swapping the checkout code or the gateway keys. Cross-check your WooCommerce plugins as well.

Step 6: Restore from Backup (Only If You Must)

Cleaning is usually better than restoring because a backup can contain the same infection. Restore when the damage is widespread, you cannot find all the malware, or the database is badly polluted.

1. Pick a backup made before the first sign of compromise. Compare its date with the file timestamps you found in Step 3.
2. Restore to a staging copy first. A local environment like the one in our WordPress localhost guide works too.
3. Scan the restored copy before it goes live.
4. Re-add any real content published between the backup date and the hack by copying it from your forensic backup. Check each piece for injected code.
5. Upload size limits blocking a large restore? See how to increase the maximum upload file size.

Whatever route you take, a restored site is still vulnerable to the original hole. Restore, then go straight to Step 7.

Step 7: Update and Harden Before Going Live

This is the step that decides whether you get hacked again. Find the entry point, close it, then reduce the attack surface.

7.1 Find the entry point

Search your forensic backup and server access logs for the first suspicious request. The usual suspects, in order of frequency:

1. An outdated plugin or theme with a known vulnerability. You can look up your versions in the Patchstack vulnerability database or WPScan.
2. Pirated or nulled themes and plugins.
3. Weak or reused passwords, especially FTP and admin accounts.
4. Another infected site on the same hosting account.
5. Insecure custom code. Developers should review sanitizing, escaping and validating data.

7.2 Update everything

Update WordPress core, all plugins and your theme. See our notes on how to safely upgrade a WordPress theme without losing customizations. Ask your host to move you to a supported PHP version. If your host can’t keep up, it may be time to look at a better one from our list of cloud hosting providers (or fast WooCommerce hosting for stores).

7.3 Lock down the site

• Correct file permissions: folders 755, files 644, wp-config.php 600 or 640.
• Disable the dashboard file editor in wp-config.php:

  define( 'DISALLOW_FILE_EDIT', true );

• Block PHP execution in uploads. On Apache, add this to wp-content/uploads/.htaccess:

  <Files *.php>
  Require all denied
  </Files>

  On Nginx, add to your server block:

  location ~* /wp-content/uploads/.*\.php$ { deny all; }

• Move wp-config.php one level above the web root if your host allows it.
• Enable two-factor authentication for every administrator and limit login attempts.
• Force HTTPS. If you haven’t yet, follow our guide on how to install an SSL certificate.
• Install a firewall (a WAF plugin or your host’s or CDN’s firewall) to block known attack patterns.
• Keep the plugin list lean. Review our list of must-have WordPress plugins and drop anything redundant.
• Back up automatically to storage outside your server, and test a restore once.

For the full list, work through our WordPress security checklist and the official WordPress hardening guide.

Running a multisite? A single infected sub-site can reach the whole network. Scan every site and read our WordPress multisite guide to understand how roles and shared plugins work.

Step 8: Remove the Google Warning and Blacklist Flags

Only do this once the site is verified clean, because a rejected review costs you time.

1. Re-scan with a different tool than the one you cleaned with.
2. Open Google Search Console and go to Security & Manual Actions → Security issues.
3. Click Request review and briefly describe what was found and how you fixed it. Google’s own documentation on hacked sites explains what it looks for.
4. Delete injected spam URLs (return 404 or 410 for them) and submit a fresh sitemap.
5. Check other blacklists (Sucuri SiteCheck lists several) and your email reputation if your domain sent spam.

Reviews are usually answered within a few days, though Google doesn’t promise a timeline. For lost traffic, restore your fundamentals using our beginner’s guide to WordPress on-page SEO.

Step 9: Monitor for 30 Days

Reinfection typically shows up within the first few weeks. Set up monitoring so you hear about it first:

• File-change alerts for core files and wp-config.php
• Login and failed-login alerts, especially for new IP addresses
• An uptime monitor with email or SMS alerts
• A weekly scan with a second tool, plus Search Console security alerts
• A weekly look at Users, Plugins and your host’s access logs

Mistakes That Cause Reinfection

• Cleaning without finding the entry point. The door stays open.
• Changing only the WordPress password and leaving FTP, hosting and database credentials unchanged.
• Restoring an infected backup or restoring without scanning it.
• Leaving “just one” suspicious file because the site works.
• Using nulled themes or plugins to save money.
• Going live too early before updates and hardening are done.
• Forgetting neighbouring sites on the same hosting account.
• Paying a ransom. There is no guarantee you get anything back, and it marks you as a paying target.

DIY or Hire a Professional?

Situation	Recommendation
Small site, one infected plugin, clean backup	DIY with this guide
You keep getting reinfected	Hire a security specialist
Customer data, payment details or personal data exposed	Professional incident response, and check your legal duties (under GDPR, for example, a breach of personal data generally has to be reported to the authority within 72 hours of discovery)
Several sites or the whole server affected	Involve your host and a specialist; server-level cleanup is needed
Revenue-critical store	Professional cleanup usually pays for itself in saved downtime

If you need developer help, see our overview of WordPress development agencies and get a sense of budget from our web development quote guide.

Frequently Asked Questions

How long does it take to recover a hacked WordPress site?

A contained infection with a clean backup can be fixed in a few hours. A deep compromise with multiple backdoors, spam pages and a Google flag can take one to two days, plus days for Google’s review.

Can I recover my hacked site without losing content?

Usually, yes. Back up the infected site first, clean the files and database, and only restore from a backup when needed. Your forensic backup lets you recover posts written after the last clean backup.

Why does my WordPress site keep getting hacked?

The usual causes are a missed backdoor, unchanged FTP or database credentials, outdated or nulled plugins, or another infected site on the same account. The original vulnerability was never closed.

Will my Google rankings recover after a hack?

In most cases, yes, once the site is clean and any security warning is cleared. The sooner you clean up and request a review, the shorter the visibility gap.

Is a security plugin enough to remove malware?

A plugin is a strong first pass but not a guarantee. Sophisticated backdoors can slip through automated scans, so combine plugin scans with checksum verification and a manual review of recently modified files and users.

Should I delete everything and start from scratch?

Not always, but rebuilding from fresh WordPress, fresh plugins and exported content is sometimes faster and safer than hunting for a deep infection. Never copy over executable files from the old site.

Can a hacked site infect other sites on my hosting?

Yes. If sites share an account or file permissions, malware often spreads to every WordPress install it can reach. Scan and reset credentials for the whole account.

Final Thoughts

Recovering a hacked WordPress site comes down to discipline: contain it, reset every credential, find every backdoor, replace instead of patching, close the original hole and monitor afterwards. Do those in order and most infections are fixable without losing your content or your rankings.

Next, make a repeat attack unlikely by working through our WordPress security checklist, and bookmark this guide so you have the runbook ready if you ever need it again.