Code HeavenCode Heaven
Back to Blog
Guide5/19/202610 min

WordPress Security Checklist 2026: 15 Steps to Lock Down Your Site

By Code Heaven

WordPress powers over 40% of the web. That scale makes it the single biggest target for automated attacks, brute-force bots, and opportunistic hackers scanning for low-hanging fruit.

Here's the thing most people get wrong: WordPress core is not the problem. According to Patchstack's 2025 annual report, roughly 96% of all new WordPress vulnerabilities originated in third-party plugins and themes -- not in core itself. The WordPress security team patches core quickly. The real risk sits in the ecosystem around it: the plugin you installed two years ago and forgot about, the theme you never updated, the admin account still using "password123."

This checklist gives you 15 concrete steps to secure a WordPress site in 2026. No fluff, no upsells. Just the actions that actually reduce your attack surface.

Part 1: Foundation -- Updates, Credentials, and Cleanup

These are the basics. Skip them and nothing else on this list matters.

Step 1: Keep WordPress Core, Plugins, and Themes Updated

Every unpatched plugin is an open door. WordPress has supported auto-updates for core since version 5.6, and you can enable auto-updates for individual plugins and themes from the dashboard.

Do this now:

  • Enable automatic updates for minor core releases (these are security patches).
  • Enable auto-updates for all plugins, or at minimum, review and update weekly.
  • If you run a staging environment, test major updates there first -- but don't let "testing" become an excuse to delay patches for weeks.

Set a calendar reminder. Every Monday, check your update screen. The vast majority of WordPress compromises exploit vulnerabilities that had patches available for weeks or months before the breach.

Step 2: Remove Unused Themes and Plugins

Deactivating a plugin does not make it safe. Its files still sit on your server, and a vulnerability in a deactivated plugin is just as exploitable as one in an active plugin.

Do this now:

  • Delete every theme you are not actively using. Keep one default theme (like Twenty Twenty-Five) as a fallback.
  • Delete every plugin that is deactivated or no longer needed.
  • Audit your plugin list quarterly. If a plugin hasn't been updated by its developer in over a year, find a replacement.

Step 3: Enforce Strong Passwords and Two-Factor Authentication

Brute-force attacks against wp-login.php are constant. Automated bots cycle through credential lists 24/7. A strong password is necessary but not sufficient -- 2FA makes a stolen password worthless.

Do this now:

  • Require passwords of at least 16 characters for all admin and editor accounts. Use a password manager.
  • Install a 2FA plugin (such as WP 2FA or Two-Factor) and require it for all users with publishing or administrative capabilities.
  • Remove or downgrade any unused admin accounts. The principle of least privilege applies: give users only the role they need.

Part 2: Hosting-Level Security

Your WordPress instance is only as secure as the server it runs on.

Step 4: Enforce SSL/TLS Everywhere

If your site isn't serving every page over HTTPS in 2026, search engines penalize you and browsers flag you as insecure. But beyond SEO, unencrypted traffic means login credentials, session cookies, and form data travel in plaintext.

Do this now:

  • Obtain and install an SSL/TLS certificate. Most hosts provide free certificates via Let's Encrypt. Cloudflare's free tier also provides edge SSL.
  • Force HTTPS site-wide. Add this to wp-config.php:

define('FORCE_SSL_ADMIN', true);

  • Set up HTTP-to-HTTPS redirects at the server level (.htaccess for Apache, server block for Nginx).
  • Verify there are no mixed-content warnings using your browser's developer console.

Step 5: Configure Server-Level Firewalls

Your hosting provider's firewall is your first perimeter. It filters traffic before it ever reaches WordPress.

Do this now:

  • If you manage your own server, configure iptables or ufw to allow only ports 80, 443, and your SSH port. Block everything else.
  • Disable direct database access from external IPs. MySQL/MariaDB should only listen on localhost unless you have a specific reason otherwise.
  • If your host provides a web application firewall (WAF) at the infrastructure level, enable it.

Step 6: Understand Managed vs. Shared Hosting Trade-offs

Not all hosting is equal from a security perspective.

Shared hosting means your site shares server resources -- and sometimes IP addresses -- with hundreds of other sites. A compromised neighbor can, in some configurations, affect your site. You have limited control over server-level settings.

Managed WordPress hosting (WP Engine, Kinsta, Cloudways, etc.) typically provides automatic core updates, server-level caching, built-in firewalls, malware scanning, and isolated environments. You pay more but offload significant security responsibility.

VPS / dedicated servers give you full control but full responsibility. If you go this route, you own patching the OS, configuring the firewall, and hardening the server yourself.

The right choice depends on your technical capacity. If you don't have a sysadmin, managed hosting pays for itself in avoided incidents.

Part 3: Application-Level Hardening

These steps lock down WordPress itself -- the application layer.

Step 7: Set Correct File Permissions

Incorrect file permissions are one of the most common misconfigurations. If WordPress files are world-writable, any exploit that gains even minimal server access can modify your code.

Do this now:

Set permissions to:

Path | Permission

Directories | `755`

Files | `644`

`wp-config.php` | `600` or `640`

On the command line:

find /path/to/wordpress/ -type d -exec chmod 755 {} \; find /path/to/wordpress/ -type f -exec chmod 644 {} \; chmod 600 wp-config.php

Never set any file or directory to 777. There is no legitimate reason for it in a production WordPress installation.

Step 8: Disable File Editing in the Dashboard

WordPress includes a built-in code editor under Appearance > Theme File Editor and Plugins > Plugin File Editor. If an attacker gains admin access, this editor lets them inject malicious code directly -- no FTP or SSH needed.

Do this now:

Add this line to wp-config.php:

define('DISALLOW_FILE_EDIT', true);

This disables the editor entirely. You can still edit files via SFTP or your IDE -- which is where code editing belongs anyway.

Step 9: Limit Login Attempts

Without rate limiting, attackers can try thousands of password combinations per hour against your login page.

Do this now:

  • Install a login-limiting plugin (Limit Login Attempts Reloaded, or use the login protection feature in a security plugin like Wordfence or Solid Security).
  • Configure it to lock out an IP after 3-5 failed attempts for at least 15 minutes, with increasing lockout durations for repeat offenders.
  • Consider moving wp-login.php to a custom URL if you face sustained automated attacks. This is security through obscurity -- it won't stop a targeted attacker, but it eliminates the vast majority of automated bot traffic.

Step 10: Restrict the REST API

The WordPress REST API exposes endpoints that can leak information by default. For example, /wp-json/wp/v2/users lists all usernames on your site -- which gives attackers half of every login credential.

Do this now:

If your site doesn't rely on the REST API for its front end (most traditional WordPress sites don't), restrict it to authenticated users:

add_filter('rest_authentication_errors', function ($result) { if (true === $result || is_wp_error($result)) { return $result; } if (!is_user_logged_in()) { return new WP_Error( 'rest_not_logged_in', __('You are not currently logged in.'), array('status' => 401) ); } return $result; });

Add this to your theme's functions.php or a custom plugin. If you use the REST API for headless WordPress, a plugin like WPGraphQL, or specific integrations, be selective -- disable only the endpoints you don't need.

Step 11: Secure wp-config.php and .htaccess

wp-config.php contains your database credentials, authentication keys, and salts. It is the most sensitive file in your WordPress installation.

Do this now:

  • Move wp-config.php one directory above your web root if your hosting setup allows it. WordPress automatically checks the parent directory.
  • Block direct access via .htaccess (Apache):

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

  • Regenerate your authentication keys and salts periodically using the WordPress salt generator. This invalidates all existing sessions.

Part 4: Backup Strategy

Security isn't just about prevention. It's about recovery.

Step 12: Implement the 3-2-1 Backup Rule

The 3-2-1 rule: keep 3 copies of your data, on 2 different types of storage, with 1 copy offsite.

Do this now:

  • Set up automated daily backups of both your database and files. Plugins like UpdraftPlus, BlogVault, or BackWPup handle this.
  • Store one backup locally (or on your hosting provider's infrastructure) and one offsite -- a separate cloud storage service like Amazon S3, Google Cloud Storage, or Backblaze B2.
  • Test your restoration process at least once per quarter. A backup you've never tested is a backup you can't trust.
  • Retain at least 30 days of backups so you can roll back past an infection that went undetected for days.

Your backup storage should not be accessible from your WordPress installation. If malware can reach your backups, it can encrypt or delete them.

Part 5: Web Application Firewalls (WAF)

A WAF inspects incoming HTTP traffic and blocks malicious requests before they reach your application. In 2026, running a WordPress site without a WAF is like leaving your front door open.

Step 13: Choose and Configure a WAF

Three popular options, each with a different approach:

Cloudflare (DNS-level WAF) -- Traffic passes through Cloudflare's network before reaching your server. The free tier includes basic DDoS protection and bot management. Pro ($20/month) adds the WAF ruleset. Best for sites that also want CDN and performance benefits.

Wordfence (application-level WAF) -- Runs as a WordPress plugin. Inspects traffic after it reaches your server but before WordPress processes it. Free tier includes the WAF with a 30-day delayed ruleset; premium ($149/year) provides real-time rules. Best for sites that want an all-in-one security plugin with scanning and login protection built in.

Sucuri (cloud-based WAF + CDN) -- Similar to Cloudflare's approach but focused specifically on security. Plans start at $199/year and include malware removal if you get hacked. Best for businesses that want a security-focused vendor with incident response included.

Recommendation: For most sites, start with Cloudflare's free tier for DNS-level filtering combined with a security plugin like Wordfence for application-level protection. This layered approach covers both network-level and application-level threats.

No WAF is set-and-forget. Review blocked requests monthly to tune rules and avoid false positives that block legitimate users.

Part 6: Monitoring and Incident Response

Prevention reduces risk. Monitoring catches what prevention misses.

Step 14: Set Up Monitoring and Alerts

You can't respond to what you don't detect.

Do this now:

  • Enable file integrity monitoring. Security plugins like Wordfence and Solid Security compare your core files against the WordPress.org repository and alert you to unauthorized changes.
  • Monitor your uptime with an external service (UptimeRobot, Better Uptime, or Pingdom). If your site goes down unexpectedly, it could indicate an attack.
  • Set up login alerts for admin accounts. Know immediately when someone logs in -- especially if it isn't you.
  • Review your server access logs regularly. Look for unusual patterns: spikes in 404 errors (scanning for vulnerabilities), repeated POST requests to wp-login.php or xmlrpc.php, and requests to files that shouldn't exist.
  • Scan for malware weekly using your security plugin or an external scanner like Sucuri SiteCheck.

Step 15: Have an Incident Response Plan

When (not if) something goes wrong, you need a plan -- not panic.

Your incident response plan should include:

  1. Detection: How you'll know you've been compromised (monitoring alerts, Google Search Console warnings, customer reports).
  2. Containment: Immediately change all passwords (WordPress admin, database, FTP/SSH, hosting panel). If the compromise is severe, take the site offline temporarily.
  3. Assessment: Determine what happened. Check file modification dates. Review access logs. Identify the attack vector (was it a plugin vulnerability? A compromised credential?).
  4. Remediation: Remove malicious code. Restore from a clean backup if needed. Update or remove the vulnerable component. If you can't determine the full scope, consider a professional malware cleanup service.
  5. Recovery: Bring the site back online. Monitor closely for 48-72 hours for re-infection.
  6. Post-incident: Document what happened. Update your security measures to prevent recurrence. If user data was compromised, you may have legal notification requirements (GDPR, state breach notification laws).

Write this plan down before you need it. Assign responsibilities if you have a team. An incident at 2 AM is not the time to figure out who does what.

The 15-Point WordPress Security Checklist

Print this. Pin it to your wall. Run through it quarterly.

  • 1. Update everything -- Core, plugins, and themes are on the latest versions. Auto-updates enabled for security patches.
  • 2. Remove unused plugins/themes -- Only active, maintained plugins and themes remain installed.
  • 3. Enforce strong credentials + 2FA -- All admin accounts use 16+ character passwords with two-factor authentication enabled.
  • 4. Enforce SSL/TLS -- HTTPS active site-wide with no mixed-content warnings.
  • 5. Configure server firewalls -- Only necessary ports open. Database not exposed externally.
  • 6. Evaluate hosting security -- Hosting type matches your security capacity. Managed hosting if you lack sysadmin skills.
  • 7. Set file permissions -- Directories at 755, files at 644, wp-config.php at 600.
  • 8. Disable dashboard file editing -- DISALLOW_FILE_EDIT set to true in wp-config.php.
  • 9. Limit login attempts -- Rate limiting active. Lockout after 3-5 failed attempts.
  • 10. Restrict REST API -- User enumeration endpoint disabled or restricted to authenticated requests.
  • 11. Secure wp-config.php -- Moved above web root or access blocked. Salts regenerated periodically.
  • 12. Implement 3-2-1 backups -- Daily automated backups. Two storage types. One offsite. Tested quarterly.
  • 13. Deploy a WAF -- DNS-level or application-level firewall active and configured.
  • 14. Enable monitoring -- File integrity monitoring, uptime checks, login alerts, and weekly malware scans active.
  • 15. Document incident response -- Written plan with roles, steps, and contact information ready before you need it.

Final Thoughts

WordPress security isn't a one-time project. It's a practice. The sites that get hacked in 2026 won't be the ones running obscure, zero-day exploits -- they'll be the ones running a contact form plugin from 2022 that never got updated.

Start at the top of this checklist and work down. You don't need to do all 15 steps today. But the first three alone -- updates, cleanup, and strong credentials with 2FA -- will eliminate the majority of your risk.

Then build the habit. Monthly check-ins. Quarterly audits. Test your backups. Review your WAF logs. Security is maintenance, and maintenance is what keeps sites online.

Your WordPress site is worth protecting. This checklist shows you how.