Your WordPress Site Was Hacked. Here's What to Do.

Do these four things first. The explanations are below, and they’ll keep.

The First Hour

That’s the first hour. Now the part nobody tells you.

The Dashboard Is Lying to You

A nonprofit I worked with had a site that got maybe 300 visitors a month. No revenue, no e-commerce, no reason for anyone to single them out. They got hit with malware that had five separate pieces to it, and the pieces were redundant. Remove four, and the fifth would put the other four back.

It ran a hidden administrator account. It ran a plugin configured not to appear in the plugin list. Neither one was visible from the WordPress dashboard. The only way to know they existed was to go read the source files directly, and the only reason I found them was that something looked wrong and I couldn’t explain it.

Then there was the part that I still think about. The malware kept a log of who had already seen it.

So you scan the site and the scanner tells you it’s filthy. You clean up what it found. You scan again from the same computer, and it comes back clean. It hadn’t gone away. It had gone quiet, for you specifically.

That nonprofit’s site, by the way, was redirecting visitors to pornography. An organization that serves adults with disabilities, three hundred visits a month, and that’s what their website was doing to the people who trusted it.

Nobody chose them. That’s the whole point. Nothing about this was personal, or targeted, or a response to anything they’d done. It was automated, it found an opening, and it did not know or care what the organization was for.

Here is what that looks like as a number. I have a site behind Cloudflare right now that gets about 15 real visitors a day. In the last 24 hours, it blocked 1,170 malicious requests. That’s 78 attempts for every actual human being who visited, about one every 75 seconds, all day and all night. Nobody has heard of this site. There’s nothing on it worth stealing. It gets hit anyway, and the quietest stretch of the entire day is mid-morning, because the things doing it don’t keep human hours.

Every tool you would use to check whether your site is okay lives on the site.

That’s the thing worth understanding, and it’s why “I looked and it seems fine” is not an answer. The dashboard, the plugin list, the user list, the scanner. All of it runs inside the thing you’re asking about. All of it can be told what to say.

This Week: Rebuild, Don’t Repair

The instinct after a hack is to find the bad file and delete it. Resist that. You found one piece of something with five pieces, and you have no way to know which number you’re on.

Going Forward: Assume It Will Happen Again

Two things, and both of them are unglamorous.

Put the site behind something. Cloudflare, CrowdSec, whatever you and your developer prefer. Exposing a WordPress install directly to the open internet in 2026 is not a reasonable thing to do. This is not optional hardening for large sites. It’s the baseline.

Be ruthless with bot traffic. Block aggressively and add exceptions later when something you actually need breaks. Most site owners do this backward, allowing everything and blocking specific bad actors as they’re identified, which is a game you cannot win at the speed it’s now being played. Automated attacks are cheap, and they’ve gotten dramatically cheaper. Spinning up a fleet of bots across compromised servers takes almost no skill and almost no money.

The Longer Answer

Here’s the thing I’d want to hear if this were my site, and it’s not a sales pitch, because it costs you nothing to consider it.

WordPress runs a huge share of the web. That is genuinely an achievement, and it’s also the reason this keeps happening. When one system runs that much of the internet, finding a single flaw in it is worth an enormous amount of effort, and the people looking are relentless, well-funded, and fully automated. That math does not change. It gets worse as automation gets cheaper.

And the thing that makes WordPress powerful is the same thing that makes it exposed. A database. An admin login. Code that executes on the server every time someone loads a page. Plugins written by thousands of different people at wildly different levels of care. Every one of those is a door. You can lock all of them and stay current on all of them forever, and that’s a real strategy, but it’s a permanent obligation and it never gets easier.

The alternative isn’t a better content management system. It’s not having those doors.

A static site is just files. There’s no database to inject, no login to brute force, nothing executing on the server to hijack. This is a different thing from being well defended. The attacks have nothing to address at all. The scan that found five pieces of malware in that nonprofit’s site would have had nothing to look at, because there’s nowhere for it to live.

That comes with real tradeoffs, and I’d rather name them than pretend otherwise. Content editing works differently. Forms need a service behind them. Anything genuinely dynamic needs a different approach. Those are all solved problems now in a way they weren’t five years ago, but they are still things to solve, and for some sites the answer will still be WordPress.

If you want the full accounting of what running WordPress actually costs once you include the security overhead, I wrote that up separately in the true cost of running WordPress. The performance side of the same problem is in why your WordPress site is slow, and if your site was built on a purchased template, that’s worth understanding too.