WordPress powers over 40% of the web, which makes it the most heavily-targeted CMS by automated attack tools. The overwhelming majority of WordPress compromises are not targeted attacks on your business specifically — they are automated bots scanning for known vulnerable plugins, weak passwords, or misconfigured installations. This has an important implication: most WordPress security incidents are preventable through straightforward measures applied consistently. You do not need to be paranoid; you need to be systematic.

This guide covers the six layers of WordPress security that together make up an adequate defence for a business site — from the hosting environment through to recovery planning — and what good day-to-day security looks like once it is in place.

Why WordPress is a target

Three factors make WordPress the single most attacked web platform in existence:

  • Market share. Over 40% of all websites run WordPress, creating the world’s largest homogeneous attack surface. An exploit that works against one WordPress site works against millions.
  • Plugin ecosystem. 60,000+ plugins in the official directory alone, with countless more outside it. Plugin code quality varies enormously, and many are maintained by solo developers without security expertise. A vulnerability in a widely-used plugin is an exploit that works against every site running it.
  • Economic incentive. Because of the above two, writing a WordPress exploit is economically rational for attackers in a way that targeting smaller platforms is not. A single exploit can be weaponised and deployed at scale.

The practical consequence: automated scanning tools probe the web continuously for known vulnerabilities, and the window between public disclosure of a plugin vulnerability and in-the-wild exploitation can be as short as 24-48 hours. A WordPress site that is not actively maintained is a site that will eventually be compromised.

Layer 1: Hosting environment

Security starts before WordPress is even installed. Your hosting environment determines the baseline risk profile of everything running on it.

Server isolation means that a compromise on one account on your server cannot spread to yours. On shared hosting with poor isolation, cross-contamination from neighbouring sites is a real and documented risk. On managed hosting with properly isolated accounts — typically via Linux containers or cgroups — infection between accounts is prevented at the infrastructure level.

Web Application Firewall (WAF) at the server level blocks known malicious requests before they reach WordPress or PHP. Server-level WAF is more effective than plugin-based WAF because it operates at a lower level — it cannot be bypassed by exploiting the WordPress application itself. Plugin WAFs load after PHP has already started processing the request, which means they cannot defend against attacks on PHP itself or on the webserver configuration.

Brute force protection at the network level prevents credential attacks from consuming server resources. Server-level rate limiting blocks repeated login attempts before they reach WordPress, where they would otherwise generate database queries, consume PHP workers, and potentially take down the site.

Automatic security patching at the server level ensures the underlying PHP, operating system, and server software are kept current without requiring your intervention. Unpatched server software is a separate attack surface from WordPress itself.

Continuous malware scanning catches compromises earlier. File-integrity monitoring at the server level detects unauthorised changes to WordPress core files, themes, and plugins — often the first sign of a successful compromise.

If your hosting provider cannot clearly explain their isolation model, WAF configuration, patching schedule, and scanning approach, that is significant missing information about your risk exposure.

Layer 2: WordPress core, plugin, and theme updates

The single most common vector for WordPress compromise is a known vulnerability in an outdated plugin or theme. Automated exploit tools scan the web continuously for sites running vulnerable versions of popular plugins — the 24-48 hour window between disclosure and exploitation is not theoretical.

Keep WordPress core updated. Enable automatic minor version updates at minimum by adding define('WP_AUTO_UPDATE_CORE', 'minor'); to wp-config.php. Major version updates should be applied promptly after your host and plugins confirm compatibility. Running an out-of-date major version for months is a meaningful security risk.

Keep plugins updated. Enable automatic background updates for plugins where possible. For plugins that require manual testing before update (complex ecommerce plugins, page builders, custom-developed plugins), establish a regular update schedule — at least monthly, preferably fortnightly. A plugin update deferred for three months is a plugin running known-vulnerable code for three months.

Remove unused plugins and themes. An inactive plugin with a known vulnerability is just as exploitable as an active one — PHP files are PHP files regardless of whether a plugin is “active” in the WordPress admin. Delete, do not just deactivate, plugins and themes you are not using. The default WordPress themes (twentytwentyfour etc.) should remain for emergency use; anything else unused should go.

Audit the plugins you do use. Number of active installations, last updated date, open support issues, and WordPress compatibility claims are all public. A plugin that hasn’t been updated in two years is a plugin you should be finding an alternative to.

For the full picture on vulnerability management, see our guide to WordPress vulnerabilities and how patching works.

Layer 3: Authentication and access control

Most WordPress compromises start with a successful login — either a stolen password, a credential-stuffing match from a data breach elsewhere, or a brute-force success against a weak password.

Two-factor authentication (2FA) for all admin accounts. Plugins like WP 2FA, Two Factor, or Google Authenticator add this. For a business site, 2FA is not optional — it is the single measure that turns a stolen password from “full site compromise” into “failed login attempt”.

Limit admin accounts. Every WordPress admin account is a potential entry point. Audit your user list regularly and remove accounts that are no longer needed (former employees, departed contractors, test accounts). Use the minimum role necessary — an editor does not need admin access, a shop manager does not need administrator privileges.

Change the default admin username. The default username is the first credential attackers try. If your site was set up with an admin account, create a new administrator account, transfer any owned content, and delete the admin account.

Strong, unique passwords. Enforced at the policy level. A WordPress password that is also used anywhere else is a WordPress password that will be compromised eventually through a breach at that other service.

Limit login attempts. Block or slow down repeated failed logins. Server-level rate limiting (preferred) or a plugin like Limit Login Attempts Reloaded prevents brute-force attacks from consuming resources while blocking the attack.

Consider hiding wp-login.php. Moving your login page to a custom URL via a plugin like WPS Hide Login stops automated scanners from finding it. This is security through obscurity and not a substitute for strong passwords and 2FA, but it dramatically reduces automated attack volume — most bots give up rather than scan for relocated login pages.

Layer 4: File and database security

Correct file permissions. WordPress files should not be world-writable. Correct permissions: directories at 755, files at 644, wp-config.php at 600 or 640. Overly permissive file permissions allow exploited vulnerabilities to write and execute malicious files.

Protect wp-config.php. This file contains your database credentials. Ensure it is not accessible from the web. Add the following to your .htaccess (Apache / LiteSpeed) to prevent direct access:

<files wp-config.php>
  order allow,deny
  deny from all
</files>

Disable file editing from the admin panel. The WordPress admin includes a file editor that can modify plugin and theme files. If an attacker gains admin access, this becomes a direct code execution vector. Disable it by adding to wp-config.php:

define('DISALLOW_FILE_EDIT', true);

Block PHP execution in uploads. The wp-content/uploads/ directory should never execute PHP. If an attacker manages to upload a PHP file via a vulnerable plugin, blocking execution prevents them from running it. Add to .htaccess in the uploads directory:

<Files *.php>
  deny from all
</Files>

Database table prefix. Using a non-default prefix (not wp_) makes SQL injection attacks slightly harder. This is easiest to set during initial installation but can be changed post-installation with care.

Use SSL/TLS properly. All admin access and any form submission must be over HTTPS. See our SSL and HTTPS guide for the configuration details.

Layer 5: Ongoing monitoring

Security is not a one-time setup. Ongoing monitoring catches problems early, when they are still inexpensive to resolve.

Malware scanning. Automated file scanning looks for known malware signatures, suspicious code patterns, and unexpected file modifications. This should run at least daily. On managed hosting it is typically handled at the infrastructure level; on shared hosting you need a security plugin (Wordfence, Sucuri Scanner) or an external service.

Uptime monitoring. Many security incidents are first detected because the site goes down or starts serving errors. External uptime monitoring alerts you immediately. Uptime Robot (free, 5-minute checks) is adequate for most sites; paid services with 1-minute checks and keyword-content monitoring are better for business-critical sites.

Login audit logging. Maintain a log of admin logins, failed attempts, and user role changes. Wordfence and similar plugins provide this. An unexpected admin login at 3am from an unfamiliar IP is something you want to know about immediately, not after the damage is done.

Integrity monitoring. Core WordPress files, themes, and plugins should not change except through updates you initiated. Integrity monitoring detects unexpected file modifications — often the first sign of a successful compromise.

Vulnerability alerting. Services like WPScan and Patchstack publish WordPress vulnerability feeds. Subscribing to alerts for plugins you actually run gives you disclosure notifications hours before automated exploitation begins.

Layer 6: Backup and recovery

Backups are your recovery mechanism when security measures fail. They are not optional, and they are the cheapest insurance a business site can carry.

Requirements for an adequate backup strategy:

  • Daily automated backups at minimum; hourly or continuous for active WooCommerce stores
  • Off-server storage — backups stored only on the same server they back up are lost in the same incident
  • Sufficient retention — 30-day minimum for business sites; 60-90 days for transactional sites. Many compromises are not discovered for weeks
  • Tested restore process — a backup you have never tested restoring is a backup of unknown quality
  • Documented recovery runbook — the person restoring at 2am during a crisis is often not the person who set up the backups

On managed hosting, daily backups to off-server storage should be included in the plan. If they are not, add them — the cost of a backup service is trivial compared to the cost of losing your data. See our full WordPress backup strategy guide for the mechanics.

What good security looks like day-to-day

A well-secured WordPress site requires very little ongoing effort once it is set up correctly:

  • Plugins and themes update automatically or on a regular scheduled review
  • 2FA is in place for all admin and editor accounts
  • Backups run daily, are off-site, and have been tested within the last 90 days
  • Malware scanning runs at the infrastructure level
  • Uptime monitoring is active and routes alerts to someone who will see them
  • User accounts are reviewed quarterly — departed staff removed, unused accounts deleted
  • The login URL is non-default, reducing automated attack volume

The ongoing overhead is measured in minutes per month, not hours. The alternative — dealing with a compromised site, potential data breach notification obligations under GDPR, and SEO recovery — is measured in days and significant cost.

When things go wrong

Even with layered security, no system is guaranteed. If your site is compromised, follow our what to do when your WordPress site is hacked guide — the short version is: isolate the site from the public internet, preserve evidence, restore from a known-clean backup, investigate the entry vector, and close it before going back online.

The business consequences of a WordPress compromise — customer data exposure, SEO blacklisting, chargebacks, reputational damage, potential regulatory fines — are documented in our guide to what happens when your WordPress site gets hacked. Reading that before being compromised is cheaper than reading it afterwards.

The hosting question

Every layer in this guide is strongly affected by your hosting choice. Cheap shared hosting forces you to implement application-level versions of things that should exist at the server level — WAF as a plugin instead of network-level, malware scanning as a plugin instead of continuous file integrity checks, backups as an add-on service instead of included and tested. Each application-level substitute is worse than the server-level equivalent, and the cumulative effect is a site with adequate security in theory but much weaker in practice.

Managed hosting built for WordPress handles layers 1, 5, and large parts of 4 and 6 at the infrastructure level — leaving you to focus on layers 2 and 3 (updates and authentication), which application-level tooling handles well. This is why hosting is the foundation: it determines how much of the rest you have to solve yourself, and how well you can solve it.

For how our security approach works in practice, see our security overview. For comparisons on security-specific features against other hosts, see our comparison pages.