What should I do if my WordPress site was hacked?

Do not delete anything, take the site offline, rotate every credential, restore from a pre-compromise backup, and identify the entry point before going back online. The last step is where most businesses need professional help.

Do I need WordPress security services for a small business site?

Often no. A brochure site on a reputable managed host mostly needs two-factor authentication, pruned plugins, automatic updates, and tested backups. Professional services become worthwhile when you take payments, hold regulated customer data, depend on uptime for revenue, or have already been compromised.

What makes engineering-led WordPress security different from security plugins?

Plugins observe the application from inside it. Engineering-led security changes the architecture: hardened non-root containers, read-only filesystems, automated patching, edge rate limiting, and secrets kept in cloud key management, so whole categories of attack have nowhere to land.

WordPress Security Services, Done by Engineers

About
Cloud Automation
DevOps Manual
Strategy
Resources
Our Projects
Contact

What Attacks on a Business Site Actually Look Like, By the Numbers

We did not want to hand you the usual hooded-figure clip art, so we pulled the raw CloudFront access logs from three properties we operate and counted. Three days, more than 860,000 requests, filtered to each site's exact hostname and then sorted request by request into humans, search and AI crawlers, and traffic that was unambiguously hostile: known attack tools, requests with no user agent at all, and probes for files that only an intruder would ask for. The pattern that fell out is the single most useful thing a business owner can understand about web security, and it has almost nothing to do with plugins.

Property	Platform	Requests (3 days)	Flatly malicious
udx.io	WordPress	50,546	21.4%
reddoorcompany.com	Headless Next.js	772,905	0.4%
api.discopresents.com	API service	40,351	Under 0.1%

Read that last column again, because it is the whole lesson. The same company, the same cloud, the same engineers running all three, and the WordPress site attracts roughly fifty times the malicious traffic of the headless site sitting beside it. Attackers are not targeting us; they are targeting WordPress, spraying the same handful of exploits at every WordPress installation on the internet, all day, forever. If you run a WordPress business site, better than one in five requests hitting it is actively hostile, and that is true whether or not you have ever heard from an attacker.

How They Actually Do It

The mechanics are almost boringly consistent, which is good news, because boring and consistent is exactly what good engineering defends against. Across those three days, the hostile traffic broke down into three techniques. The largest was simple credential and endpoint brute force: on the WordPress site alone, attackers hit /wp-login.php more than 4,300 times and the old /xmlrpc.php remote interface another 2,179, hammering the two doors every WordPress site ships with. The second was reconnaissance from tools and scripts arriving with no user agent, hoping to slip past logging. The third, and the most revealing, was probing for secrets left lying around.

That last category is worth seeing in detail, because it is a catalog of other people's worst days. In three days our WordPress endpoint was asked for /.env.local, /.env.production, /.env.bak, and half a dozen other variations of the environment file where developers stash database passwords and API keys. It was asked for /.git/config and /.git/HEAD, because a carelessly deployed .git folder hands an attacker your entire source history. It was asked for /.aws/credentials directly. Every one of those requests is a bet that someone, somewhere, deployed carelessly, and at internet scale that bet pays off constantly. It just does not pay off against infrastructure that never puts those files on the web root in the first place, which is the entire point of the architecture we describe below.

If You Have Just Been Hacked: The First Hour

If you found this page because something is wrong right now, here is the honest triage order. First, do not delete anything; the evidence of how they got in is the most valuable thing on the server, and wiping it usually guarantees a repeat visit. Second, take the site offline or put it behind a maintenance page, because a compromised site that stays up is spreading malware to your customers under your brand. Third, rotate every credential that touches the site: hosting, database, WordPress admins, FTP, API keys. Fourth, restore from a backup taken before the compromise, onto fresh infrastructure if you can get it.

And fifth, figure out how they got in before you go back online, because a restored site with the same hole is just an invitation to do this again next weekend. That last step is where most businesses genuinely need an expert, and it is fine to admit it. If you are in the Triangle, we are in downtown Durham and you can reach an engineer at (919) 459-7857. If you are anywhere else, the form at the bottom of this page reaches the same people.

What Professional WordPress Security Looks Like

Real security work is mostly unglamorous engineering, applied consistently. On the infrastructure we operate, WordPress runs in hardened containers that execute as non-root users with privilege escalation blocked at the cluster level, so even a compromised plugin has very little room to move. Images rebuild from source and redeploy from Git, which means recovering a site is a deployment, not an archaeology project. Operating systems patch on a monthly managed cadence, dependency updates flow through automated pull requests, and our own hardened worker images carry the security tooling with them.

Around the application, the edge does quiet, constant work: a CDN absorbs scanner traffic before it costs you compute, rate limits blunt brute-force attempts, and, a lesson we learned on our own logs, steering crawlers with robots.txt beats blunt firewall rules that end up blocking the visitors you want. Secrets live in cloud key management rather than configuration files, service accounts use workload identity instead of long-lived keys, and everything that changes leaves an audit trail. None of this is exotic. It is the discipline of doing it every time, which is precisely what a business owner should be buying.

What You Can Honestly Do Yourself

Not every site needs an engineering firm, and we would rather tell you that than sell you a retainer you do not need. If you run a brochure site on a reputable managed host, you can get most of the way there on your own: turn on two-factor authentication for every admin account, delete the plugins you are not using rather than merely deactivating them, keep automatic updates on for everything you can tolerate, confirm your host takes backups you have actually test-restored once, and use a password manager so your credentials are not a pattern.

The moment to bring in an expert is when the stakes change: you take payments, you hold customer data with regulatory strings attached, your revenue depends on uptime, or you have been compromised once already. At that point security stops being a plugin choice and becomes an architecture question, and architecture is an engineering conversation.

The Relevant Services