Hardening WordPress means closing the specific doors attackers actually use: outdated plugins and themes, weak or reused admin credentials, unrestricted login attempts, over-permissive file permissions, and an unmonitored hosting environment. Do those five things well and you eliminate the large majority of real-world compromises, because most WordPress breaches exploit known, already-patched vulnerabilities rather than novel attacks against WordPress core. The order matters more than the tooling. Patching and credential hygiene prevent far more incidents than any plugin you can install, so start there, then layer on login protection, file-level restrictions, and backups you have actually tested restoring.
Table of Contents
- Patch First: Plugins and Themes Are the Usual Entry Point
- Credentials, Roles, and the Login Page
- File Permissions, wp-config, and Server-Level Restrictions
- What a Firewall and Malware Scanner Actually Buy You
- Backups, Monitoring, and Recovery You Have Tested
- A Practical Hardening Order
- Frequently Asked Questions
Patch First: Plugins and Themes Are the Usual Entry Point
WordPress core is maintained by a dedicated security team and ships automatic updates for minor releases. The code around it is a different story. A typical site runs fifteen to thirty plugins from independent developers of varying diligence, and that third-party code is where most exploitable vulnerabilities live. Enable automatic updates for plugins and themes unless you have a concrete reason not to.
For sites where an unattended update could break a checkout flow or a custom layout, the alternative is a staging copy and a weekly update window — not indefinite delay. A plugin left three versions behind is a published vulnerability with your domain attached to it. Audit what you are running at the same time. Deactivated plugins still sit in the filesystem and can still be reachable, so delete what you do not use. Pay particular attention to plugins that have been abandoned by their developers or removed from the WordPress.org directory; a plugin with no maintainer will never be patched, and replacing it is the only fix.
- Delete deactivated plugins and unused themes rather than leaving them installed
- Replace anything whose last update is more than a year old
- Avoid nulled or pirated premium plugins entirely — backdoored code is the point of the distribution
- Subscribe to a vulnerability feed for the plugins you depend on most
Credentials, Roles, and the Login Page
Brute-force and credential-stuffing attacks against `/wp-login.php` and `/xmlrpc.php` are constant background noise on every public WordPress site. They succeed when a password is weak, reused from a breached service, or attached to an account with administrator rights that does not need them. Require unique passwords stored in a password manager, and enable two-factor authentication for every account with administrator or editor capabilities. Two-factor is the single highest-value control here, because it holds even when a password has already leaked. Several reputable plugins add it, and some managed hosts offer it at the platform level.
Then reduce what an account can do. WordPress ships six roles for a reason: a copywriter needs Author, a client reviewing drafts needs Contributor or Editor, and almost nobody needs Administrator. Remove dormant accounts when contractors leave, and disable file editing in the dashboard by adding `define('DISALLOW_FILE_EDIT', true);` to `wp-config.php` so a hijacked admin session cannot rewrite theme code directly from the browser. Rate-limit the login endpoint as well. A login-limiting plugin or a web application firewall that blocks an IP after a handful of failures turns an automated attack into a non-event. If nothing on your site uses XML-RPC — the legacy remote-publishing interface — disable it, since it allows many credential guesses in a single request.
File Permissions, wp-config, and Server-Level Restrictions
File permissions decide what a compromised process can rewrite. The conventional baseline is 755 for directories and 644 for files, with `wp-config.php` tightened to 640 or 600. Anything set to 777 is writable by every user on the server and should be corrected immediately. `wp-config.php` holds your database credentials and authentication salts, so treat it as the crown jewels. Move it one directory above the web root if your host's layout allows it, rotate the salts in the `AUTH_KEY` block if you suspect a compromise — doing so invalidates every active session — and never leave backup copies like `wp-config.php.bak` in a web-accessible directory, because a plain-text `.bak` file will be served to anyone who requests it.
Block script execution where uploads land. The `/wp-content/uploads/` directory should serve images and documents, never PHP, and an `.htaccess` rule on Apache or an `location` directive on nginx enforces that. This matters because file-upload vulnerabilities in plugins are a common path to a persistent backdoor, and a PHP file sitting in uploads is harmless if the server refuses to execute it. Disable directory indexing, serve the whole site over HTTPS with HTTP Strict Transport Security, and confirm your host runs a currently supported PHP version. PHP branches reach end of life on a published schedule, and an unsupported one stops receiving security patches regardless of how current WordPress itself is.
What a Firewall and Malware Scanner Actually Buy You
A web application firewall inspects traffic before it reaches WordPress and blocks requests matching known attack patterns. It is genuinely useful, with one important limitation worth being honest about: a firewall buys you time against a newly disclosed plugin vulnerability, but it is a mitigation, not a patch. You have two deployment choices. An endpoint firewall runs as a plugin inside WordPress, sees requests after they hit your server, and can read your site's context. A cloud or DNS-level firewall filters upstream and absorbs traffic before it reaches your origin, which also helps with denial-of-service load but requires pointing your DNS at the provider. Reverse-proxy services also sit in this category and often bundle caching.
Malware scanning is a detection control, not a preventive one. A scanner that compares your core, plugin, and theme files against known-good checksums will catch an injected backdoor or a modified core file, and file integrity monitoring will tell you when something changed that you did not change. Schedule scans and route the alerts somewhere you read, because an alert in an unmonitored inbox is the same as no alert at all. Be skeptical of hardening that trades real security for the appearance of it. Renaming the login URL, hiding the WordPress version number, and changing the database table prefix are obscurity measures: they reduce automated noise in your logs but stop no attacker who has decided to target you specifically. Do them if they are free, but never in place of patching and two-factor authentication.
Backups, Monitoring, and Recovery You Have Tested
Hardening reduces the odds of a compromise; backups determine what a compromise costs you. The standard that survives real incidents is automated daily backups of both files and database, stored off-server, with at least thirty days of retention so you can roll back to a point before an infection you did not notice immediately. A backup you have never restored is a hypothesis. Restore to a staging environment at least once so you know the procedure, know how long it takes, and know that the archive is complete.
Teams discover missing database tables or truncated uploads during the restore, which is exactly the wrong moment. Keep a basic activity log as well. A plugin that records logins, user-role changes, plugin installations, and post edits gives you a timeline when something goes wrong, and timeline is what separates a one-hour cleanup from a week of guessing. Pair it with uptime and file-change monitoring so you learn about a problem from your tooling rather than from a client or a Google Safe Browsing warning.
A Practical Hardening Order
If you are hardening an existing site and want a defensible sequence, work top to bottom and stop expanding scope until each step is actually done. For agencies managing several sites, the leverage is in the process rather than the checklist. A documented update cadence, a central record of who has access to what, and one person accountable for reviewing scanner alerts prevents more incidents than any single configuration change on any one site.
- Take a full off-server backup and verify it restores
- Update core, plugins, and themes; delete anything unused or abandoned
- Audit user accounts, remove dormant ones, demote over-privileged roles
- Enforce unique passwords and enable two-factor for all admins and editors
- Add login rate limiting; disable XML-RPC if unused
Frequently Asked Questions
Does a security plugin replace the need for manual hardening?
No. Security plugins automate login limiting, scanning, and firewall rules, but they cannot update an abandoned plugin, fix a weak admin password, or correct file permissions your host set wrong. Treat them as one layer on top of patching and credential hygiene.
Is managed WordPress hosting enough on its own?
Managed hosts typically handle server patching, backups, and often a platform-level firewall, which removes real work from your plate. They do not control your user accounts, your plugin choices, or whether you enable two-factor, so the application-layer items remain yours.
How do I know whether my site has already been compromised?
Common signals include unfamiliar administrator accounts, unexpected redirects for mobile or search traffic, spam pages indexed under your domain, modified core files, and a sudden drop in search traffic from a Safe Browsing flag. A checksum-based malware scan and your host's access logs are the first places to look.
Should I change the database table prefix on an existing site?
Rarely worth it. The change requires editing `wp-config.php` and rewriting table names and serialized option keys, which can break plugins, and the security benefit is limited to frustrating some automated SQL injection payloads. Spend the same hour on two-factor and updates instead.
