How to Secure a WordPress Website in 2026: 12 Essential Hardening Steps

WordPress gives website owners an enormous amount of flexibility. You can build a blog, business website, membership platform, online store, portfolio, or almost any other type of website without developing everything from scratch.

That flexibility also means WordPress websites must be maintained correctly.

Table of Contents

Installing WordPress and publishing content is not enough. A secure website requires regular updates, protected administrator accounts, reliable backups, sensible file permissions, secure hosting, and continuous monitoring.

The good news is that you do not need to be a cybersecurity expert to secure a WordPress website. Most security improvements come from following a consistent set of practical best practices.

In this guide, you will learn how to harden a new or existing WordPress website, reduce common security risks, protect sensitive information, and prepare a recovery plan in case something goes wrong.

Why WordPress Security Matters

WordPress itself is actively maintained, but every WordPress installation is different. Your website may include third-party themes, plugins, custom code, user accounts, payment integrations, forms, analytics scripts, and hosting configurations.

Every additional component can introduce potential security risks when it is:

Outdated
Poorly coded
Incorrectly configured
No longer maintained
Installed from an untrusted source
Given more access than it requires

A compromised website can lead to more than temporary downtime. It may result in stolen customer data, modified website content, spam pages, malicious redirects, damaged search rankings, blocked email delivery, or suspension by your hosting provider.

Security should therefore be treated as an ongoing maintenance process rather than a one-time setup task.

The goal is not to make your website mathematically impossible to compromise. No website can guarantee that. The goal is to reduce the attack surface, detect suspicious activity early, and ensure that you can recover quickly.

1. Keep WordPress Core, Plugins, and Themes Updated

Outdated software is one of the most avoidable WordPress security risks.

WordPress websites usually contain three primary types of software:

WordPress core
Plugins
Themes

Developers release updates to add features, fix bugs, improve compatibility, and patch security vulnerabilities. Delaying updates may leave your website exposed to problems that have already been publicly documented and fixed.

How to update WordPress safely

Before installing significant updates:

Create a complete backup of the website.
Review the plugin or theme changelog.
Check compatibility with your current WordPress and PHP versions.
Test the update on a staging website when possible.
Install the update.
Clear server, plugin, CDN, and browser caches.
Test important website functions.

Your post-update checks should include:

Homepage and navigation
Contact forms
Login and registration
Checkout and payment processing
Search functionality
Mobile layouts
Custom templates
Scheduled tasks
Email notifications

Small security updates can often be applied automatically, but major releases should be tested more carefully.

Remove unused software

Deactivating a plugin does not remove its files from the server. If an inactive plugin contains vulnerable code, those files may still create unnecessary risk.

Delete:

Inactive plugins you no longer need
Unused themes
Old theme copies
Abandoned plugins
Duplicate plugins with overlapping features
Testing tools left on the production website

Keep one default WordPress theme available for troubleshooting, but remove other unused themes.

A smaller software footprint is easier to maintain, faster to audit, and less likely to contain forgotten vulnerabilities.

2. Use Strong Passwords and Unique Login Credentials

Weak or reused passwords remain a common account security problem.

A strong password should be:

Long
Unique
Randomly generated
Unrelated to personal information
Stored in a reputable password manager

Avoid passwords based on:

Company names
Website domains
Birthdays
Common keyboard patterns
Names of family members
Repeated passwords from other services

The password for your WordPress administrator account should not be reused for your hosting account, domain registrar, database, email account, or CDN.

If one service is compromised, unique passwords prevent the attacker from using the same credentials across your entire website infrastructure.

Protect every important account

Securing WordPress alone is not sufficient. Review credentials for:

WordPress administrator accounts
Hosting control panel
Domain registrar
SFTP or SSH
Database administration
Transactional email service
CDN or web application firewall
Cloud backup service
Analytics and tag management platforms

Your website can still be compromised if an attacker gains access to the hosting account or domain registrar, even when the WordPress password is strong.

3. Enable Two-Factor Authentication

Two-factor authentication adds a second verification step to the login process.

Instead of relying only on a username and password, the user must also provide a temporary code or confirm the login through another trusted method.

This is valuable because a stolen password alone may not be enough to access the account.

Two-factor authentication should be required for:

Administrators
Shop managers
Editors
Developers
Support personnel
Anyone with access to customer or payment information

An authenticator application is generally preferable to codes delivered through email because an attacker who controls the email account may also be able to reset the WordPress password.

Store recovery codes securely

Two-factor authentication systems usually provide emergency recovery codes. Store them somewhere separate from the website and primary device.

Suitable locations include:

An encrypted password manager
A secure offline document
A restricted company vault

Do not store recovery codes inside a publicly accessible cloud document or an unencrypted text file.

4. Protect the WordPress Login Page

The default WordPress login page is usually located at:

example.com/wp-login.php

Knowing this URL does not automatically make a website insecure. However, automated systems frequently target WordPress login pages with credential-stuffing and brute-force attempts.

You can reduce this risk through several layers of protection.

Limit repeated login attempts

A login protection system can temporarily block an IP address or introduce a delay after repeated failed attempts.

The configuration should be strict enough to stop automated attacks without repeatedly locking out legitimate users.

A reasonable setup may include:

A limited number of failed attempts
A temporary lockout period
Increasing lockout duration for repeated violations
Notifications for excessive failed logins
An allowlist for trusted office IP addresses when appropriate

Avoid permanent IP blocking as your only defense. Many attackers rotate addresses, while legitimate users may have dynamic IP addresses.

Add CAPTCHA selectively

CAPTCHA can help reduce automated login and registration attempts, but it should not be placed on every website interaction without reason.

Use it on high-risk forms such as:

Login
Registration
Password reset
Comment submission
High-volume contact forms

Test accessibility and mobile usability after enabling CAPTCHA.

Consider changing the login URL carefully

Changing the login URL may reduce low-quality automated traffic, but it is not a replacement for strong passwords, two-factor authentication, and rate limiting.

It may also interfere with:

Membership plugins
Mobile applications
Single sign-on systems
Security integrations
Custom login forms

Document the custom URL and confirm that authorized users can still access the website before logging out.

5. Apply the Principle of Least Privilege

Every WordPress user should receive only the permissions required to perform their role.

WordPress includes several standard user roles:

Subscriber
Contributor
Author
Editor
Administrator

An administrator can install plugins, change themes, modify settings, create users, and access sensitive parts of the website. Most content contributors do not need that level of access.

Review user accounts regularly

Check Users → All Users and look for:

Accounts belonging to former staff members
Test accounts
Duplicate accounts
Unexpected administrator users
Accounts that have not been used recently
Generic shared logins
Users with excessive permissions

Remove accounts that are no longer required. When deleting a user, WordPress allows you to assign their content to another account.

Avoid shared administrator accounts

Each administrator should have an individual account.

Individual accounts make it easier to:

Track changes
Revoke access
investigate suspicious activity
enforce two-factor authentication
identify who performed an action

A shared account such as admin@company makes accountability and auditing more difficult.

Do not use “admin” as the public identity

Using admin is not automatically a vulnerability, but predictable usernames make automated login attempts easier.

Choose a non-obvious login username and configure a separate public display name for posts and author archives.

6. Install SSL and Force HTTPS

HTTPS encrypts data transferred between the visitor’s browser and your website.

Without HTTPS, information submitted through login forms, checkout pages, contact forms, and account pages may be exposed during transmission.

Most established hosting providers offer SSL certificates. After installing the certificate, confirm that WordPress is configured to use HTTPS.

Go to:

Settings → General

Verify that both addresses begin with https://:

WordPress Address (URL)
Site Address (URL)

Force administrator access over SSL

WordPress can be instructed to require HTTPS for administrator and login pages.

Add the following line to wp-config.php above the comment that says to stop editing:

define( 'FORCE_SSL_ADMIN', true );

Before adding this setting, confirm that the SSL certificate is active and valid. Enabling it before HTTPS is working may make the administrator area inaccessible.

Fix mixed-content warnings

A mixed-content warning occurs when an HTTPS page loads assets through HTTP.

Common sources include:

Hardcoded image URLs
Theme files
Custom CSS
Page-builder content
External scripts
Old database values

After switching to HTTPS:

Update the WordPress URLs.
Replace old internal HTTP references.
Clear all caches.
Regenerate page-builder CSS when applicable.
Test important pages in a private browser window.
Review the browser developer console for blocked resources.

Back up the database before performing a global search and replace.

7. Create Reliable Off-Site Backups

Backups are part of security because prevention is never perfect.

A complete WordPress backup should include:

Database
Plugins
Themes
Uploads
Custom code
Configuration files
Server-specific files where required

The backup schedule should reflect how frequently your website changes.

For example:

A small brochure website may need daily or weekly backups.
An active blog may need daily backups.
A membership website may need backups several times per day.
A WooCommerce store may require near-real-time database protection.

Store backups off the website server

Do not rely exclusively on backups stored inside the same hosting account.

If the hosting account is compromised, corrupted, or suspended, locally stored backups may also become unavailable.

Use at least one independent destination, such as:

Cloud object storage
Remote SFTP storage
A dedicated backup provider
A separate hosting account
Encrypted offline storage

Test the restoration process

A backup is not useful until it has been successfully restored.

Schedule periodic restoration tests on a staging environment. Confirm that:

The database imports correctly.
Media files are present.
Administrator access works.
Permalinks function.
Forms submit properly.
Scheduled tasks run.
Store orders and customer data are intact.
Custom code loads without errors.

Document the restoration process so that it can be followed during an emergency.

8. Disable File Editing in the WordPress Dashboard

By default, authorized administrators may be able to edit theme and plugin files from the WordPress dashboard.

If an administrator account is compromised, the built-in editor can make it easier for an attacker to insert malicious PHP code.

Disable dashboard file editing by adding this line to wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

Place it above:

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

This setting does not prevent updates or file changes through SFTP, SSH, deployment tools, or the hosting file manager.

It only removes the built-in theme and plugin editor from the dashboard.

Consider disabling plugin installation for managed websites

For tightly controlled production environments, you can also prevent dashboard-based plugin and theme installation:

define( 'DISALLOW_FILE_MODS', true );

This is a much more restrictive setting. It disables updates and installations through the WordPress dashboard.

Use it only when updates are handled through a controlled deployment process, staging workflow, version control system, or hosting management platform.

Do not enable it on a website unless you understand how future updates will be installed.

9. Configure Secure File Permissions

File permissions determine which server users can read, write, or execute files.

Incorrect permissions may allow unauthorized modification of WordPress files. Permissions that are too restrictive may prevent uploads, updates, caching, or plugin functionality.

A common starting point is:

Directories: 755
Files: 644
wp-config.php: 600 or 640 when supported

These values are not universal. The correct configuration depends on the web server, hosting architecture, file ownership, and PHP execution model.

Never use 777 permissions as a permanent fix

Setting files or directories to 777 grants broad read, write, and execute access.

It is sometimes suggested as a quick solution for upload or update errors, but it creates unnecessary security risk.

When WordPress cannot write to a directory:

Check file ownership.
Verify the web server user.
Review the hosting provider’s recommended permissions.
Correct ownership or group access.
Apply the narrowest permission required.

Do not solve ownership problems by granting unrestricted access.

Protect `wp-config.php`

The wp-config.php file contains sensitive configuration details, including database credentials and authentication settings.

It should not be publicly downloadable or writable by unnecessary users.

Some hosting configurations allow wp-config.php to be placed one directory above the public WordPress installation. WordPress can detect it there in supported setups.

Confirm compatibility with your hosting environment before relocating it.

10. Use a Web Application Firewall

A web application firewall, commonly called a WAF, analyzes requests before they reach WordPress.

It can help filter traffic associated with:

Known exploit patterns
Malicious bots
Suspicious file uploads
Brute-force activity
Automated vulnerability scans
Abusive request rates
Common injection attempts

A firewall can operate at different levels.

DNS or cloud-based firewall

A cloud-based firewall receives traffic before forwarding approved requests to your hosting server.

Potential benefits include:

Reduced load on the origin server
Protection before traffic reaches WordPress
Distributed denial-of-service mitigation
Bot filtering
Geographic and rate-based rules

WordPress-level firewall

A plugin-based firewall runs within or near the WordPress application.

It may provide:

Login protection
File integrity monitoring
Malware scanning
Security notifications
WordPress-specific firewall rules

A plugin firewall can be useful, but it still consumes server resources. A cloud-level firewall can reject malicious requests earlier.

For stronger protection, use layered security rather than relying on a single tool.

11. Monitor File Changes and Administrator Activity

Many website compromises are not immediately visible.

An attacker may create a hidden administrator account, inject code into an existing plugin, add spam pages, modify scheduled tasks, or redirect selected visitors.

Monitoring helps you identify changes before they cause extensive damage.

Enable activity logging

A WordPress activity log can record actions such as:

User logins
Failed login attempts
Plugin installations
Plugin activation or deactivation
Theme changes
User creation
Role changes
Setting modifications
Content updates
File changes

Logs should be protected from unauthorized access and retained long enough to support investigation.

Monitor file integrity

File integrity monitoring compares current files with known or previous versions.

Unexpected modifications to these locations deserve investigation:

/wp-admin/
/wp-includes/
/wp-content/plugins/
/wp-content/themes/
/wp-content/uploads/

PHP files inside the uploads directory can be especially suspicious because normal media uploads generally do not require executable PHP.

However, not every file change is malicious. Legitimate updates, cache generation, optimization tools, and deployment systems can modify files.

Review the context before deleting anything.

Configure security notifications carefully

Too many low-priority alerts can cause important warnings to be ignored.

Prioritize notifications for:

New administrator accounts
Changes to administrator email addresses
Modified core files
Unexpected plugin installation
Repeated lockouts
Malware detections
Changes to DNS or SSL
Backup failures

12. Secure the Hosting Environment

WordPress security depends heavily on the server where it runs.

Choose hosting that provides:

Supported PHP versions
Automatic operating-system patching
Malware isolation
Secure account authentication
SFTP or SSH access
SSL management
Reliable backups
Server-level logging
Staging environments
Web application firewall options

Keep PHP updated

Unsupported PHP versions may no longer receive security patches.

Before changing PHP versions:

Create a backup.
Test the new version on staging.
Review theme and plugin compatibility.
Enable error logging.
Test forms, checkout, scheduled actions, and integrations.
Monitor the error log after deployment.

Do not display PHP errors publicly on a live website. Public error messages may reveal file paths, database details, or application structure.

Disable production debugging output

WordPress debugging can be useful during development, but errors should not be displayed publicly on a production website.

A safer production configuration is:

define( 'WP_DEBUG', false );

When temporary troubleshooting is required, log errors without showing them to visitors:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Remove or disable debugging after the issue has been resolved. Also protect or delete old debug logs because they may contain sensitive information.

Additional WordPress Hardening Measures

The previous twelve steps provide the foundation of a secure WordPress website. The following measures can add further protection when implemented correctly.

Disable XML-RPC when it is not required

XML-RPC supports remote communication with WordPress. Some external publishing tools, mobile applications, and integrations may require it.

When your website does not use these features, you can disable XML-RPC through a small custom plugin or MU plugin.

Create this file:

/wp-content/mu-plugins/site-security.php

Add:

<?php
/**
 * Plugin Name: Site Security Settings
 * Description: Applies website-specific WordPress security settings.
 */

defined( 'ABSPATH' ) || exit;

add_filter( 'xmlrpc_enabled', '__return_false' );

Create the mu-plugins directory if it does not already exist.

Test external integrations after adding the filter. Remove the code if it breaks a service that depends on XML-RPC.

Review the WordPress REST API carefully

The REST API is an important part of modern WordPress. The block editor, applications, plugins, and headless integrations may depend on it.

Do not disable the entire REST API without a specific reason.

Instead:

Require authentication for sensitive custom endpoints.
Validate and sanitize request parameters.
Use permission callbacks.
Avoid exposing private data.
Keep plugins that register endpoints updated.

Broadly disabling the API may cause more compatibility problems than security benefits.

Refresh WordPress security salts after a compromise

WordPress salts help secure authentication cookies.

They are stored in wp-config.php and look similar to:

define( 'AUTH_KEY',         'unique value' );
define( 'SECURE_AUTH_KEY',  'unique value' );
define( 'LOGGED_IN_KEY',    'unique value' );
define( 'NONCE_KEY',        'unique value' );
define( 'AUTH_SALT',        'unique value' );
define( 'SECURE_AUTH_SALT', 'unique value' );
define( 'LOGGED_IN_SALT',   'unique value' );
define( 'NONCE_SALT',       'unique value' );

Replacing the salts invalidates active login sessions and forces users to authenticate again.

This is useful after suspected account compromise or unauthorized access.

Do not publish or reuse your real salt values.

Common WordPress Security Mistakes

Security tools cannot compensate for poor maintenance. Avoid these common mistakes.

Installing multiple security plugins with overlapping features

Running several firewalls, login blockers, scanners, and activity monitors simultaneously can create:

Duplicate database tables
Conflicting rules
Slow requests
False positives
Repeated notifications
Login problems
Difficult troubleshooting

Choose a deliberate security stack. Each tool should have a specific purpose.

Downloading premium plugins or themes from unofficial sources

Modified or “nulled” software may contain:

Backdoors
Hidden administrator creation
Malicious JavaScript
Spam injection
External tracking
Cryptocurrency mining code

Obtain software from the original developer, an official marketplace, or the WordPress plugin and theme directories.

Relying only on a security plugin

A security plugin cannot protect a website when:

The hosting account is compromised
The domain registrar is breached
Administrator passwords are reused
Backups do not work
Plugins remain outdated
Developers introduce insecure custom code
Server permissions are incorrect

WordPress security requires multiple layers.

Hiding the WordPress version and assuming the website is secure

Removing version information may reduce minor information disclosure, but it does not fix vulnerable software.

Attackers can often identify WordPress through public files, asset paths, markup patterns, and behavior.

Updating the software is more important than hiding the version number.

Changing the database prefix as the main defense

Changing the default database prefix may block poorly written automated attacks, but it does not prevent SQL injection.

Secure code must use:

Prepared database queries
Sanitized input
Validated data
Escaped output
Appropriate user permissions

Treat a custom prefix as a minor configuration choice, not a primary security control.

What to Do If Your WordPress Website Is Hacked

If you suspect a compromise, act methodically.

1. Restrict access

Consider placing the website in maintenance mode, blocking suspicious traffic, or temporarily restricting public access.

For an online store or membership platform, coordinate carefully to avoid losing new transactions or user data.

2. Preserve evidence

Before deleting files, collect:

Access logs
Error logs
Security alerts
Modified-file lists
Suspicious user details
Recent backup information
Timestamps

This information may help identify the entry point.

3. Create a backup of the compromised state

Although it may sound counterintuitive, preserve a copy for investigation.

Do not overwrite your most recent clean backup with the compromised version.

4. Reset credentials

Change passwords for:

WordPress users
Hosting accounts
SFTP and SSH
Database users
Domain registrar
Email accounts
CDN and firewall
External integrations

Replace WordPress salts to invalidate existing sessions.

5. Remove unauthorized users and files

Check for:

Unknown administrators
Modified core files
Unrecognized plugins
Suspicious PHP files in uploads
Unexpected scheduled tasks
Modified .htaccess rules
Database-injected scripts
Spam posts and pages

Do not delete files blindly. Compare them with clean copies and confirm their purpose.

6. Reinstall clean software

Replace WordPress core, plugins, and themes with clean copies from trusted sources.

Do not simply restore visible pages while leaving the original vulnerability unresolved.

7. Identify the entry point

Investigate whether the compromise came from:

An outdated plugin
A vulnerable theme
Stolen credentials
Insecure custom code
A compromised hosting account
Incorrect file permissions
Malware on an administrator’s computer

Without fixing the entry point, the website may be compromised again.

8. Monitor the website after recovery

Watch logs, user accounts, files, outgoing email, search indexing, and security alerts closely after cleanup.

WordPress Security Checklist

Use this checklist during launch and routine maintenance:

WordPress core is updated.
Plugins and themes are updated.
Unused plugins and themes are deleted.
Administrator passwords are unique.
Two-factor authentication is enabled.
User roles follow least privilege.
Old user accounts are removed.
SSL is active.
All traffic uses HTTPS.
Backups run automatically.
Backups are stored off-site.
A restoration test has been completed.
Dashboard file editing is disabled.
File ownership and permissions are correct.
The login page has rate limiting.
A firewall is active.
Security activity is logged.
File integrity is monitored.
PHP is supported and current.
Production errors are not publicly displayed.
Hosting, domain, and email accounts are protected.
A documented recovery plan exists.

Review this checklist at least quarterly and after major website changes.

Frequently Asked Questions

Is WordPress secure?

WordPress can be secure when it is properly maintained and configured. Many compromises involve outdated extensions, weak credentials, insecure hosting, excessive user permissions, or vulnerable custom code rather than the current WordPress core installation.

Do I need a WordPress security plugin?

A security plugin can provide useful features such as login protection, malware scanning, activity logging, and file monitoring. However, it should complement strong passwords, updates, backups, secure hosting, and proper user permissions rather than replace them.

How often should I back up my WordPress website?

The schedule should match how frequently the website changes. A static website may require daily or weekly backups, while an active store, membership platform, or publication may require multiple backups per day.

Should I hide the WordPress login URL?

Changing the login URL can reduce basic automated traffic, but it is not a complete security measure. Strong passwords, two-factor authentication, rate limiting, and monitoring provide more meaningful protection.

Should I disable XML-RPC?

Disable XML-RPC only when your website and connected services do not require it. Some mobile applications, remote publishing tools, and integrations depend on XML-RPC.

What file permissions should WordPress use?

A common starting point is 755 for directories and 644 for files. The correct permissions depend on the server configuration and file ownership. Follow your hosting provider’s requirements and never use 777 as a permanent fix.

Can a hacked WordPress site be recovered?

In many cases, yes. Successful recovery requires clean backups, careful malware removal, credential resets, replacement of compromised files, and identification of the original entry point.

Final Thoughts

Learning how to secure a WordPress website is not about applying one plugin or changing one setting. Effective security comes from multiple layers working together.

Keep WordPress and its extensions updated. Protect every privileged account with unique passwords and two-factor authentication. Remove unnecessary software and user accounts. Store reliable backups outside the hosting environment. Configure file permissions correctly, use HTTPS, monitor important changes, and maintain a documented recovery process.

Security also needs to evolve with the website. A simple blog, WooCommerce store, membership platform, and business website have different risks and maintenance requirements.

Review your security configuration regularly, especially when installing a new plugin, changing hosting providers, adding team members, introducing customer accounts, or connecting an external service.

A well-maintained WordPress website is easier to protect, faster to troubleshoot, and far easier to recover when an unexpected problem occurs.