How to Secure a WordPress Site

Mar 13, 2026 · 4 min read

WordPress powers over 43% of the web, which makes it the most targeted CMS on the planet. But here’s what most site owners get wrong: the core software is rarely the problem. According to security research from Patchstack, the vast majority of WordPress vulnerabilities come from plugins and themes — not WordPress core itself. That means your security posture depends almost entirely on how you maintain and configure your site.

This guide covers the WordPress security best practices that actually matter, without the outdated advice.

Key Takeaways

Nearly all WordPress vulnerabilities originate in plugins and themes, not core — audit and prune your extensions regularly.
Strong authentication (unique passwords, TOTP-based 2FA, and passkeys) is your most effective defense against unauthorized access.
Server-level protections like disabling the file editor, enforcing HTTPS, and setting correct file permissions dramatically shrink your attack surface.
Reliable, tested backups are your last line of defense — a backup you have never restored is a backup you cannot trust.

Why Most WordPress Sites Get Compromised

Before jumping into fixes, it helps to understand the actual attack surface. Most successful breaches exploit:

Outdated or abandoned plugins and themes
Weak or reused passwords
Misconfigured file permissions
Hosting environments with no server-level protections

WordPress core (currently in the 6.x release line) is actively maintained by a dedicated security team, uses bcrypt for password hashing, and ships automatic minor security updates. The risk is almost always in the ecosystem around it.

WordPress Hardening Guide: The Essentials

Keep Everything Updated — Without Exception

The window between a vulnerability disclosure and active exploitation is often hours, not days. Enable automatic background updates for minor core releases. For plugins and themes, review and apply updates weekly at minimum.

More importantly, audit what you have installed. Every inactive plugin is an attack surface. If you’re not using it, delete it — not just deactivate it.

Before installing any plugin, check:

Last updated date (avoid anything untouched for 12+ months)
Active installation count
Whether it’s listed in the WordPress.org plugin repository
Open support threads mentioning security issues

Never install nulled or pirated themes and plugins. They frequently contain backdoors.

Use Strong Authentication on Every Account

WordPress core does not include built-in two-factor authentication. You’ll need a plugin or an external identity provider to add it.

Modern authentication best practices:

Use a passphrase (four or more random words) or a randomly generated password stored in a password manager like Bitwarden or 1Password
Enable TOTP-based 2FA (authenticator app) for all admin accounts — SMS-based 2FA is better than nothing but weaker
Where your stack supports it, consider passkeys/WebAuthn for phishing-resistant login
Use WordPress Application Passwords for REST API and third-party integrations instead of your main credentials

Avoid sharing admin accounts. Every user should have their own login with the minimum role required.

Apply Basic Server-Level Protections

A few configuration changes significantly reduce your attack surface:

Disable the file editor in wp-config.php to prevent code execution if an admin account is compromised:
```
define( 'DISALLOW_FILE_EDIT', true );
```
Protect wp-config.php by restricting access via your server configuration and ensuring it is not publicly accessible
Set correct file permissions: directories at 755, files at 644
Use SFTP or SSH instead of plain FTP when transferring files
Enforce HTTPS — every WordPress site should have a valid TLS certificate and redirect HTTP to HTTPS

Add a Web Application Firewall and Rate Limiting

A WAF filters malicious traffic before it reaches WordPress. You can implement this at three levels:

CDN/proxy level — services like Cloudflare offer WAF and DDoS protection with bot management
Server level — ModSecurity on Apache or Nginx
Plugin level — security plugins like Wordfence or Sucuri add application-layer firewall rules and login rate limiting

Rate limiting login attempts is essential. Brute-force attacks against wp-login.php are constant and automated.

Note on XML-RPC: Don’t blanket-disable XML-RPC without understanding your dependencies. Some plugins and mobile apps rely on it. If you don’t use it, blocking it is reasonable — but do it at the server level rather than with fragile .htaccess rules.

Back Up Reliably and Test Your Restores

A backup you’ve never tested is not a backup. Use the 3-2-1 rule: three copies, two different media types, one off-site. Automate backups and verify that restores actually work on a regular schedule.

Secure Your WordPress Site: Quick Reference Checklist

Conclusion

Securing a WordPress site is less about exotic hardening tricks and more about consistent maintenance discipline. Keep your software updated, use proper authentication, apply server-level protections, and back up regularly. Most attacks succeed because one of these basics was skipped — not because WordPress itself failed.

FAQs

No. WordPress core is actively maintained by a dedicated security team and receives automatic minor security updates. The vast majority of vulnerabilities come from third-party plugins and themes, not the core software. Keeping your extensions audited and updated is far more important than worrying about WordPress itself.

Yes. Brute-force and credential-stuffing attacks against wp-login.php are constant and automated. A strong password alone is not enough because passwords can be leaked or reused. TOTP-based 2FA through an authenticator app adds a second layer that stops most unauthorized login attempts.

It depends on your setup. XML-RPC is a legacy API that some plugins and the WordPress mobile app still use. If nothing on your site relies on it, disabling it reduces your attack surface. Block it at the server level rather than through htaccess rules, which can be bypassed more easily.

Frequency depends on how often your content changes. For active sites, daily automated backups are a reasonable baseline. More important than frequency is testing your restores regularly. Follow the 3-2-1 rule: three copies, two different storage types, one stored off-site.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.