20 WordPress hardening best practices for maximum protection

Maintaining a secure WordPress website requires more than installing a plugin or updating themes. Hackers are constantly developing new ways to exploit outdated core files, plugins, and weak login credentials. Without proactive security measures, your site could be compromised in minutes, leading to data loss, downtime, or reputational damage. 

In this guide, we present 20 WordPress hardening best practices that will strengthen your website, safeguard sensitive data, and ensure long-term protection against evolving online threats.

What does hardening WordPress mean?Link to heading

WordPress hardening is the process of applying a series of advanced security measures to make a WordPress site significantly more resistant to attacks. Unlike basic security, which might only involve keeping WordPress and plugins up to date or using strong passwords, hardening actively reduces potential vulnerabilities across multiple layers. 

It involves configuring the server, database, WordPress core, themes, and plugins to minimize attack surfaces, enforce secure access policies, and block unauthorized actions before they can cause damage.

Modern cyber threats are highly sophisticated, automated, and continuously evolving. Hackers now exploit zero-day vulnerabilities, leverage botnets for brute-force attacks, or manipulate insecure plugins and themes. A site that relies solely on basic security is vulnerable to these advanced threats.

Hardening ensures your WordPress installation can withstand a wide range of attacks, reduces downtime, prevents data theft, and protects both your site’s integrity and user trust. By implementing hardening practices, website owners gain peace of mind, reduce maintenance overhead caused by breaches, and future-proof their sites against emerging risks.

20 WordPress hardening best practices for maximum protectionLink to heading

Change the Default Table Prefix (wp_) to mitigate SQL InjectionLink to heading

By default, WordPress uses the table prefix wp_ for all database tables. Hackers targeting WordPress sites often assume this default prefix, which makes SQL injection attacks easier to execute. Changing the table prefix adds an additional layer of obscurity, making automated attacks less effective and reducing the likelihood of unauthorized database access.

How to implement it:

1. Backup your website and database
2. Edit the wp-config.php file

Open the wp-config.php file located in your WordPress root directory. Look for the line:

$table_prefix = 'wp_';

Replace wp_ with a custom prefix, such as wpsecure_ or site123_. For example:

$table_prefix = 'wpsecure_';

3. Rename existing database tables

You need to rename all WordPress tables in your database to match the new prefix. If your new prefix is wpsecure_, tables like wp_posts should become wpsecure_posts, wp_users becomes wpsecure_users, and so on. You can do this using a tool like phpMyAdmin or through SQL commands:

RENAME TABLE wp_posts TO wpsecure_posts;

RENAME TABLE wp_users TO wpsecure_users;

4. Update references in the database

Some database entries reference table names directly, such as options and user metadata. Update these references using SQL queries.

After renaming tables and updating references, your WordPress installation will be more resilient against automated SQL injection attempts that rely on default table names.

Secure the wp-config.php File: Move or Set Permissions to 400/440Link to heading

The wp-config.php file contains critical configuration details for your WordPress site, including database credentials, secret keys, and site settings. If this file is accessed by unauthorized users, attackers can gain full control over your website. Securing it by restricting access or moving it to a safer location significantly reduces the risk of compromise.

How to implement it:

Option 1: Move wp-config.php outside the web root

1. Identify your web root directory, e.g., /public_html/ or /www/.
2. Move the wp-config.php file one level above the web root. For example, if your WordPress files are in /public_html/, move it to /home/username/.
3. WordPress will still load the configuration automatically from the new location as long as the file is in the server path.

Example:

• Original location: /public_html/wp-config.php
• New location: /home/username/wp-config.php

This ensures that even if a hacker tries to access your website via a browser, the wp-config.php file is not publicly reachable.

Option 2: Restrict file permissions

1. Set strict file permissions to limit access to only the server owner. Use SSH or your hosting control panel to execute the command:

chmod 400 wp-config.php

or
chmod 440 wp-config.php

• 400 — Read-only for the owner; no access for group or others.
• 440 — Read-only for owner and group; no access for others.

2. Verify permissions by listing the file attributes:

ls -l wp-config.php

Example output:

 -r-------- 1 username group 4205 Dec 18 12:00 wp-config.php

This confirms the file is now read-only and inaccessible to unauthorized users.

Disable file editing in the WordPress dashboard (DISALLOW_FILE_EDIT)Link to heading

By default, WordPress allows administrators to edit theme and plugin files directly from the dashboard under Appearance → Theme Editor and Plugins → Plugin Editor. While convenient, this feature poses a significant security risk. If an attacker gains admin access, they could inject malicious code directly into your themes or plugins, potentially taking full control of your site. Disabling file editing prevents such attacks.

How to implement it:

1. Open the wp-config.php file in a text editor.
2. Add the following line above the line that says /* That's all, stop editing! Happy blogging. */:

define('DISALLOW_FILE_EDIT', true);

3. Save the changes and upload the file back to your server if you edited it locally.

Example:

<?php

// Enable WordPress security settings

define('DISALLOW_FILE_EDIT', true);

 

/* That's all, stop editing! Happy blogging. */

Disable PHP Execution in Sensitive Directories (uploads, includes)Link to heading

Certain directories in WordPress, such as wp-content/uploads or wp-includes, are primarily meant for storing media files, images, or other static content. By default, these directories can execute PHP code if a file is uploaded. If an attacker manages to upload a malicious PHP script, it can be executed directly from these folders, giving full access to your website. Disabling PHP execution in these directories greatly reduces this attack vector.

How to implement it:

1. Using .htaccess for Apache servers:

• Create a file named .htaccess inside the target directory (e.g., wp-content/uploads).
• Add the following code to the file:

<Files *.php>

    deny from all

</Files>

Save the file. This configuration blocks execution of all .php files in that directory.

2. For Nginx servers:

• Open your Nginx configuration file for your website.
• Add the following block inside the server context:

location ~* /wp-content/uploads/.*\.php$ {

    deny all;

}

• Save and reload the Nginx configuration.

Example:

Directory structure:

wp-content/

   uploads/

       .htaccess  <- Contains deny rule for PHP

 

.htaccess content:

<Files *.php>

    deny from all

</Files>

Remove Unnecessary Files (readme.html, license.txt, wp-config-sample.php)Link to heading

WordPress installations include several default files such as readme.html, license.txt, and wp-config-sample.php. While these files are harmless by themselves, they provide attackers with valuable information about your WordPress version and site configuration. Exposing such details can help hackers identify known vulnerabilities for that specific version and plan targeted attacks. 

Removing unnecessary files reduces the amount of information available to potential attackers, enhancing your website’s security posture.

How to implement it:

1. Identify default files:

• After installing WordPress, check the root directory of your website for the following common files:

readme.html

license.txt

wp-config-sample.php

• Other files may include wp-admin/install.php (after setup) or default theme documentation files that are not in use.

2. Remove the files safely:

• Access your website via FTP, SFTP, or your hosting control panel file manager.
• Navigate to the WordPress root directory (usually public_html/).
• Select the unnecessary files and delete them. For example:

public_html/readme.html

public_html/license.txt

public_html/wp-config-sample.php

3. Verify website functionality:

• Ensure that WordPress is still working properly after removing the files. Only remove files that are non-essential for site operation.

Example:

Directory structure before cleanup:

public_html/

   index.php

   wp-config.php

   readme.html

   license.txt

   wp-config-sample.php

Directory structure after cleanup:

public_html/

   index.php

   wp-config.php

Never use the username “admin”Link to heading

Using the default username “admin” is a common security risk for WordPress sites. Attackers know that many WordPress installations still rely on “admin” as the primary administrator account. This makes brute-force attacks and credential-stuffing attempts much easier, as hackers only need to guess the password instead of both username and password. 

By choosing a unique administrator username, you significantly reduce the risk of unauthorized access.

How to implement it:

1. Create a new administrator account:

• Log in to your WordPress dashboard.
• Navigate to Users → Add New.
• Enter a unique username that is difficult to guess. For example: siteMaster92 or wpAdminJohn.
• Assign the role Administrator.
• Use a strong password (letters, numbers, symbols, mixed case) for this account.

2. Delete or downgrade the “admin” account:

• Go to Users → All Users.
• Locate the default admin account.
• Delete it, or if needed, assign it a less powerful role (e.g., Subscriber) and remove administrative privileges.
• WordPress will prompt you to attribute existing posts to another account. Make sure to transfer posts to the new administrator account.

Enforce a strong password policyLink to heading

Weak passwords are one of the primary causes of WordPress site compromises. Hackers and automated bots can quickly guess simple passwords using brute-force or credential-stuffing attacks. Enforcing a strong password policy ensures that all users, especially administrators, use complex and unpredictable credentials. This significantly reduces the risk of unauthorized access and strengthens the overall security of your website.

A strong WordPress password should include:

• At least 12 characters
• A combination of uppercase and lowercase letters
• Numbers
• Special symbols (e.g., !, @, #, $)
• Avoid using personal information such as names, birthdays, or predictable patterns.

Assign user permissions according to the “Least Privilege” principleLink to heading

The “Least Privilege” principle is a fundamental security concept that ensures users have only the minimum permissions necessary to perform their tasks. In WordPress, giving users excessive privileges, such as Administrator rights can be dangerous. If an account with high privileges is compromised, attackers gain full access to your site, including themes, plugins, and sensitive data. 

Limiting user permissions reduces the risk of accidental changes or deliberate attacks, enhancing overall site security.

Automatically log out inactive users after a timeout periodLink to heading

Inactive sessions on WordPress websites pose a significant security risk. If a user leaves their account logged in on a shared or public device, attackers can potentially hijack the session and gain unauthorized access. Automatically logging out users after a set period of inactivity reduces the window of opportunity for such attacks, ensuring that unattended sessions do not become a vulnerability.

Use a plugin for session management:

Several WordPress plugins allow administrators to control user session durations. Recommended options include:

• Inactive Logout
• WP Idle Logout

These plugins automatically track user inactivity and log out users after the defined period.

Use email instead of username for logging inLink to heading

Many attackers target WordPress websites by guessing common usernames such as admin, administrator, or even publicly exposed author names. Using usernames for login increases the risk of brute-force or credential-stuffing attacks. Switching to email-based authentication adds an extra layer of security because email addresses are typically less predictable and harder for attackers to guess.

WordPress by default allows login via username, but several plugins can enforce email-only login, including:

• WP Email Login
• Email Login

1. Install the plugin via the WordPress dashboard:

Plugins → Add New → Search for "WP Email Login" → Install → Activate

2. Configure email login:

• After activation, navigate to the plugin settings.
• Enable the option that restricts login to email addresses only.
• Optionally, disable username login entirely to prevent attackers from exploiting known usernames.

3. Inform users about the change:

• Notify all registered users that email addresses will now be required for login.
• Ensure users have valid, accessible email addresses linked to their accounts.

Restrict Database user privileges (Allow only SELECT, INSERT, UPDATE, DELETE)Link to heading

The WordPress database contains all your website’s critical information, including posts, pages, user credentials, and plugin data. By default, WordPress database users often have broad privileges, including administrative commands such as DROP or ALTER, which can be exploited if the site is compromised. 

Limiting the database user to only the essential operations - SELECT, INSERT, UPDATE, and DELETE - reduces the potential impact of an attack and prevents unauthorized changes to the database structure.

How to implement it:

1. Access your database management tool:

Typically, this is phpMyAdmin, MySQL CLI, or a hosting control panel database interface.

2. Create a restricted database user:

If your current user has full privileges, create a new user specifically for WordPress with limited rights:

CREATE USER 'wp_limited'@'localhost' IDENTIFIED BY 'StrongPassword123!';

3. Grant only essential privileges:

• Assign permissions required for normal WordPress operations:

GRANT SELECT, INSERT, UPDATE, DELETE ON wordpress_db.* TO 'wp_limited'@'localhost';

• Replace wordpress_db with your actual WordPress database name.

4. Update the WordPress configuration file:

• Edit wp-config.php to reflect the new database user:

define('DB_USER', 'wp_limited');

define('DB_PASSWORD', 'StrongPassword123!');

5. Test database functionality:

Ensure that your website functions normally. Check posts, pages, plugin updates, and media uploads to confirm that the restricted user has sufficient privileges for standard operations.

Always use SSL/HTTPS across your entire websiteLink to heading

Using an encrypted SSL (Secure Sockets Layer) connection ensures that all data transmitted between your website and its visitors is secure. This prevents attackers from intercepting sensitive information such as login credentials, personal data, or payment details. Running WordPress over HTTPS also boosts SEO rankings, improves user trust, and prevents browser warnings that can discourage visitors from accessing your site.

Many hosting providers offer free SSL certificates via Let’s Encrypt, or you can purchase one for advanced features.

Block directory browsing: Prevent hackers from viewing folder contentsLink to heading

Directory browsing allows visitors to see a list of files inside a directory when no index file (such as index.php or index.html) exists. If enabled, attackers can easily discover sensitive files, backup archives, configuration scripts, or uploaded malware. This information significantly lowers the effort required to plan further attacks.

Blocking directory browsing is a simple but highly effective hardening measure that removes unnecessary exposure and limits reconnaissance opportunities for attackers.

How to check if directory browsing is enabled

You can test directory browsing by visiting a folder directly in your browser, for example:

https://yourwebsite.com/wp-content/uploads/

If you see a list of files: Directory browsing is enabled and must be disabled immediately.

How to disable directory browsing

This is the most common and effective solution for WordPress websites hosted on Apache.

1. Access your website via FTP or File Manager.
2. Locate the .htaccess file in the root WordPress directory.
3. Add the following line:

Options -Indexes

4. Save the file and refresh the directory URL in your browser.

Hide the WordPress version in the Header and RSS FeedLink to heading

By default, WordPress publicly exposes its version number in the website’s source code and RSS feeds. Attackers actively scan websites to identify WordPress versions and then exploit known vulnerabilities associated with outdated releases. When your WordPress version is visible, it makes targeted attacks faster and more effective.

Hiding the WordPress version does not replace updates or patching, but it significantly reduces attack surface intelligence and forces attackers to spend more time probing your site.

WordPress typically reveals version information in:

• The HTML <head> section (meta generator tag)
• RSS and Atom feeds
• Page source comments
• Some themes and plugins

Example from page source:

<meta name="generator" content="WordPress 6.4.2" />

How to Hide the WordPress Version 

Remove WordPress Version from the HTML Header

Add the following code to your theme’s functions.php file:

remove_action('wp_head', 'wp_generator');

Disable XML-RPC and secure the xmlrpc.php fileLink to heading

XML-RPC is a WordPress feature that allows remote communication with your site, enabling functions such as mobile app access, remote publishing, and integrations with third-party services. While useful in some cases, XML-RPC has become one of the most commonly abused attack vectors in WordPress.

Attackers frequently target the xmlrpc.php file to:

• Launch large-scale brute-force attacks using the system.multicall method
• Perform credential-stuffing attacks more efficiently than through the login page
• Generate excessive server load that can lead to service degradation

If you do not actively use XML-RPC, leaving it enabled unnecessarily increases your attack surface.

Completely Disable XML-RPC

1. Disable XML-RPC using code

Add the following line to your theme’s functions.php file or a custom plugin:

add_filter('xmlrpc_enabled', '__return_false');

2. Disable XML-RPC using a security plugin

Many WordPress security plugins provide a one-click option to disable XML-RPC. This method is ideal for non-technical users and ensures compatibility with future updates.

Completely remove unused WordPress plugins and themesLink to heading

Unused plugins and themes are one of the most common hidden security risks in WordPress. Even when they are deactivated, their files still exist on the server and can be exploited if they contain known vulnerabilities. Attackers often scan websites specifically for outdated or abandoned plugins and themes, using them as an entry point to gain unauthorized access.

From a security standpoint, any code that exists on your server but serves no active purpose increases your attack surface and should be removed.

Many website owners assume that deactivating a plugin or theme makes it harmless. This is a dangerous misconception.

• Deactivated plugins can still be accessed directly if vulnerable files are exposed.
• Unused themes may contain outdated PHP code or insecure functions.
• Attackers can exploit known vulnerabilities without activating the plugin or theme.

For maximum protection, unused components must be fully deleted, not just disabled.

Enable automatic security updates: Ensure timely patch managementLink to heading

Security vulnerabilities in WordPress core, plugins, and themes are discovered and publicly disclosed on a regular basis. Once a vulnerability is announced, attackers often begin scanning the internet for unpatched websites within hours. If your site is not updated promptly, it becomes an easy target.

Automatically applying security patches ensures that known vulnerabilities are closed as quickly as possible, significantly reducing the risk of exploitation. For most WordPress websites, delayed updates are one of the primary causes of successful attacks.

What should be automatically updated

Not all updates carry the same level of risk. The safest approach is to automate security-related updates while manually reviewing major changes.

Recommended automatic updates:

• WordPress core security and maintenance releases
• Minor plugin updates that include security fixes
• Minor theme updates from trusted developers
• Updates that should be reviewed manually:
• Major WordPress core version upgrades
• Major plugin or theme releases that introduce new features

Install plugins only from trusted sources with a strong update historyLink to heading

Plugins are one of the most common entry points for WordPress attacks. Many security breaches occur not because WordPress itself is insecure, but because poorly maintained or malicious plugins introduce vulnerabilities. Installing plugins only from official and reputable sources significantly reduces the risk of backdoors, malware, and exploitable code.

A plugin that is not regularly updated may contain known security flaws. Once these vulnerabilities are publicly disclosed, attackers actively scan the internet for websites still using outdated versions.

You should only install plugins from:

• The official WordPress Plugin Repository
• Well-known commercial vendors with a proven reputation
• Developers with verifiable identities, documentation, and support channels

Avoid downloading plugins from:

• Unofficial forums or file-sharing websites
• “Cracked” or pirated plugin sources
• Unknown vendors offering premium features for free

How to evaluate a plugin before installing it

Before clicking “Install,” review the following key indicators:

Last updated date

• Prefer plugins updated within the last 3–6 months.
• Plugins not updated for over a year may be abandoned.

Compatibility with your WordPress version

• Ensure the plugin is tested with the current WordPress release.

Number of active installations

• A higher number of active installs generally indicates trust and stability.

User ratings and reviews

• Look for consistent feedback and how developers respond to issues.

Changelog and support activity

• Active development and responsive support suggest long-term reliability.

Perform regular source code reviewsLink to heading

Regularly reviewing your website’s source code is a critical security practice that helps detect malicious changes early. Attackers who gain access to a WordPress site often inject hidden backdoors, obfuscated scripts, or malicious redirects directly into core files, themes, or plugins. These changes may not immediately affect site functionality, allowing malware to remain undetected for long periods.

By performing periodic source code checks, you can identify unauthorized modifications before they cause serious damage such as data theft, search engine blacklisting, or reputation loss.

What to check during a source code review

• WordPress core files: wp-config.php, wp-settings.php, index.php
• Theme files: functions.php, header.php, footer.php
• Plugin directories: especially recently added or inactive plugins
• Upload folders: /wp-content/uploads/ (malicious files should never be here)

How to perform regular source code checks

1. Access your site using FTP or File Manager.
2. Open critical files and look for suspicious patterns such as:
   • Encoded strings (base64_decode, eval, gzinflate)
   • Long unreadable code blocks
   • Unexpected JavaScript injections
3. Compare files against clean versions from the official WordPress repository.

Example of suspicious code:

<?php eval(base64_decode('aWYoJF9QT1NUKQ==')); ?>

If you see code like this and did not add it yourself, it is likely malicious.

Configure security headers (HSTS, X-Frame-Options, X-XSS-Protection)Link to heading

Security headers are HTTP response headers that instruct browsers on how to handle your website’s content. Properly configured headers reduce the risk of common web attacks such as man-in-the-middle (MITM) attacks, clickjacking, and cross-site scripting (XSS). For WordPress websites, security headers act as a defensive layer at the browser level, protecting users even if other controls fail.

1. HTTP Strict Transport Security (HSTS)

HSTS forces browsers to connect to your website using HTTPS only. Once enabled, the browser will refuse any HTTP connection attempts, even if a user types http:// manually. Without HSTS, attackers can downgrade secure connections to HTTP using SSL-stripping techniques. HSTS eliminates this risk after the first secure connection.

2. X-Frame-Options

This header prevents your website from being embedded inside an iframe on another domain. Clickjacking attacks trick users into clicking hidden elements by embedding your site within a malicious page. X-Frame-Options blocks this technique.

3. X-XSS-Protection

This header enables the browser’s built-in XSS filtering and blocks pages when an attack is detected. Although modern browsers rely more on Content Security Policy (CSP), X-XSS-Protection still adds value for older browsers.

>>> Add a powerful external defense layer and keep harmful traffic away using W7SFW.

ConclusionLink to heading

As cyber threats continue to evolve, relying solely on basic protections such as updates or passwords is no longer sufficient. The 20 WordPress hardening best practices outlined in this guide work together to reduce attack surfaces, block unauthorized access, and protect your website at multiple layers, from the server and database to the browser and user level.

By systematically applying these measures, you significantly lower the risk of data breaches, malware infections, and account takeovers.