10 Ways to Secure Your WordPress Website: A Practical Security Guide

Introduction

WordPress website security requires more than installing a security plugin and assuming everything is protected. A stronger approach combines WordPress configuration, authentication security, database protection, server-level controls, backups, and continuous monitoring.

In our previous article, “Myth: A New Website Is Too Small for Hackers to Care About,” we discussed why even new and low-traffic websites can receive automated login attempts, vulnerability scans, and other malicious traffic.

WordPress security is not about installing one security plugin and assuming everything is protected. A stronger approach combines WordPress configuration, authentication security, database protection, server-level controls, backups, and continuous monitoring.

1. Keep WordPress Core, Plugins, and Themes Updated

One of the simplest security measures is also one of the most important: keep your software updated.

Your WordPress installation consists of several components:

Security vulnerabilities are regularly discovered and fixed through updates. Running outdated components may leave known vulnerabilities available to automated scanners.

However, updates should be performed carefully on production websites.

Also remove plugins and themes you no longer use. Every unnecessary component increases the amount of code that must be maintained and monitored.

2. Protect the Administrator Account with Strong Authentication

Administrator accounts have extensive control over WordPress, making them especially important to protect.

Start with a strong, unique password that is not reused on other websites. Then enable Two-Factor Authentication (2FA).

Even if an attacker obtains the password, they still need the second authentication factor. Security plugins such as AIOS can provide login protection and TOTP-based two-factor authentication.

Also periodically check:

You should recognize every Administrator account. An Administrator you did not create should be treated as a serious security event.

3. Disable Public User Registration When It Is Not Required

Many company websites, portfolios, blogs, and informational WordPress websites do not require public accounts.

Go to:

If visitors do not need accounts, make sure Anyone can register is unchecked.

This does not protect against every possible method of unauthorized account creation if the website itself is compromised, but it removes an unnecessary registration feature.

4. Protect WordPress Authentication Keys and Salts

WordPress uses authentication keys and salts as part of its cookie and session security.

They are configured inside wp-config.php. A new configuration file may contain placeholder values such as:

define( 'AUTH_KEY', 'put your unique phrase here' );

These placeholders should be replaced with strong random values. WordPress provides an official generator:

WordPress Secret-Key Generator →

The generated values should remain private.

If you suspect that a website or Administrator session has been compromised, generating new keys and salts is also useful because it invalidates existing WordPress authentication cookies, requiring users to log in again.

5. Use a Dedicated Database User Instead of MySQL Root

WordPress needs database credentials, but the application should not normally connect using the MySQL root account.

Instead, create a dedicated user for the WordPress database.

CREATE USER 'wordpress_user'@'localhost'
        IDENTIFIED BY 'STRONG_RANDOM_PASSWORD';

GRANT ALL PRIVILEGES
        ON wordpress_database.*
        TO 'wordpress_user'@'localhost';

SHOW GRANTS FOR 'wordpress_user'@'localhost';

Then configure the dedicated database credentials in wp-config.php.

This follows the principle of least privilege.

6. Disable Theme and Plugin File Editing

WordPress can allow Administrators to modify theme and plugin files directly from the dashboard.

On a production website where code is managed through Git, SSH, SFTP, or another controlled deployment process, this capability may not be necessary.

define( 'DISALLOW_FILE_EDIT', true );

This disables the built-in WordPress theme and plugin editors.

define( 'DISALLOW_FILE_MODS', true );

7. Prevent PHP Execution Inside the Uploads Directory

The WordPress uploads directory normally contains media and downloadable files such as:

It generally should not execute PHP application code. On an Apache-based WordPress server, you can add an .htaccess file inside:

Add a rule such as:

<FilesMatch "\.(?i:php|phtml|phar|php3|php4|php5|php7|php8)$">
            Require all denied
        </FilesMatch>

This adds an important security boundary. If a malicious PHP file somehow reaches the uploads directory, Apache should refuse web access to files matching this rule.

apache2ctl configtest

Syntax OK

Then test the restriction with a harmless test file rather than assuming the rule works as expected.

8. Disable XML-RPC If Your Website Does Not Need It

WordPress includes xmlrpc.php for certain remote communication features. If your website does not use functionality that depends on XML-RPC, you can consider blocking it.

<Files "xmlrpc.php">
            Require all denied
        </Files>

Place custom rules outside the WordPress-generated section of .htaccess, because WordPress may rewrite content between these markers:

# BEGIN WordPress
        ...
        # END WordPress

apache2ctl configtest

systemctl reload apache2

Finally, request /xmlrpc.php and confirm that access is denied.

9. Maintain Off-Site Backups and Know How to Rebuild

A backup stored only on the production server is not enough. If the server is compromised, deleted, corrupted, or inaccessible, the backup may be affected as well.

Keep at least one copy outside the production server, such as secure local storage or a trusted backup service.

For custom development, keeping your theme or application code in a private Git repository also provides a trusted source from which the code can be redeployed.

After a serious compromise, a safer recovery process may look like:

10. Monitor Security Logs — Don’t Just Install Security Tools

Security does not end after configuration. You also need to monitor what happens afterward.

The most important distinction is between an attack attempt and a successful compromise.

Do not spend all your time manually blocking every suspicious IP. Automated attacks can rotate through many different addresses. Focus instead on whether your security controls are preventing unauthorized actions.

A Practical WordPress Security Model

Instead of relying on one feature, think of your WordPress security as multiple layers working together.

What If You Discover an Unknown Administrator?

This deserves special attention. Suppose you open:

and discover an Administrator account that you never created. Do not simply delete it and assume the problem is solved.

First preserve useful logs and evidence, then investigate:

Then rotate credentials, invalidate existing sessions, inspect the database and filesystem, replace questionable executable files with trusted copies, and continue monitoring the website.

Final Thoughts

WordPress security is not one setting, one plugin, or one firewall rule. A practical security strategy combines multiple layers of protection.

You cannot prevent every bot from requesting your website or attempting a login. Your objective is to make sure those attempts do not become successful compromises.

And if something does go wrong, your backups, logs, trusted source code, and recovery process should allow you to respond quickly.