WordPress Security Hardening: A Complete Guide

WordPress powers a very large share of business websites, which also makes it the most common target for automated attacks. Bots scan continuously for known weaknesses in old plugins, exposed configuration files and weak admin passwords. The good news is that most WordPress compromises are preventable with disciplined configuration and maintenance. This WordPress security hardening guide walks through the layers that matter, from accounts and plugins to server settings, backups and monitoring, in the order we apply them on real business sites.

Why WordPress sites get compromised

Before hardening anything, it helps to understand the usual entry points:

• Vulnerable plugins and themes, especially abandoned ones or "nulled" premium copies.
• Weak or reused admin passwords, often without two-factor authentication.
• Outdated core or PHP versions on neglected sites.
• Poor hosting isolation, where one compromised site on a shared account infects others.
• Leftover files such as backups, installers or database dumps in public folders.

Hardening addresses each of these, layer by layer.

Layer 1: core, plugins and themes

This is where most of the risk lives.

1. Keep WordPress core current. Leave automatic minor and security updates on.
2. Audit plugins. List every plugin and ask whether it is still needed, still maintained and from a reputable source. Remove what you do not use; do not just deactivate it.
3. Never use nulled themes or plugins. Pirated copies are a frequent malware source.
4. Prefer fewer, well-maintained plugins over many small ones that each add risk.
5. Update on a schedule. Test significant updates on a staging copy, then apply to production.
6. Remove unused themes, keeping one default theme as a fallback.
7. Watch security advisories for the plugins you depend on.

Key takeaway: Every plugin is code from a third party running with full access to your site. Treat installing one like hiring a contractor with a master key.

Layer 2: users and authentication

• Give each person a named account; avoid a shared "admin" user.
• Assign the lowest suitable role: Editors and Authors do not need Administrator.
• Enforce strong, unique passwords through a password manager.
• Require two-factor authentication for administrators and editors. See our guide to adding two-factor authentication.
• Limit login attempts and add bot protection to the login form.
• Remove accounts for former staff and agencies promptly.
• Disable or restrict XML-RPC if you do not use apps or services that need it.
• Restrict the REST API user listing endpoint if usernames should not be public.

Layer 3: wp-config.php and WordPress settings

A few configuration lines close common gaps. Typical settings in wp-config.php include:

define('DISALLOW_FILE_EDIT', true);   // disable the theme and plugin editor
define('FORCE_SSL_ADMIN', true);      // require HTTPS for admin
define('WP_DEBUG', false);            // never display errors in production

Also:

• Use unique authentication keys and salts, and regenerate them after a suspected compromise.
• Use a non-default database table prefix on new installs.
• Store wp-config.php with restrictive permissions, and where the host allows, one level above the web root.
• Use a dedicated database user for each site with only the privileges WordPress needs.
• Consider DISALLOW_FILE_MODS on sites where updates are deployed through a controlled process, accepting that dashboard updates will then be disabled.

Layer 4: file permissions and server settings

Blocking PHP execution in wp-content/uploads is one of the most valuable single changes; it stops many uploaded web shells from running even if an upload vulnerability exists. Our article on secure file uploads explains why.

At the server level, apply the basics in our Linux server hardening checklist: OS patching, SSH keys, a firewall and per-site isolation. On cPanel servers, features such as per-account PHP handlers and ModSecurity help considerably.

Layer 5: HTTPS and security headers

• Serve the entire site over HTTPS with automatic certificate renewal.
• Redirect HTTP to HTTPS and enable HSTS once everything works over HTTPS.
• Add security headers: X-Content-Type-Options, Referrer-Policy, frame protection and, where feasible, a Content Security Policy. CSP takes care on WordPress because many plugins inject inline scripts, so introduce it gradually in report-only mode first.

Layer 6: firewall and malware protection

A web application firewall (WAF) filters malicious requests before they reach WordPress. Options include:

• A cloud or CDN-based WAF in front of the site.
• A server-level WAF such as ModSecurity with a maintained rule set.
• A reputable WordPress security plugin offering firewall rules, login protection and file integrity checks.

Pick one primary approach rather than stacking several overlapping plugins, which can slow the site and conflict.

Layer 7: backups

1. Back up files and the database automatically.
2. Store copies off the server, in an account WordPress cannot access.
3. Keep multiple restore points over several weeks.
4. Test restores regularly.

Our 3-2-1 backup strategy guide explains a robust setup.

Layer 8: monitoring and response

• Monitor uptime and certificate expiry.
• Alert on new administrator accounts and changes to core files.
• Review login failure patterns.
• Keep server and access logs long enough to investigate incidents.
• Write down what to do if the site is compromised: maintenance mode, preserve logs, rotate passwords and keys, restore from a clean backup, find the entry point, then update.

A monthly WordPress security hardening routine

When hardening is not enough

Some WordPress sites have grown into platforms: membership systems, product catalogues with complex data, B2B portals or marketplaces held together by dozens of plugins. Each new plugin adds update work and attack surface, and the combinations become hard to test. In those cases, moving to a purpose-built platform can reduce both risk and maintenance effort. Our guide to moving from WordPress to Laravel discusses when that makes sense.

Hosting choices that make hardening easier

Much of the work above is easier, or partly done for you, on the right hosting. When choosing or reviewing a host for a business WordPress site, look for:

• Account isolation, so each site runs as its own system user and one compromised site cannot read another's files.
• Current PHP versions with the ability to choose per site and upgrade on a planned schedule.
• A server-level firewall and WAF with maintained rules, rather than relying entirely on plugins.
• Automatic off-server backups with several restore points and a simple restore process you have actually tested.
• Staging environments, so updates can be tested before they reach production.
• Malware scanning and clear incident support, including who to call and what the host will do if a site is infected.
• SSH and SFTP access with keys, and no plain FTP.

Cheap shared hosting can be fine for a small brochure site, but once a site handles enquiries, orders or member data, the difference in isolation and support becomes significant. Our comparison of managed and shared hosting covers the trade-offs, and our managed hosting and email service includes these items as standard.

Next steps

Start with Layers 1 and 2: remove unused plugins, update everything and enforce two-factor authentication for administrators. Those steps alone close most common entry points.

If you would rather hand this over, DigiVort can harden and maintain WordPress sites through our maintenance and support service, or plan a move to a custom platform through website migration.