WordPress Security Checklist: 6 Essential Protection Layers

A practical WordPress security checklist covering 6 protection layers, critical configurations, and technical criteria that make a measurable difference for your site.

Why WordPress security needs a layered approach

A solid WordPress security checklist is not about installing a plugin and calling it a day. According to Sucuri’s annual web threat report, WordPress accounted for more than 96% of all infected CMS platforms in their 2023 analysis of compromised sites. That doesn’t mean WordPress is insecure by design — it means that as the world’s most widely used CMS (with over 43% market share), it’s also the most frequent target.

The real problem isn’t the WordPress core. Most exploited vulnerabilities come from outdated plugins, abandoned themes, permissive server configurations, and — above all — the absence of a structured security strategy. This article isn’t a list of recommended plugins; you’ll find dozens of those elsewhere. What I’m laying out here is a technical checklist organized by layers, designed to help you identify exactly where your site is exposed and which actions deliver measurable impact.

Layer 1: Infrastructure and hosting

The first protection layer for any WordPress installation has nothing to do with WordPress itself — it depends entirely on the environment where it runs. If your server has loose configurations, it doesn’t matter how many security plugins you stack on top.

SSL certificate and forced HTTPS

It sounds basic, but in 2026 there are still WordPress sites running without HTTPS or with partial implementations where certain resources load over HTTP. An SSL certificate encrypts communication between the browser and the server, protecting login credentials, form data, and session cookies. It’s not optional: Google has treated it as a ranking signal since 2014, and modern browsers display explicit warnings on sites without SSL.

Verify that your site forces HTTPS across all URLs. On Apache servers, the redirect should live in your .htaccess file. On Nginx, the directive return 301 https://$host$request_uri; does the same job. If you’re using a CDN like Cloudflare, make sure the SSL mode is set to “Full (strict)” — not “Flexible,” which can create redirect loops or leave the connection between the CDN and your origin server unencrypted.

PHP version and server configuration

WordPress recommends PHP 8.1 or higher. Every PHP version that reaches end-of-life stops receiving security patches. If your host is still running PHP 7.4 (whose security support ended in November 2022), you have a structural gap that no plugin can close.

Beyond the version itself, several PHP directives directly affect WordPress security:

• display_errors = Off in production — error messages can expose file paths and database structure.
• expose_php = Off — prevents HTTP headers from revealing the exact PHP version.
• disable_functions — functions like exec, shell_exec, system, and passthru should be disabled unless a specific process explicitly requires them.
• open_basedir — restricts PHP script access to your installation’s directory only.

Account isolation

On shared hosting, ask whether your provider uses CloudLinux or a similar account isolation system (CageFS, for example). Without isolation, a compromised site on the same server could access files in your installation. On VPS or dedicated servers, each site should run under its own operating system user rather than the same generic www-data account.

Layer 2: WordPress core configuration

Once the server environment is solid, the next layer of WordPress security is configured within the installation itself — primarily through configuration files and settings that many administrators leave at their defaults.

The wp-config.php file

This file is the heart of your WordPress configuration. It holds database credentials, authentication keys, and constants that control system behavior. A few critical settings:

• define('DISALLOW_FILE_EDIT', true); — disables the file editor in the admin panel. If an attacker gains backend access, they won’t be able to directly modify theme or plugin code from the browser.
• define('DISALLOW_FILE_MODS', true); — goes one step further: it prevents installing or updating plugins and themes from the dashboard. This forces all changes through FTP/SSH or a controlled deployment workflow. It’s restrictive, but on stable production environments it dramatically reduces the attack surface.
• define('FORCE_SSL_ADMIN', true); — enforces HTTPS in the admin area.
• Salt keys: if you’ve never changed them since the original installation, WordPress provides an official generator at https://api.wordpress.org/secret-key/1.1/salt/. Rotating them invalidates all active sessions — a healthy periodic practice.

The wp-config.php file itself should also be protected. Move it one level above the web root (WordPress detects it automatically) or, if that’s not possible, restrict access via .htaccess with a <Files> directive that returns a 403.

Database table prefix

The default wp_ prefix makes automated SQL injection attacks easier because the attacker already knows the table names. Changing the prefix during installation is trivial. Changing it afterward requires updating the value in wp-config.php, renaming every table in the database, and updating any records in the options and usermeta tables that contain the old prefix. It’s not a difficult change, but doing it wrong can break the site. The key takeaway: if you’re setting up a new WordPress site, define a custom prefix from minute zero.

File and directory permissions

The standard permissions recommended by the official WordPress documentation are:

• Directories: 755 (or 750 in more restrictive environments).
• Files: 644 (or 640).
• wp-config.php: 440 or 400.

The most common mistake is setting 777 permissions on upload directories or plugin folders to “fix” a write error. That’s the equivalent of leaving the front door wide open. If a directory needs write permissions, it should be exclusively wp-content/uploads — and even then, 755, never 777.

Layer 3: Access management and authentication

More than half of compromised WordPress sites are breached through weak or stolen credentials. Managing who accesses the dashboard — and how — is a protection layer that’s routinely underestimated.

Passwords and two-factor authentication

Passwords should be long (at least 16 characters), unique, and managed with a password manager. It’s not enough for the administrator to have a strong password: every user with dashboard access needs the same level of rigor. Since version 5.6, WordPress generates secure passwords by default when creating users, but it doesn’t prevent users from replacing them with something weak.

Two-factor authentication (2FA) adds a layer that renders stolen passwords alone useless. Plugins like WP 2FA or Wordfence’s 2FA module implement TOTP (Time-based One-Time Password), compatible with apps like Google Authenticator or Authy. Ideally, 2FA should be mandatory for at least the administrator and editor roles.

Limiting login attempts and changing the login URL

Brute-force attacks against /wp-login.php are constant and fully automated. Limiting login attempts to 3–5 per IP address before a temporary lockout is an effective measure against bots. Changing the login URL (from /wp-login.php to a custom path) isn’t real security on its own — it’s security through obscurity — but combined with other measures it significantly reduces the noise from automated attacks and the server resources consumed by bots.

Periodic user review

Audit the registered users in your installation at least once per quarter. Look for inactive accounts, users with administrator roles who shouldn’t have them, and email addresses you don’t recognize. Attackers who gain access often create a silent admin account as a persistent backdoor. If you find an administrator account you didn’t create, you have an active problem.

Layer 4: Plugins, themes, and updates

This layer is responsible for the majority of exploited vulnerabilities in WordPress — not because plugins are inherently bad, but because their lifecycle management is often completely absent.

Criteria for evaluating plugin security

Before installing any plugin, check the following:

• Last updated: if it hasn’t been updated in more than 6 months, question whether it’s still actively maintained.
• Compatibility with your WordPress version: the official repository states this explicitly.
• Number of active installations: not a guarantee of quality, but a plugin with fewer than 1,000 installs has fewer eyes reviewing its code.
• Vulnerability history: check databases like the WPScan Vulnerability Database or Patchstack to see whether the plugin has recent CVEs and how quickly they were patched.
• Developer reputation: do they maintain other plugins? Do they respond in the support forums?

Update policy

Updating everything at once with no plan is poor practice. So is never updating at all. A sensible policy for protecting WordPress:

1. Enable automatic minor core updates (these are already active by default since WordPress 5.6).
2. Review major core updates in a staging environment before pushing to production.
3. Update security-related plugins as a priority — ideally within the first 24–48 hours of a patch being released.
4. Remove inactive plugins and themes. A theme you don’t use but still have installed can contain exploitable vulnerabilities.

Layer 5: Monitoring and incident response

The four layers above are preventive. This fifth layer assumes that no prevention is perfect and establishes mechanisms for detecting and responding to incidents.

Malware scanning and integrity monitoring

A malware scanner reviews your installation’s files looking for malicious code, PHP shells, hidden redirects, and backdoors. Integrity monitoring compares your installation’s files against the original versions in the repository and alerts you when something changes without your involvement.

Tools like Wordfence include both functions. If you prefer a server-level approach, tools like AIDE or OSSEC monitor system file changes independently of WordPress.

Verified backups

A backup you’ve never tested restoring is a backup that doesn’t exist. The minimum viable strategy:

• Full daily backup (files + database).
• Retention of at least 30 days of backups.
• External storage off the server (Amazon S3, Google Cloud Storage, an independent remote server). If the server is compromised and your backups are in the same location, you lose them too.
• Quarterly restoration test in a staging environment.

Activity log (audit log)

An activity log within WordPress records who did what and when: logins, configuration changes, plugin installations, content modifications. When an incident occurs, the audit log is the first thing you review to reconstruct the attack timeline. Plugins like WP Activity Log or Simple History serve this purpose. Without this log, investigating a compromised site is like working in the dark.

Layer 6: Web Application Firewall (WAF)

A WAF (Web Application Firewall) filters and blocks malicious requests before they reach your application. There are two main deployment models for WordPress:

• Plugin-level WAF: runs within the WordPress installation itself. Examples: Wordfence, NinjaFirewall. The advantage is that it understands WordPress context (logged-in users, internal routes), but it consumes server resources because it processes every request.
• DNS/CDN-level WAF: runs outside the server as a reverse proxy. Examples: Cloudflare WAF, Sucuri Firewall. It filters malicious traffic before it reaches your server, reducing load. The trade-off is that all traffic must route through a third party.

Neither option is universally better. The choice depends on your infrastructure, budget, and traffic volume. What isn’t optional in 2026 is having some form of WAF. Automated attacks against WordPress are relentless, and a well-configured WAF blocks the vast majority of them without any manual intervention.

WordPress security checklist: quick audit

Use this WordPress security checklist to run a rapid audit of your site’s protection status. It isn’t exhaustive, but it covers the highest-impact points:

Common mistakes that weaken WordPress security

Beyond what you should do, it’s worth being clear about which mistakes are most common and carry the worst consequences:

• Relying solely on a security plugin: a plugin is one layer, not the complete strategy. If the hosting is weak, passwords are flimsy, and there are no backups, a plugin can’t compensate for all of that.
• Having no incident response plan: what do you do if your site starts redirecting to a phishing page tomorrow? If you haven’t documented the process — who to contact, where the backups are, how to restore — you’ll lose hours or days resolving it.
• Ignoring the security of the associated email account: the admin email address is the password recovery vector. If that email account doesn’t have its own 2FA, an attacker can reset the WordPress password without ever touching your server.
• Using nulled (pirated) themes or plugins: “free” themes and plugins downloaded from unofficial sites are the most direct way to voluntarily install malware on your WordPress. There are no exceptions to this rule.

Frequently asked questions about WordPress security

Is WordPress inherently insecure?

No. The WordPress core has a dedicated security team and a rigorous review process. The most frequently exploited vulnerabilities come from third-party plugins and themes, weak server configurations, and human error (weak passwords, missing updates). A properly configured and maintained WordPress site is as secure as any other CMS.

How often should I audit my site’s security?

A full review every quarter is a good baseline. Plugin and core updates should be checked weekly. Malware monitoring and backups must be automated and continuous — not manual tasks.

Do I need a WAF if my hosting already has protection?

It depends on what your hosting includes. Many hosts offer basic DDoS protection and IP filtering, but not a WAF with WordPress-specific rules. If your host doesn’t explicitly offer application-level protection (rules that understand WordPress’s structure), adding your own WAF is recommended.

Are automatic updates safe?

Minor core updates (security patches and bug fixes) are safe in the vast majority of cases and should be enabled. For major core and plugin updates, it’s preferable to test first in a staging environment if your site has custom functionality that could be affected.

Securing a WordPress site doesn’t require advanced cybersecurity expertise — but it does require method and consistency. If you need to implement these protection layers on a custom WordPress project or a site with complex functionality, you can see how I approach these topics on my services page.

// About the author

fernandodomecq

Freelance WordPress developer specializing in WooCommerce, integrations and AI. I write about web projects, agencies and technical best practices.

View all articles →