WordPress Security Checklist: The Essential Guide

WordPress security does not have to be complicated. After years of building and securing WordPress sites, I have learned that most security problems come from skipping the basics. Here is what actually matters.

The Problem With WordPress Security

WordPress powers over 40% of the web, which makes it an irresistible target for attackers. In 2026, WordPress vulnerabilities have surged by 68% year over year according to recent security reports. In just one recent week, 333 new security flaws were discovered across plugins and themes. That is nearly 48 new threats appearing every day.

The reality is that most WordPress hacks exploit a handful of common vulnerabilities. Outdated plugins are responsible for 95% of WordPress vulnerability reports. 81% of attacks are based on insecure or stolen passwords. On average, hackers attack WordPress sites 90,000 times a minute.

The cost of getting hacked is not just the cleanup. Removing malware professionally costs $613 on average, but serious data breaches can cost thousands or even millions. The real cost is often the reputation damage and lost business while your site is down.

The Foundation: Updates and Passwords

Keeping everything updated sounds obvious, but outdated software is the number one cause of WordPress hacks. Not fancy vulnerabilities, just old code with known exploits that attackers can find with automated scanners.

WordPress core needs to be current. All active plugins need to be updated. Your theme and parent theme need to be updated. Your PHP version should be 8.0 or higher, with 8.2 recommended. And here is the one people forget: inactive plugins should be deleted, not just deactivated. A deactivated plugin can still be exploited.

Only 30% of WordPress users enable auto updates, leaving sites exposed. The problem is that managing updates across WordPress core, plugins, and themes requires constant attention. One outdated plugin is all it takes.

Admin123 is not a password. It is an invitation. Every account on your site needs a strong, unique password. This includes WordPress admin accounts, database users, FTP and SFTP accounts, your hosting control panel, and email accounts connected to the site.

Wordfence blocks approximately 65 million brute force attacks per day. Those attacks work by trying common passwords over and over until one works. A truly random 20 character password would take longer than the age of the universe to crack via brute force. The question is whether you are using one.

What Most People Get Wrong

In my experience, the biggest mistake is prioritizing advanced features over fundamentals. I have seen sites with elaborate firewall rules that still use password123 for the admin account. I have seen sites with real time threat intelligence subscriptions that have not updated plugins in six months.

The second mistake is thinking security is a one time setup. It is not. Security requires ongoing attention. Updates need to happen regularly. Logs need to be reviewed. User accounts need to be audited. The site that was secure six months ago may not be secure today.

The third mistake is ignoring hosting. Your hosting environment matters more than most security plugins. A good host provides server level firewalls, automatic malware scanning, regular backups, SSL certificates, PHP version management, and isolated accounts so your site is not affected if another site on the server is hacked. Cheap shared hosting often means shared security problems. 41% of all websites were hacked due to vulnerabilities in their hosting provider.

Login Protection

Brute force attacks hammer your login page with thousands of password guesses. Without protection, it is just a matter of time before they guess right. If an attacker can try 1,000 passwords per second with no rate limiting, they can attempt 86 million passwords per day.

Login attempt limiting is essential. After a few failed attempts, the IP address should be blocked. Lockout times should increase for repeat offenders. Failed attempts should be logged for review. And you should be notified when attacks happen.

Changing wp admin to something custom does reduce automated attacks, but it is security through obscurity. A determined attacker will find your login page. Consider it a nice to have, not a substitute for real security.

If your password is compromised, two factor authentication is your last line of defense. It should be required for all administrator accounts, editor accounts, and any account that can modify site content. Use an authenticator app like Google Authenticator or Authy, not SMS. SIM swapping attacks make SMS based 2FA less secure.

Attack Surface Reduction

XML RPC is an old protocol for remote publishing that is mostly used for attacks now. It allows multiple login attempts in a single request through the system.multicall method. An attacker can try 500 passwords in one HTTP request, bypassing many rate limiters. Unless you specifically need XML RPC for Jetpack, the WordPress mobile app, or specific integrations, it should be disabled entirely.

WordPress lets admins edit theme and plugin files from the dashboard. If an attacker gets admin access, they can inject malicious code directly. This feature should be disabled.

You need to audit your user list regularly. Delete accounts for people who no longer need access. Reduce privileges where possible because that editor probably does not need admin access. Check for suspicious accounts you did not create. And make sure the admin username does not exist.

Server Level Protection

HTTP security headers protect against various attacks. X Content Type Options prevents MIME type confusion. X Frame Options prevents clickjacking. Strict Transport Security forces HTTPS. Content Security Policy controls resource loading.

Most WordPress sites score poorly on security header tests because no one ever set them up. See our detailed security headers guide for more on what these are and why they matter.

Your wp-config.php contains database credentials and security keys. It needs to be protected from direct access. The uploads directory needs to prevent PHP execution because attackers often upload malicious PHP files disguised as images.

Monitoring

You cannot investigate what you do not log. You need to track login attempts (successful and failed), user actions like post edits and plugin changes, file changes, and settings modifications. Review logs periodically and look for patterns of attacks, unusual activity at odd hours, and actions by unknown users.

File integrity monitoring is critical. You need to know when core WordPress files change unexpectedly. This catches malware injections into core files, unauthorized theme and plugin modifications, and backdoors added to existing files.

Backups are not security. They are recovery. When everything else fails, backups let you restore your site. You need automated daily backups stored offsite (not on the same server), with multiple versions kept (not just the latest), that you have actually tested restoring.

What You Do Not Need

Security plugins love adding features. Some are unnecessary. Database prefix changes have marginal benefit and break plugins. Hiding WordPress completely does not work because determined attackers will find it anyway. Complex firewall rules are better handled at the server level. Real time threat intelligence is often just marketing. Country blocking blocks legitimate users and is easily bypassed.

Focus on the fundamentals. A site with strong passwords, updated software, and login protection is more secure than one with a dozen advanced features but weak basics.

When Things Go Wrong

Even with good security, things can happen. If you are hacked, do not panic because rushed decisions cause more damage. Document everything with screenshots and timestamps. Take the site offline to prevent further damage. Restore from backup if you have a clean recent one. Change all passwords. Investigate how they got in and fix that hole. And monitor closely because attackers often leave backdoors.

Prevention is better than cure, but having a plan for when prevention fails is essential. That is why we built our plugin to handle the protection basics automatically. You should not have to think about XML RPC vulnerabilities or security header configurations. Those should just be handled.