Your WordPress Site Got Hacked. Do This First.
Back in 2011, I was working on vWorker — that’s when before the takeover by Freelancer.com — and a client from Ohio messaged me in a panic. His Joomla 1.5 site was serving pharmacy spam. Not just a page or two. Every URL on the domain was showing Viagra listings in Google’s index. He’d had the site for three years, never updated a plugin, and the hosting account was shared with four other sites he ran. I didn’t know it yet, but this was my introduction to a cross-site contamination scenario, and I cleaned it completely wrong the first time. I wiped his Joomla install, restored a “clean” backup, and handed it back. Two days later, same spam. The backdoor was sitting in a folder under one of his other sites on the same cPanel account, quietly reinfecting everything I touched.
That mistake cost me about 12 hours of unpaid work and cost him two weeks of Google visibility. I never made it again. Here’s what I learned — and what you need to do if your WordPress site is hacked right now.
Step One: Don’t Panic, But Don’t Wait Either
The first 30 minutes matter. A lot.
If Google has already flagged your site — you’re seeing that red “Deceptive site ahead” warning, or your browser is blocking visitors outright — that’s the Google red screen warning from Safe Browsing. It can tank your traffic within hours and take days to reverse even after you’ve cleaned everything. So speed is real, but frantic clicking around your wp-admin while infected is also how you accidentally delete something you need for forensics later.
First thing: put the site into maintenance mode or take it offline. If you can’t access wp-admin because the hack has locked you out, go straight to your hosting control panel and either password-protect the directory or temporarily rename the index.php file via File Manager. Stopping new visitors from hitting infected pages matters — both for them and for limiting further Google crawls of bad content.
Then change everything. WordPress admin password, hosting cPanel password, FTP credentials, database password. Do it in that order. Don’t skip database — I’ve seen infections where the attacker had already created a hidden admin user directly in the wp_users table and was logging back in through normal wp-login.php every time the site owner changed surface-level credentials.
What You’re Actually Looking For
This is where most tutorials lose people, because they say “scan your site” without explaining what a scan is actually finding.
Install Wordfence if it isn’t already there. Run a full scan. What you’re looking for is files that have been modified recently and don’t belong — particularly anything in wp-content/uploads with a .php extension. Uploads shouldn’t have PHP files in them at all. Ever. If Wordfence flags something in that folder, that’s almost certainly a webshell — a backdoor that lets the attacker run commands on your server through a browser.
I also run a manual check through the hosting File Manager sorted by “last modified” date. If your site was last touched in November and there’s a file in wp-includes/ms-settings.php that was modified last Tuesday at 3 AM, that file didn’t modify itself. That’s the kind of detail automated scans sometimes miss because the attacker has obfuscated the code well enough to avoid signature matching.
Base64-encoded strings are the most common obfuscation I see. Something like eval(base64_decode(...)) buried inside an otherwise normal-looking function. Wordfence catches a lot of these, but not all. For serious infections I use the wp-cli command below, which searches every PHP file in the install for eval calls combined with base64:
wp eval 'foreach(new RecursiveIteratorIterator(new RecursiveDirectoryIterator(".")) as $f){ if($f->getExtension()==="php"){ $c=file_get_contents($f); if(strpos($c,"eval(base64_decode")!==false) echo $f."\n"; } }'Run that from your WordPress root over SSH. It won’t fix anything, but it gives you a hit list fast.
My Honest Opinion on “Clean Backup” Restores
Here’s where I’m going to be direct with you, because most articles hedge on this: restoring a backup is not the same as cleaning a hacked site, and doing it wrong is exactly the mistake I made in 2011.
If you restore a backup without first identifying how the attacker got in, you are going to get reinfected. It might take a week. It might take 48 hours. The vulnerability is still there — an outdated plugin, a nulled theme, a weak password on an old admin account — and the attacker’s bots are often set up to automatically recheck and reinfect sites they’ve previously compromised.
My rule: restore the backup only after you know the entry point, have patched or removed whatever was exploited, and have cleaned or replaced the core files. In that order. If you don’t have a clean backup from before the infection — which is common, because a lot of clients have no backups at all, or their backups are also infected — then a full manual clean is the only option. That means replacing wp-core files from a fresh WordPress download, auditing every plugin and theme file, and checking the database for injected JavaScript or spam links in post content.
After the clean, fixing the deceptive site ahead warning fix with Google is a separate step: you submit a review request through Google Search Console under Security Issues. Google typically responds within 24–72 hours for straightforward cases. Longer if the infection was severe or the site has been flagged before.
After the Clean — What to Actually Put in Place
The hacked website recovery steps don’t end when Wordfence shows green. The hour after a clean is when you build the defences that should have been there before.
Block PHP execution in the uploads folder. Full stop. This is the single most effective preventative measure I know, and it takes two minutes. Add this to a .htaccess file inside wp-content/uploads/:
<Files *.php>
deny from all
</Files>Then: disable XML-RPC if you’re not using it (the Disable XML-RPC plugin works, or you can block it in .htaccess), set file permissions correctly (644 for files, 755 for directories, 600 for wp-config.php), and remove any admin accounts you don’t recognise. Check your wp_options table for any suspicious siteurl or home values that might be redirecting visitors. Enable two-factor authentication on every admin account going forward.
Wordfence’s firewall on “extended protection” mode, with rate limiting on login attempts turned on, handles a huge amount of brute-force and automated attack traffic before it ever reaches WordPress. That alone would have prevented three of the last five wordpress emergency response calls I dealt with this year.
One last thing — document what you found and how you fixed it. I send clients a short written summary every time. Not just for their records; it’s how you prove to yourself you actually understood the infection and didn’t just guess your way through it.
If you’re in the middle of this right now and you need someone to handle it properly, I take on WordPress site hacked recovery work through swsDreams — drop me a message and I’ll tell you honestly whether I can help and what it will take.
The Order Matters: hacked website recovery steps That Most Guides Get Wrong
Every time I work a compromised site, I see the same mistake: people jump straight to deleting files before they’ve documented anything. Don’t do that. The hacked website recovery steps I follow always start with taking a full snapshot — database, file system, server logs — before I touch a single line of code. I’ve had clients where the infection pattern in the access logs was the only thing that told me exactly which plugin was the entry point. You delete first, you lose that thread. Screenshot your Wordfence scan results, export your error logs, note the file modification timestamps. Then you start cleaning.
Related reading: How to Remove Malware From WordPress Manually and WordPress Pharma Hack: Step-by-Step Cleanup.
