To fix a hacked WordPress site, work in four stages and don’t skip ahead. First, contain it: take the site offline, change every password, and back up the infected state. Second, identify what changed with checksum checks, file dates, user lists, options and cron. Third, clean it by replacing core, plugins and themes from clean sources, or by restoring a clean backup. Fourth, harden the site and ask Google to remove its warnings.
Most failed cleanups I see skipped one stage. Somebody deleted the obvious bad file, felt relieved, and the hack was back within a week because the backdoor and the original hole were still there.
This is my general recovery procedure. If your main symptom is spam pages in Google, I cover that in WordPress SEO spam. If visitors get bounced to scam sites, read WordPress hacked redirect. Both plug into the steps below.
What Should You Do in the First Hour?
Stop the bleeding before you investigate. Google’s own hacked-site recovery guide on web.dev puts quarantine before any cleanup, and I follow the same order.
Take the site offline. Google’s quarantine article suggests stopping the web server or pointing DNS to a static page on another server that returns a 503. It also warns that a robots.txt disallow isn’t enough, because it only blocks crawlers and real people can still reach the harmful content. The same article says taking the site offline temporarily during recovery likely won’t hurt your future rankings. That matches my experience. A few days of 503 costs far less than a Chrome warning.
Know the limit of WordPress maintenance mode. Running wp maintenance-mode activate shows a maintenance message, but it only works inside WordPress. A standalone PHP backdoor in wp-content/uploads can still run because it never loads WordPress. So I treat maintenance mode as a fallback when I can’t take the server down, not as real containment.
Change every password. That means hosting control panel, SFTP or FTP, SSH, the database user, every WordPress administrator, and the email account tied to the domain. Google’s quarantine page lists FTP, database, system administrator and CMS accounts. I add the email, because whoever controls it can reset everything else.
Call your host. Ask whether other sites on the same account are infected and whether they saw the attack in their logs. A shared hosting account with one dirty site will reinfect the clean ones.
Back up the infected state. Download all files plus a database export and keep them off the server. It sounds odd to save malware. But you’ll need it to work out what happened, and it’s your fallback if the cleanup breaks something.
Which Kind of Hack Are You Dealing With?
The symptom tells you where to look first. Here’s the condition map I start every job with.
| What you see | Most likely cause | Where I’d go next |
|---|---|---|
| Japanese, pharma or casino pages in Google | SEO spam generator or injected content | WordPress SEO spam |
| Visitors sent to a scam or ad site | Redirect in .htaccess, PHP or injected JavaScript | WordPress hacked redirect |
| “Deceptive site ahead” or malware warning in Chrome | Phishing kit or malware download hosted on your domain | This post, then the Google section below |
| Host suspended the account for malware or spam email | Mailer script or backdoor files | This post, starting with file checks |
| Unknown admin user, nothing else visible | Stolen login or privilege escalation through a plugin | This post, starting with users and options |
Whatever the symptom, the core procedure stays the same. What changes is where you start digging and how much database cleanup you’ll do.
How Do You Find What the Attacker Changed?
I run read-only checks before I delete anything. Each one answers a different question, and together they give you a list of suspects. These are WP-CLI and shell commands that only list or compare files, so run them from the site root over SSH.
# Core files vs WordPress.org checksums, plus unknown files in the root folder
wp core verify-checksums --include-root
# WordPress.org plugins vs their published checksums
wp plugin verify-checksums --all
# PHP files changed in the last 14 days, and any PHP inside uploads
find . -type f -name "*.php" -mtime -14 -print
find wp-content/uploads -type f -name "*.php" -print
# Administrators, must-use plugins and drop-ins
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp plugin list --status=must-use
wp plugin list --status=dropin
# Options attackers like to change
wp option get siteurl
wp option get home
wp option get users_can_register
wp option get default_role
# Scheduled tasks inside WordPress and on the server
wp cron event list
crontab -l
Here’s how I read the output.
Checksum failures on core files mean someone edited WordPress itself. Don’t patch those files. You’ll replace them. The --include-root flag also warns about non-WordPress files sitting in the root folder, which is where I often find a randomly named PHP file.
Plugin checksum failures only work for plugins hosted on WordPress.org. Premium plugins can’t be verified this way, so I simply reinstall them from the vendor download.
File dates help but can lie. Attackers can reset a file’s modified time. I use -mtime to build a shortlist, not to clear anything.
Users and options are where I catch the quiet hacks. If users_can_register is on and default_role is administrator, anyone can sign up as an admin. That’s a classic. Any admin account you can’t name gets deleted, after you note its creation date for your timeline.
Cron is the part people forget. A malicious WordPress cron event or a server crontab line can re-download the malware every hour. If the hack keeps coming back after a “clean,” this is the first place I look.
Should You Restore a Backup or Clean by Hand?
This is the big branch in any recovery, and the answer depends on one question. Do you have a backup that you know predates the hack?
Branch 1: You Have a Clean Backup
If you can date the infection (from the first spam query in Search Console, the first odd admin account, or the oldest suspicious file) and you have a backup from before that date, restore it. Google’s clean-up guide says the same: restore the backup, then install every available update and patch.
Restoring isn’t the end, though. The backup still contains the vulnerability that let the attacker in. So after restoring, I update everything, change the passwords again, and work through the “find the way in” section below before I bring the site back online.
The trade-off is lost content. Anything published after the backup date has to be re-added by hand. On a blog with a few new posts, that’s an easy call. On a busy shop with new orders in the database, I’d talk to the developer before restoring the database.
Branch 2: No Clean Backup, or You Can’t Date the Hack
If every backup might be infected, or you don’t have one, clean by hand. Google’s guide recommends cleaning a copy of the files, not the live server, and doing a clean installation of your software instead of just an upgrade. Here’s my order:
- Replace WordPress core. Delete
wp-adminandwp-includesand upload fresh copies of the same version from WordPress.org. Then comparewp-config.phpand the root files by hand. - Reinstall every plugin and theme from the source. Download fresh copies from WordPress.org or the vendor. Delete anything unused, including inactive plugins and old themes.
- Empty PHP out of uploads. The uploads folder should hold media, not PHP. Delete any PHP file the
findcommand listed there. - Clean the database. Remove rogue admin users, reset changed options, and search posts and options for injected scripts. The redirect and spam posts linked above have the exact queries.
- Check
.htaccessin every folder, not just the root.
How Do You Remove Backdoors Without Missing One?
A backdoor is any file or setting that lets the attacker back in after you clean. In my experience, there’s almost never just one. Attackers plant several in different places so that you find the obvious one and stop looking.
The places I check every time are mu-plugins (they load automatically and don’t show on the normal Plugins screen), drop-ins like object-cache.php, PHP files in uploads, fake plugin folders with generic names, extra code at the top of wp-config.php, and unknown SSH keys in the account’s .ssh folder. I also look for unknown users with FTP or database access in the hosting panel.
This lists files with common obfuscation patterns. Expect some false positives from legitimate plugins:
grep -rlE "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" wp-content/
I’m not looking for any one function. I’m looking for a file that doesn’t belong: a random name, one enormous line of code, or a date that lines up with the infection.
How Did the Attacker Get In?
Cleaning without finding the entry point just resets the clock. Google’s hacked-site guide has a whole step on identifying the vulnerability, and it’s the step most DIY cleanups skip.
Check the server access logs around your infection date. A burst of POST requests to one plugin file, or a login from an unfamiliar country right before the first bad file appeared, usually tells the story.
Check the plugin and theme list against known vulnerabilities. An outdated plugin with a public exploit is the most common cause I see. Nulled (pirated) premium themes and plugins come next, and they often ship with a backdoor already inside.
Check the people. A reused password, an old developer account that was never removed, or a shared hosting login all count as an entry point.
If you can’t find it, assume it’s still open. Keep monitoring closely for a few weeks and treat any new unknown file as a reinfection, not bad luck.
Hardening So It Doesn’t Happen Again
Once the site is clean, I make it harder to hit twice. I’ll cover full WordPress security in its own guide, so here are only the steps I never skip after a hack.
- Rotate the salts.
wp config shuffle-saltschanges the secret keys inwp-config.php, which logs everyone out and kills any session the attacker still holds. - Change passwords again. Google’s clean-up guide says to change them one more time once the site is clean.
- Turn on two-factor authentication for every admin. The WordPress hardening guide recommends two-step authentication on top of a strong password.
- Disable the file editor with
define( 'DISALLOW_FILE_EDIT', true );. The WordPress hardening guide explains it removes the theme and plugin editing capabilities from all users. - Use least privilege. Fewer admins, editors for editors. The same guide notes that day-to-day WordPress usually only needs SELECT, INSERT, UPDATE and DELETE on the database, though some plugins and upgrades need more, so test before you restrict.
- Set file permissions the way the hardening guide suggests: 755 for folders, 644 for files, 440 or 400 for
wp-config.phpwhere your host allows it. - Keep off-server backups and update weekly. My WordPress maintenance checklist turns this into a routine.
How Do You Get Google to Trust the Site Again?
Your site can be perfectly clean and still carry a warning. Google removes it only after a review.
Check Search Console first. Open the Security Issues report and Manual Actions report, and remove any unknown users under Settings, since attackers sometimes verify themselves as owners. Also check your domain in Google’s Safe Browsing site status tool on the Transparency Report.
Bring the clean site back online, then request a review from the Security Issues report. Google’s review guide asks you to confirm you’ve cleaned the site, fixed the vulnerability and put it back online first. Write a short note per issue: what you removed, how they got in, what you changed.
Expect these waits. Google’s guide says phishing reviews take about a day, malware reviews a few days, and reviews for sites hacked with spam can take up to several weeks. Once Google finds the site clean, it says browser and search warnings are removed within 72 hours. Don’t request a review early, because Google warns that asking while the problem still exists only prolongs the warning.
Then deal with the leftovers. Spam URLs should return 404 or 410 so they drop out of the index. If rankings stay down after the warning is gone, that’s a recovery job, not a cleanup job.
How to Fix a Hacked WordPress Site: Decision Matrix
| If | And | Then |
|---|---|---|
| You can date the hack | Backup exists from before that date | Restore it, update everything, find the entry point |
| You can’t date the hack | Or no backup exists | Clean a copy by hand: core, plugins, themes, uploads, database |
| Core checksums fail | Plugins pass | Replace wp-admin and wp-includes, check root files |
Unknown admin or default_role is administrator | Files look clean | Fix options, delete users, then look for the plugin that allowed it |
| Hack returns within days | You already cleaned files | Check cron, mu-plugins, SSH keys and other sites on the account |
| Site is clean | Security Issues still flagged | Request one review with a specific note, then wait |
When Should You Bring In a Specialist?
Stop doing it yourself if the hack returns after a full cleanup, if your host suspended the account, or if the site takes payments or stores customer data. That last case can create legal reporting duties, so involve whoever handles your privacy compliance alongside a WordPress incident responder.
That’s the kind of work we handle at Skyranko under WordPress care and hacked-site repair. I quote each job after a free audit, because a single infected blog and a reinfected shop on shared hosting are very different jobs.
Frequently Asked Questions
Can I Fix a Hacked WordPress Site Myself?
Often, yes, if you’re comfortable with SFTP, a database tool and ideally WP-CLI. The procedure above is the one I use. The risky part isn’t deleting bad files. It’s missing a backdoor or never finding the entry point, so budget time for those two steps.
Will Reinstalling WordPress Remove the Hack?
Not on its own. Reinstalling core replaces wp-admin and wp-includes, but most malware lives in wp-content, the database, .htaccess or server cron. You still need to reinstall plugins and themes, clean uploads and the database, and close the hole.
Do Security Plugins Clean Hacked Sites Automatically?
Some can remove known malware, but I treat any scanner as a second opinion. Signature scanners miss new backdoors, cloaked output and database injections. Run one after your own checks, not instead of them.
How Long Does It Take to Recover Rankings After a Hack?
It depends on what Google saw. A short hack with no warning may barely register. Once a warning is involved, review times range from about a day for phishing to several weeks for spam, according to Google’s review guide, and spam URLs then need to drop out of the index.
Last updated: October 2026 by Mizanur Rahman
