WordPress Security Checklist: Complete Guide to Securing Your Website
WordPress powers millions of websites, but keeping a WordPress website secure requires more than installing a security plugin.
A secure WordPress website depends on several layers working together:
- Updated WordPress core
- Updated plugins and themes
- Strong authentication
- Secure hosting
- HTTPS
- Regular backups
- Proper user permissions
- Secure configuration
- Monitoring and malware scanning
- Good development and maintenance practices
There is no single setting that makes a WordPress website completely secure. The goal is to reduce unnecessary risks and make it harder for an attacker to gain access or cause damage.
This WordPress security checklist walks through the most important steps you can take to secure a WordPress website.
WordPress Security Checklist
Before going through the detailed explanations, here is the quick checklist:
- Keep WordPress core updated
- Keep plugins updated
- Keep themes updated
- Remove unused plugins and themes
- Use strong, unique passwords
- Enable two-factor authentication
- Review administrator accounts
- Use the principle of least privilege
- Enable HTTPS
- Protect
wp-config.php - Disable the WordPress file editor
- Use secure file permissions
- Maintain regular backups
- Use malware/security scanning
- Monitor login activity
- Protect the login page
- Keep PHP updated
- Use a reputable hosting provider
- Consider a web application firewall
- Keep your computer secure
- Test backups periodically
- Have a recovery plan
Now let’s look at each item in more detail.
1. Keep WordPress Core Updated
One of the most important WordPress security practices is keeping WordPress up to date.
WordPress releases updates that can include security fixes, bug fixes, and compatibility improvements. Older versions may contain vulnerabilities that have already been fixed in newer releases.
Check your WordPress version from:
Dashboard → Updates
You should also monitor update notifications instead of ignoring them indefinitely.
Don’t disable updates without a reason
Some developers disable automatic updates because they need to test changes before deploying them.
That’s reasonable for carefully managed development and production workflows.
However, simply disabling updates and forgetting about them creates unnecessary risk.
WordPress documentation specifically discourages disabling automatic updates without a good reason.
A better approach is:
Update available
↓
Backup
↓
Test on staging
↓
Update
↓
Test website
2. Keep Plugins Updated
Plugins are one of the most important parts of WordPress security.
Every plugin adds code to your website. A vulnerable plugin can therefore become an entry point into the website.
Go to:
Dashboard → Plugins
Check for available updates regularly.
When updating plugins:
- Create a backup.
- Update the plugin.
- Check the front end.
- Check the WordPress dashboard.
- Test important functionality.
For important websites, test major updates on staging first.
3. Remove Plugins You Don’t Use
Deactivating a plugin is not the same as removing it.
If you don’t need a plugin, remove it rather than leaving unnecessary software installed.
The same applies to unused themes.
For example, if your active theme is:
my-custom-theme
and you have several abandoned themes installed, remove themes you don’t need.
Keep a fallback WordPress theme if your maintenance workflow requires one, but don’t accumulate years of unused themes and plugins.
WordPress’s own security guidance recommends deleting plugins that are not being used.
4. Use Strong, Unique Passwords
Every important account should have a unique password.
This includes:
- WordPress administrators
- Hosting accounts
- SFTP accounts
- Database accounts
- Domain registrar accounts
- CDN accounts
- Email accounts
- Git repositories
- API services
Never reuse the same password across several services.
A password manager can make this much easier.
Instead of trying to remember dozens of passwords, generate unique passwords and store them securely.
5. Enable Two-Factor Authentication
A strong password is important, but adding another authentication factor provides an additional layer of protection.
Two-factor authentication can require something such as:
- Password
- Authenticator app
- Security key
- Other supported second factor
WordPress documentation describes two-step authentication as an additional authentication factor beyond the password.
For websites with administrator accounts, 2FA should be strongly considered.
Especially protect accounts that can:
- Install plugins
- Modify themes
- Manage users
- Change site settings
- Access customer information
- Modify WooCommerce settings
6. Review WordPress Administrator Accounts
Open:
Users → All Users
Review every administrator account.
Ask:
- Does this person still need access?
- Is this account still being used?
- Is the email address valid?
- Does the user actually need administrator privileges?
- Are there unexpected administrator accounts?
Delete accounts that are no longer required.
For users who only need to write blog posts, consider whether they really need the Administrator role.
7. Use the Principle of Least Privilege
Give users only the permissions they need.
For example:
Subscriber
Usually needs basic account access.
Contributor
Can create content but has limited publishing capabilities.
Author
Can publish and manage their own content.
Editor
Can manage content across the site.
Administrator
Has broad control over the WordPress installation.
Don’t give everyone Administrator access simply because it is convenient.
The fewer accounts with high-level privileges, the smaller the number of accounts that can make dangerous changes.
8. Use HTTPS
Your website should use HTTPS.
HTTPS encrypts communication between visitors and the web server and is particularly important for login sessions and other sensitive traffic. WordPress officially recommends HTTPS for securing WordPress administration and logins.
Your website should consistently use:
https://example.com
rather than:
http://example.com
Check both:
https://example.com
https://www.example.com
depending on which domain version your site uses.
Also check for mixed-content warnings after enabling HTTPS.
9. Force HTTPS for WordPress Administration
If HTTPS is correctly configured on your server, WordPress provides a configuration constant that can force administration and login traffic through SSL/TLS.
In wp-config.php:
define( 'FORCE_SSL_ADMIN', true );
WordPress documents FORCE_SSL_ADMIN as the current constant for securing administration and logins over HTTPS.
Important
Don’t add this blindly.
Your server must already be correctly configured for HTTPS. Reverse proxies and CDN configurations can require additional setup to avoid redirect loops.
10. Protect Your wp-config.php File
wp-config.php contains important configuration information, including database connection details.
It should not be publicly accessible.
WordPress documentation recommends protecting this file appropriately and notes that it can be placed one directory above the WordPress installation in supported configurations.
On Apache, a server configuration can also deny direct requests to the file.
For example:
<Files "wp-config.php">
Require all denied
</Files>
Your exact server configuration may differ, particularly if you’re using Nginx.
11. Don’t Expose Database Credentials
Never publish your wp-config.php file publicly.
Be especially careful when:
- Uploading files to GitHub
- Sharing code with a developer
- Posting debugging screenshots
- Sending configuration files
- Creating backups
- Sharing hosting files
Never publish values such as:
DB_NAME
DB_USER
DB_PASSWORD
DB_HOST
AUTH_KEY
SECURE_AUTH_KEY
AUTH_SALT
If credentials are accidentally exposed, rotate them immediately.
12. Use Strong WordPress Security Keys and Salts
WordPress uses security keys and salts to improve the security of authentication cookies and related data.
These values are stored in wp-config.php.
Examples include:
define( 'AUTH_KEY', 'unique-random-value' );
define( 'SECURE_AUTH_KEY', 'unique-random-value' );
define( 'LOGGED_IN_KEY', 'unique-random-value' );
define( 'NONCE_KEY', 'unique-random-value' );
define( 'AUTH_SALT', 'unique-random-value' );
define( 'SECURE_AUTH_SALT', 'unique-random-value' );
define( 'LOGGED_IN_SALT', 'unique-random-value' );
define( 'NONCE_SALT', 'unique-random-value' );
Don’t copy example values from an article and use them on your site.
WordPress recommends strong, random keys.
If you believe authentication credentials may have been compromised, regenerating these keys can invalidate existing login cookies.
13. Disable the WordPress File Editor
By default, WordPress administrators can access the built-in theme and plugin file editor.
This can be convenient, but it also provides a way to modify PHP code directly from the dashboard.
You can disable it with:
define( 'DISALLOW_FILE_EDIT', true );
WordPress documents this constant as a way to disable the dashboard file editor.
This does not prevent all possible file uploads or attacks, so it should be considered one security layer rather than a complete solution.
14. Be Careful With DISALLOW_FILE_MODS
WordPress also provides:
define( 'DISALLOW_FILE_MODS', true );
This is more restrictive.
It can disable plugin and theme installation and updates from the dashboard, in addition to disabling file editing.
This may be appropriate for some managed or locked-down production environments.
However, don’t add it without understanding the consequences.
You may prevent administrators from performing normal plugin and theme maintenance through WordPress.
15. Use Secure File Permissions
Incorrect file permissions can create security problems.
WordPress documentation commonly describes a setup where files are readable but not broadly writable, with directories using appropriate permissions for the server environment.
A commonly seen baseline is:
Files: 644
Directories: 755
But don’t blindly change every file to these values.
The correct permissions depend on your hosting configuration, ownership model, deployment process, and server.
Avoid overly permissive settings such as:
777
unless you have a very specific, understood reason.
16. Keep PHP Updated
WordPress security isn’t limited to WordPress itself.
Your website also depends on:
- PHP
- Web server
- Database server
- Operating system
- Hosting infrastructure
Using an outdated PHP version can create compatibility and security problems.
Before changing PHP versions:
- Create a backup.
- Check WordPress compatibility.
- Check plugin compatibility.
- Check theme compatibility.
- Test on staging if possible.
- Monitor the site after upgrading.
17. Create Regular Backups
A backup is one of the most important parts of a security strategy.
If your website is hacked, a backup may allow you to recover without rebuilding everything manually.
Back up both:
Files
Including:
wp-content/
wp-config.php
.htaccess
custom files
Database
Including:
- Posts
- Pages
- Users
- Settings
- WooCommerce data
- Plugin data
- Custom post types
- Metadata
A backup that only contains your database is not necessarily enough to restore the entire website.
18. Keep Backups Separate From the Website
If an attacker gains access to your hosting account and your only backup is stored in the same hosting account, the backup could potentially be affected too.
Maintain backups somewhere separate from the production website.
Depending on your setup, this could include:
- Separate cloud storage
- Managed backup service
- Offline storage
- Another secured server
Most importantly, test your backups.
A backup that has never been restored is an assumption, not a proven recovery solution.
19. Use a Security Scanner
A security scanner can help identify:
- Malware
- Modified files
- Suspicious code
- Vulnerable plugins
- Vulnerable themes
- Unexpected administrator accounts
- Suspicious changes
Scanning is useful, but don’t treat a scanner as a guarantee that your site is clean.
A scan is one layer of your security process.
For a deeper recovery workflow, see:
How to Scan and Fix a Hacked WordPress Site
That guide covers what to do when you already suspect the website has been compromised.
20. Monitor Administrator Logins
Pay attention to unexpected login activity.
Look for:
- Unknown IP addresses
- Unknown administrator accounts
- Login attempts at unusual times
- Unexpected password-reset emails
- Unexpected user changes
- Plugin installations you did not perform
Logging can be especially useful when investigating an incident.
However, logs should be protected because they can contain sensitive information.
21. Protect the WordPress Login
The login page is an obvious target for automated attacks.
Consider using multiple layers of protection:
- Strong passwords
- 2FA
- Login rate limiting
- CAPTCHA where appropriate
- Security monitoring
- WAF protection
- Secure hosting
Don’t rely on simply changing the login URL as your primary security strategy.
It can reduce some automated noise, but it is not a replacement for proper authentication and access controls.
22. Consider a Web Application Firewall
A Web Application Firewall, or WAF, can inspect incoming web traffic and block certain malicious requests before they reach your WordPress installation.
A WAF may be provided by:
- Your hosting provider
- A CDN
- A security service
- A WordPress security plugin
- Server-level security software
WordPress’s security documentation discusses both WordPress-level firewalls and server/network-level firewall options.
A WAF is useful, but it should complement—not replace—updates, authentication, backups, and secure configuration.
23. Keep Your Plugins and Themes From Multiple Sources Under Control
Be careful about where you obtain WordPress software.
Use:
- WordPress.org
- The official plugin/theme developer
- Reputable commercial vendors
Avoid pirated or modified “nulled” plugins and themes.
You don’t know what has been added to the code.
If a premium plugin costs money, downloading a modified copy from an unknown website can create a much larger security problem than the original purchase price.
24. Review Third-Party API Keys
Many WordPress websites connect to external services.
Examples include:
- Google Maps
- Payment gateways
- Email services
- CRM systems
- Analytics
- Social networks
- AI APIs
- Shipping services
Review your API credentials periodically.
If a credential is exposed:
- Revoke it.
- Generate a replacement.
- Update the website.
- Check access logs where available.
Never publish private API keys in JavaScript, screenshots, Git repositories, or public code.
25. Protect Your Development Environment
Website security doesn’t stop at the server.
Your own computer can also become an entry point.
Protect:
- Operating system
- Browser
- Password manager
- SFTP credentials
- SSH keys
- Git accounts
- Hosting accounts
- WordPress administrator accounts
If your computer is compromised, an attacker could potentially obtain saved credentials or authentication sessions.
Use device security and keep software updated.
26. Be Careful With SFTP and FTP
If you need file access, use secure protocols such as SFTP where available.
Avoid sending sensitive credentials over insecure connections.
Also consider creating separate SFTP accounts with access limited to the directories they actually need.
For example, a developer working on one site doesn’t necessarily need access to every website hosted on the same server.
27. Secure Your Hosting Account
Your WordPress installation can be secure while the hosting account remains poorly protected.
Protect your hosting account with:
- Strong unique password
- 2FA where available
- Limited account access
- Secure recovery email
- Monitoring for unexpected changes
Also protect your:
- Domain registrar
- DNS provider
- CDN
- Email account
If someone gains control of your domain or DNS, WordPress security alone cannot protect the website.
28. Don’t Give Developers More Access Than Necessary
If several people work on your website, give each person the access they actually need.
For example:
A content editor may only need WordPress Editor access.
A developer may need SFTP access.
A hosting administrator may need server-level access.
Avoid sharing one Administrator account among everyone.
Individual accounts make it easier to:
- Track changes
- Remove access
- Change permissions
- Investigate incidents
29. Keep Staging and Production Separate
A staging website is useful for testing:
- WordPress updates
- Plugin updates
- Theme changes
- PHP upgrades
- Security configuration
- Custom code
However, staging sites can themselves become a security problem if they are publicly accessible and forgotten.
If a staging website contains real customer or production data, protect it appropriately.
Don’t assume:
staging.example.com
is automatically private.
30. Don’t Store Sensitive Information in Public Code
Be careful with:
$password = 'your-password';
or:
$api_key = 'secret-api-key';
Private credentials should not be hard-coded into publicly accessible repositories.
For development projects using Git, make sure sensitive configuration files aren’t accidentally committed.
Use environment-specific configuration and secure secret management where appropriate.
31. Keep an Eye on wp-content
The wp-content directory contains some of the most frequently modified parts of a WordPress installation.
Pay particular attention to:
wp-content/plugins/
wp-content/themes/
wp-content/uploads/
Unexpected PHP files inside locations that normally contain only media files can deserve investigation.
For example, if you find a strange .php file inside an uploads directory, don’t automatically assume it is legitimate.
Investigate its origin and contents.
32. Don’t Automatically Trust Suspicious PHP Functions
During a malware investigation, you may encounter functions such as:
eval()
base64_decode()
gzinflate()
str_rot13()
These functions can appear in malicious code, but their presence alone does not prove that a file is malware.
Legitimate software can also use functions that look suspicious during a quick inspection.
Look at the complete file, its origin, modification time, surrounding code, and whether it belongs to known software.
This is especially important when cleaning hacked websites.
33. Review File Modification Dates During an Incident
If you suspect a compromise, recently modified files can provide useful clues.
On systems where you have shell access, you might use:
find . -type f -mtime -7
This searches for files modified within the last seven days.
You can adjust the number:
find . -type f -mtime -30
for files modified within approximately the last 30 days.
Modification dates aren’t proof of compromise, but they can help narrow an investigation.
34. Keep a Recovery Plan
Security isn’t only about preventing attacks.
You should know what you will do if an attack happens.
Your recovery plan should answer:
- Where are backups stored?
- When was the last verified backup?
- Who has hosting access?
- Who has domain access?
- Who can reset WordPress administrator accounts?
- How will compromised credentials be revoked?
- How will WordPress core be replaced?
- How will plugins and themes be reinstalled?
- How will the database be checked?
- How will the website be scanned after recovery?
A documented recovery process can save significant time during an incident.
35. What to Do If Your WordPress Site Is Already Hacked
If you believe your website has already been compromised, don’t treat it as a normal security-hardening task.
First:
- Create a backup or forensic copy if possible.
- Contact your hosting provider.
- Restrict access if necessary.
- Scan the website.
- Review administrator accounts.
- Inspect suspicious files.
- Replace compromised WordPress core.
- Reinstall trusted plugins and themes.
- Review the database.
- Change passwords.
- Rotate important credentials.
- Regenerate WordPress security keys.
- Identify the original entry point.
- Harden the website.
- Scan again.
- Monitor the website afterward.
For the complete recovery process, see:
How to Scan and Fix a Hacked WordPress Site: Complete Step-by-Step Guide
36. WordPress Security Checklist for Developers
If you’re a developer maintaining WordPress websites, add these items to your regular workflow.
Before launching
- HTTPS configured
- Admin accounts reviewed
- Strong passwords configured
- 2FA enabled
- Unused plugins removed
- Unused themes removed
- WordPress updated
- Plugins updated
- Theme updated
- Backups configured
- Backup restoration tested
- Debugging disabled on production
- File editor disabled where appropriate
- API credentials protected
- Hosting account protected
- Domain/DNS account protected
During maintenance
- Test updates
- Check backups
- Review security notifications
- Review administrator accounts
- Remove unnecessary software
- Monitor logs
- Check for unexpected changes
37. Quick WordPress Security Setup
If you’re setting up a new WordPress website, start with these fundamentals:
1. Install WordPress from a trusted source
2. Configure HTTPS
3. Create strong administrator credentials
4. Enable 2FA
5. Remove unnecessary software
6. Update WordPress
7. Update plugins and themes
8. Configure backups
9. Protect wp-config.php
10. Disable the file editor
11. Configure appropriate permissions
12. Set up security monitoring
13. Test recovery procedures
Then add additional protections based on the website’s requirements.
An informational blog may need a different security architecture from a large WooCommerce store or a membership platform.
WordPress Security Checklist: Final Version
Before considering a WordPress website reasonably hardened, review these areas:
WordPress
- Current WordPress version
- Current plugins
- Current themes
- No unnecessary plugins
- No unnecessary themes
Accounts
- Strong unique passwords
- 2FA
- Administrator accounts reviewed
- Unused accounts removed
- Least-privilege roles
Server
- Supported PHP version
- Secure file permissions
- HTTPS
- Secure SFTP/SSH access
- Hosting account protected
WordPress configuration
wp-config.phpprotected- Security keys configured
- File editor disabled where appropriate
- Debugging disabled on production
- Sensitive credentials protected
Monitoring
- Security scanning
- Login monitoring
- Error logging
- Backup monitoring
- Unexpected user/file changes investigated
Recovery
- Regular backups
- Off-site backup
- Backup restoration tested
- Recovery procedure documented
Frequently Asked Questions
Is WordPress secure?
WordPress can be operated securely, but security depends on the complete environment: WordPress core, plugins, themes, hosting, authentication, configuration, and maintenance.
Keeping WordPress and its components updated is an important part of reducing known security risks.
Do I need a WordPress security plugin?
Not every website needs the same security setup.
A security plugin can provide useful features such as scanning, firewall rules, login protection, or monitoring, but it does not replace updates, strong authentication, backups, HTTPS, and secure hosting.
Is changing the WordPress login URL enough?
No.
Changing the login URL may reduce some automated traffic, but it should not be considered a replacement for strong passwords, 2FA, rate limiting, monitoring, and other security controls.
Should I disable XML-RPC?
It depends on your website.
XML-RPC is used by some WordPress functionality and integrations. If you don’t need it, restricting unnecessary access can be considered, but don’t blindly disable it if your website or integrations depend on it.
Should I use 777 permissions?
Generally, no.
Overly permissive permissions can allow more users or processes to modify files than necessary. Use permissions appropriate for your hosting environment.
How often should I back up WordPress?
It depends on how frequently your website changes.
A site publishing content every day needs a different backup schedule from a mostly static brochure website.
The important part is that backups are automated, stored separately, and periodically tested.
Can a security plugin guarantee that my website won’t be hacked?
No.
Security plugins can provide useful protection, but no single plugin can guarantee complete security.
WordPress security requires multiple layers.
What should I do if my WordPress site is hacked?
Don’t simply delete suspicious files and assume the problem is solved.
Create an appropriate backup/forensic copy, investigate the entry point, review accounts and credentials, replace compromised software, scan the website, harden the installation, and monitor it afterward.
Final Thoughts
WordPress security isn’t a one-time task.
A website that is secure today can become vulnerable later if plugins are abandoned, passwords are reused, software becomes outdated, backups stop working, or new vulnerabilities are discovered.
The most effective approach is to build security into your normal maintenance routine.
Keep WordPress and its components updated, protect administrator accounts, use HTTPS and 2FA, maintain reliable backups, remove unnecessary software, protect sensitive configuration files, and monitor the website for unexpected changes.
Most importantly, have a recovery plan before you need one.
A good WordPress security strategy isn’t about adding every security feature available. It’s about using appropriate layers of protection and maintaining them consistently.