Why WordPress sites get targeted
WordPress runs a very large share of the websites on the internet, which makes it an efficient target for automated attacks rather than a technically weak one. Bots scan enormous numbers of sites looking for specific, known, already-patched vulnerabilities in outdated plugins and themes, or simply try common username and password combinations against the login page. Almost none of this is a person deliberately choosing to target your specific business. It's automated, opportunistic, and entirely preventable with unglamorous basics.
The checklist, in order of priority
- Use a strong, unique admin password, and limit login attempts. Reused or simple passwords combined with unlimited login attempts is how most compromises actually start. A password manager and a login-attempt limit close this off almost entirely.
- Keep WordPress core, themes, and plugins updated. The overwhelming majority of exploited vulnerabilities were already patched by the developer before the attack happened. Falling behind on updates is choosing to stay exposed to a problem that's already been fixed.
- Delete unused plugins and themes, don't just deactivate them. A deactivated plugin's code still sits on your server. If it has a known vulnerability, that vulnerability doesn't disappear just because the plugin isn't currently switched on.
- Change the default "admin" username if you're still using it. It's the first username every automated login-guessing attempt tries.
- Turn on two-factor authentication for admin logins. This means a correctly guessed or leaked password alone isn't enough to get in, closing off the single most common entry point.
- Enforce HTTPS site-wide, not just on specific pages, so all data moving between your visitors and your server is encrypted.
- Keep real, tested backups. If something does get through despite everything else, a recent, verified backup is what turns a disaster into an inconvenience. We've written a full breakdown of what a genuine backup strategy looks like.
- Check file permissions. Overly permissive settings, particularly on configuration files, give an attacker who does get partial access far more room to cause damage than they should have.
- Review any plugin exposing WordPress's REST API or XML-RPC if you're not actively using the functionality it provides, since both have historically been used as attack vectors when left wide open unnecessarily.
Items 1 through 6 alone close off the overwhelming majority of real-world WordPress compromises. If you only do six things from this list, do those six.
What's your job versus your host's job
A good host handles the infrastructure layer: server-level firewalling, malware scanning at the hosting environment level, and the backup and replication architecture that gets you back online if something does go wrong. What a host generally can't do for you is manage your specific plugin choices, your admin password strength, or which unused themes are still sitting in your installation. Site-level hardening is genuinely a shared responsibility, and most of the checklist above sits on your side of that line.
Get the infrastructure side covered
Every WebSpaceBar hosting plan includes nightly encrypted backups and 5-minute ZFS replication as standard, so even a worst-case scenario has a clean way back.
Frequently asked questions
Why do WordPress sites get hacked so often?
Mostly because of its popularity, not any particular weakness in WordPress itself. Its large market share makes it an efficient target for automated bots scanning the entire internet for sites running outdated plugins or themes with known, already-patched vulnerabilities, or weak admin passwords.
Is a security plugin enough to protect a WordPress site?
A security plugin helps, particularly for malware scanning and login protection, but it isn't a substitute for the basics: keeping core, themes, and plugins updated, using strong unique passwords, and removing unused plugins entirely rather than just deactivating them.
Should I delete unused WordPress plugins or just deactivate them?
Delete them. A deactivated plugin's code still sits on the server, and if it has a known vulnerability, that vulnerability can potentially still be exploited even while the plugin isn't actively running. Deleting removes the code entirely.
Does two-factor authentication actually matter for a small WordPress site?
Yes. Most WordPress compromises start with a guessed or reused password rather than a sophisticated exploit. Two-factor authentication means a correctly guessed password alone isn't enough to log in, which closes off the single most common entry point regardless of how small or low-profile the site is.