What I check first when a WordPress site gets hacked

The message is almost always some version of the same thing. “My site is down.” “Google says my site is dangerous.” “My host suspended my account.” “There’s weird Japanese text showing up in Google for my pages and I have no idea why.” Sometimes there is a lot of exclamation marks. There is always a little panic.

I have been doing this a long time - exclusively WordPress and SEO since 2008 - and I have cleaned up enough hacked sites that the panic does not transfer to me anymore. Not because it is not serious. It is. But because there is a routine, and the routine works. When you have a plan, a hacked site stops being a catastrophe and becomes a checklist.

So here is the checklist. This is genuinely what I do in the first 30 minutes, in the order I do it.

First: don’t panic, and don’t start deleting things

The instinct when you find out you are hacked is to start ripping things out. Delete the suspicious file, delete the weird plugin, maybe nuke the whole thing and start over. Resist that.

The very first thing I do is take a backup of the site in its hacked state - files and database, exactly as they are. I know that sounds backwards. Why back up an infected site? Because that infected copy is evidence. If I clean too aggressively and break something, I want to be able to go back and look. And the pattern of how they got in is often hiding in the very files you are itching to delete.

So: snapshot first, surgery second.

Confirm it’s actually hacked (and how badly)

“My site looks weird” can be a hack. It can also be a broken plugin update, a caching problem, or an expired license. Before I treat it as a compromise, I confirm it actually is one. A few quick tells:

• Google Search Console. If the site is verified, the Security Issues report will often tell you flat out that Google found malware or spammy pages, and sometimes even shows you example URLs. This is the fastest “yes, it’s real” I know of.
• A search for your own site. site:yourdomain.com in Google. If you suddenly have thousands of indexed pages selling things you have never heard of, that is a spam injection.
• The unexpected redirect. Open the site in an incognito window, sometimes from your phone on mobile data. A lot of modern hacks only redirect certain visitors - mobile users, or people arriving from Google - so it looks fine when the owner checks from their own desk.

Read the logs - this is where the story is

This is the step most people skip, and it is the most useful one. The server access logs almost always contain the story of how someone got in: the suspicious POST requests, the requests to a file that should not exist, the same IP hammering wp-login.php a thousand times right before everything went wrong.

I want to know two things: how did they get in, and when. The “when” matters a lot, because it tells me which backup is safe to trust. A backup from after the break-in is just a tidier copy of the same problem.

Look at the usual hiding spots

Once I have the backups and a rough timeline, I start actually looking at the files. After enough cleanups you learn where the bad stuff likes to live:

• The WordPress core files. They should be identical to a fresh download of the same version, every single time. So I compare them against the originals - and anything modified jumps straight out. This one check catches an enormous amount, which is exactly why a core file scanner is so useful.
• wp-content/uploads. Your uploads folder is for images and PDFs. It has no business containing .php files. When I find executable code sitting in the uploads directory, that is almost always a backdoor.
• mu-plugins and oddly-named files. Attackers love must-use plugins and files with innocent-sounding names like wp-cache-functions.php that are not part of WordPress at all.
• Recently modified files. Sort the whole install by modification date. A cluster of files all changed at 3:47am on a day you were asleep is not a coincidence.
• The database. Injected spam and rogue admin users hide in there too. I check the users table for accounts I did not create, and scan post content for injected scripts and links.

Clean, then close the door

Cleaning the infection is only half the job, and honestly it is the half people fixate on. If you remove the malware but leave the hole they came through, they will be back within days - sometimes within hours. The bots that scan for vulnerable sites never sleep.

So once it is clean, I close the door behind them: every password rotated (WordPress, hosting, database, FTP), salts and keys regenerated, every user account reviewed, and WordPress, plugins, and themes all updated to current versions. Then I get a firewall and login protection in front of it so the next attempt does not get a foothold. This is exactly the kind of hardening I built WP Security Ninja to handle, because doing it by hand on every site is tedious and easy to half-finish.

The part that would have prevented all of it

Here is the uncomfortable truth I end most of these jobs with: almost every hacked site I clean up was preventable. Not by being a security genius - by doing the boring stuff. Keeping WordPress and plugins updated. Using real passwords. Having actual, recent, off-site backups so that “restore from a clean copy” is even an option.

A current backup turns a hack from a multi-day emergency into a 20-minute restore. That is the entire difference. It is also why I bundle this into ongoing website maintenance rather than only showing up for the security cleanup - the cleanup is the expensive, stressful version of a problem the maintenance quietly prevents.

If you are in the middle of this right now, take the backup, take a breath, and work the list. And if you would rather hand it to someone who has done it many, many times, get in touch - this is exactly the kind of mess I am happy to clean up.