WordPress Security Hardening Checklist for 2026

TL;DR: WordPress Security Hardening Checklist

To secure WordPress in 2026, use strong hosting, keep WordPress core, plugins, and themes updated, remove unused plugins and themes, enable two-factor authentication for admins, use strong unique passwords, limit administrator accounts, disable dashboard file editing, set correct file permissions, protect wp-config.php, use backups with restore testing, add a firewall, secure login and XML-RPC access, monitor logs, use HTTPS, review REST API and Application Password access, add security headers carefully, and prepare an incident recovery plan before you need it.

1. Start With Secure WordPress Hosting

WordPress security starts at the hosting layer. A weak server can undermine even a well-managed WordPress site. Your host should keep server software updated, isolate accounts properly, provide reliable backups, support modern PHP versions, offer malware scanning or incident support, and make recovery possible.

Hosting security checklist:

• Use a trusted hosting provider, not the cheapest unknown server.
• Run a supported PHP version.
• Use HTTPS with a valid SSL certificate.
• Enable server-level firewall protection if available.
• Use account isolation on shared hosting.
• Use SSH keys instead of password-only SSH access where possible.
• Disable unused services and ports on VPS servers.
• Keep server packages updated.
• Use backups or snapshots outside the same server.
• Ask your host how malware cleanup and restore support works.

If you manage your own VPS, you are responsible for server updates, firewall rules, SSH hardening, malware monitoring, backups, and incident response. If you do not want that responsibility, use managed WordPress hosting or managed VPS support.

2. Keep WordPress Core Updated

Outdated WordPress core versions increase risk, especially when security fixes become public. Keep WordPress updated, but update major versions with a proper process: backup, staging, compatibility test, production update, and post-update review.

Core update checklist:

• Keep minor/security updates enabled where appropriate.
• Test major WordPress releases on staging first.
• Check plugin and theme compatibility before major updates.
• Back up files and database before updating.
• Run database updates when WordPress asks.
• Test login, editor, forms, checkout, search, and key pages after updating.
• Monitor error logs after the update.

Do not stay on old WordPress versions because “the site still works.” Working is not the same as secure.

3. Audit Plugins and Themes

Plugins and themes are one of the biggest WordPress attack surfaces. Every installed plugin adds code, dependencies, settings, permissions, and possible vulnerabilities. You should treat plugin selection as a security decision, not only a feature decision.

Plugin and theme checklist:

• Remove plugins you do not use.
• Remove inactive themes except one clean default fallback theme.
• Avoid nulled, cracked, or unofficial premium plugins and themes.
• Check update history before installing new plugins.
• Prefer plugins from trusted developers or the WordPress.org repository.
• Avoid plugins that duplicate the same function.
• Replace abandoned plugins when possible.
• Review plugins that handle forms, payments, users, uploads, API access, or redirects.
• Test plugin updates on staging for business-critical sites.

High-risk plugin categories:

• File upload plugins.
• Form plugins.
• Membership and LMS plugins.
• WooCommerce extensions.
• Page builders and builder addons.
• Backup and migration plugins.
• Security plugins with firewall or login control.
• Custom code snippet plugins.
• REST API or automation plugins.

Security hardening does not mean installing ten security plugins. It means reducing unnecessary code and keeping essential code maintained.

4. Use Strong Passwords and Two-Factor Authentication

Weak login security is still one of the easiest ways to compromise a WordPress site. Use strong unique passwords and enable two-factor authentication for administrators, editors, store managers, and any user with access to sensitive data.

Login security checklist:

• Use long, unique passwords for every user account.
• Never reuse hosting, email, database, and WordPress passwords.
• Enable two-factor authentication for administrator accounts.
• Use a password manager.
• Remove old staff, freelancer, and agency accounts.
• Do not share one admin login across a team.
• Review accounts after employee, developer, or agency changes.
• Use temporary accounts for support access and delete them afterward.

MFA is especially important for accounts that can install plugins, edit code, change payment settings, export user data, or access WooCommerce orders.

5. Limit Administrator Accounts

Every administrator account is a high-value target. If a user only writes content, they should not be an administrator. If a store manager only manages orders, they should not control plugins and themes.

User role checklist:

• Use Administrator only for users who truly need full control.
• Use Editor for content managers.
• Use Author or Contributor for writers where appropriate.
• Use Shop Manager carefully on WooCommerce stores.
• Remove inactive accounts.
• Audit user roles monthly on business-critical sites.
• Do not give plugin/theme installation access to normal editors.
• Use role editor plugins carefully and document changes.

Least privilege is simple: give users only the access they need to do their job.

6. Change the Default “admin” Username If Still Used

A username alone is not a security layer, but using predictable admin usernames makes brute-force attempts easier. If your site still has a main administrator named admin, create a new administrator account with a unique username, log in with it, and remove or downgrade the old account.

Safe process:

1. Create a new administrator user with a unique username.
2. Use a strong password and enable two-factor authentication.
3. Log out and log back in with the new user.
4. Delete the old admin user.
5. Reassign content to the new user or a safe editorial account.

Do not rename users directly in the database unless you understand the risks.

7. Protect the WordPress Login Page

The login page is a common target for bots and credential attacks. You do not need to hide it as your only defense, but you should reduce abuse.

Login protection checklist:

• Enable two-factor authentication.
• Limit login attempts or use a firewall that blocks brute-force attempts.
• Add CAPTCHA or challenge only when needed.
• Use rate limiting at the firewall, CDN, or security plugin level.
• Block obvious bot traffic patterns.
• Monitor failed login attempts.
• Use strong passwords for all users.
• Protect password reset workflows.

Changing the login URL can reduce noise, but it is not a replacement for strong passwords, MFA, firewall protection, and user audits.

8. Disable File Editing in the WordPress Dashboard

WordPress can allow administrators to edit plugin and theme files from the dashboard. If an attacker gets access to an administrator account, this can become a direct path to code execution.

Add this line to wp-config.php above the final stop-editing comment:

define( 'DISALLOW_FILE_EDIT', true );

Why this helps:

• Prevents editing plugin files from the dashboard.
• Prevents editing theme files from the dashboard.
• Reduces damage if an admin account is compromised.
• Encourages proper deployment through SFTP, Git, or hosting tools.

FyrePress tool: Use the FyrePress wp-config.php Builder to generate reviewable configuration constants before editing your live file.

9. Use Correct File and Folder Permissions

Bad file permissions can allow unauthorized users, scripts, or compromised processes to modify files they should not control. WordPress permissions vary by server setup, but common safe defaults are usually stricter than what many beginners use.

Common baseline permissions:

• Directories: 755
• Files: 644
• wp-config.php: often 600 or 640, depending on host setup

Shell examples:

# Directories
find /path/to/wordpress/ -type d -exec chmod 755 {} \;

# Files
find /path/to/wordpress/ -type f -exec chmod 644 {} \;

Avoid:

• Setting folders to 777.
• Making plugin/theme directories globally writable.
• Giving the web server write access to files that do not need it.
• Changing permissions randomly to “fix” upload problems.

If uploads fail, ask your host to check file ownership and PHP user configuration before weakening permissions.

10. Protect wp-config.php

The wp-config.php file contains database credentials, authentication keys, salts, debug settings, and other sensitive constants. Treat it as one of the most important files on the site.

wp-config.php checklist:

• Set strict file permissions.
• Never expose it in backups or public directories.
• Do not share it in support tickets without removing secrets.
• Use strong database credentials.
• Disable file editing.
• Turn off debug display on production.
• Use fresh authentication keys and salts after a compromise.

Apache rule to deny direct access:

<Files "wp-config.php">
    Require all denied
</Files>

On Nginx, use server-level rules instead of .htaccess.

11. Regenerate WordPress Security Keys and Salts When Needed

WordPress security keys and salts help protect authentication cookies and logged-in sessions. You should regenerate them after a suspected compromise, admin account leak, migration from an untrusted environment, or major security cleanup.

wp-config.php keys look like this:

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

Use the official WordPress secret-key generator: WordPress.org Secret Key Service.

Important: changing salts logs out all users. That is expected.

12. Secure the Database

The WordPress database stores posts, users, options, WooCommerce orders, plugin settings, sessions, forms, and sensitive configuration data. Database security matters as much as file security.

Database hardening checklist:

• Use a strong database username and password.
• Give the database user only the permissions it needs.
• Do not reuse database credentials across multiple sites.
• Use separate databases or users for separate WordPress installations.
• Restrict remote database access unless required.
• Back up the database regularly.
• Protect database backups from public access.
• Do not store SQL dumps inside publicly accessible directories.
• Remove old migration files after use.

Changing the table prefix alone is not strong security, but using separate databases and unique credentials helps containment if one site is compromised.

13. Use Backups That Actually Restore

A backup is only useful if you can restore it. Many site owners discover too late that their backup is incomplete, corrupted, stored on the same hacked server, or missing the database.

Backup checklist:

• Back up both files and database.
• Store backups off-server.
• Keep multiple restore points.
• Encrypt sensitive backups where possible.
• Test restore procedures regularly.
• Do not keep backups inside public web folders.
• Use more frequent backups for WooCommerce, LMS, and membership sites.
• Document how to restore the site quickly.

Recommended backup frequency:

14. Add a Web Application Firewall

A web application firewall can block many common attacks before they reach WordPress. It can help reduce brute-force attempts, malicious payloads, exploit scanning, bad bots, suspicious query strings, and known plugin vulnerability probes.

Firewall options:

• Cloud-based WAF through a CDN or security provider.
• Server-level WAF such as ModSecurity.
• WordPress security plugin firewall.
• Hosting-managed firewall rules.

Firewall checklist:

• Enable protection for known WordPress attack patterns.
• Rate-limit login attempts.
• Block malicious user agents and obvious bot patterns.
• Protect XML-RPC if not needed.
• Exclude legitimate admin, checkout, and API workflows carefully.
• Review firewall logs instead of blindly blocking everything.

A firewall reduces risk, but it does not replace updates, backups, strong passwords, or clean plugin management.

15. Secure XML-RPC

XML-RPC can be used by some mobile apps, Jetpack-style integrations, legacy tools, and remote publishing workflows. It can also be abused for brute-force and amplification-style attacks if left open unnecessarily.

XML-RPC checklist:

• Disable XML-RPC if your site does not need it.
• Restrict access to known IPs if only one service needs it.
• Block abusive XML-RPC requests through WAF or server rules.
• Test Jetpack, mobile apps, or integrations before disabling it.
• Monitor logs for repeated xmlrpc.php requests.

Apache example to block XML-RPC:

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

Do not disable XML-RPC blindly on sites that depend on it. Confirm your integrations first.

16. Review REST API and Application Password Access

The WordPress REST API powers modern WordPress functionality and integrations. You should not block it blindly, because that can break the block editor, apps, plugins, and external workflows. Instead, review what is exposed and protect sensitive endpoints.

REST API checklist:

• Do not expose private data through custom endpoints.
• Use proper permission_callback in custom REST routes.
• Require authentication for write actions.
• Validate and sanitize all request data.
• Do not return API keys, tokens, server paths, logs, or private settings.
• Rate-limit expensive endpoints where needed.
• Monitor unusual API traffic.

Application Password checklist:

• Use Application Passwords only for integrations that need them.
• Create one Application Password per integration.
• Revoke unused Application Passwords.
• Do not expose Application Passwords in frontend JavaScript.
• Use HTTPS.
• Review which users are allowed to create API credentials.

WordPress Application Passwords are tied to a user account, shown only once, stored hashed, and individually revocable, which makes them useful for controlled integrations when handled properly.

17. Harden Uploads and File Types

Upload features are sensitive because they allow users or admins to place files on the server. Poorly controlled uploads can create malware, phishing pages, defacement, or remote code execution risks.

Upload security checklist:

• Allow only file types your site actually needs.
• Do not allow executable files through normal upload forms.
• Restrict uploads for untrusted users.
• Use file scanning if your site accepts public uploads.
• Store user uploads outside executable paths where possible.
• Block PHP execution inside uploads directories.
• Review form plugins that accept attachments.
• Limit file size to reduce abuse.

Apache example to block PHP execution in uploads:

<Directory "/path/to/wordpress/wp-content/uploads">
    <FilesMatch "\.php$">
        Require all denied
    </FilesMatch>
</Directory>

Your exact rule depends on hosting and server configuration. Ask your host before adding directory rules you do not understand.

18. Use HTTPS Everywhere

HTTPS protects traffic between visitors and your website. It is essential for logins, admin pages, checkout, forms, membership sites, API requests, and any page that handles personal data.

HTTPS checklist:

• Install a valid SSL certificate.
• Redirect HTTP to HTTPS.
• Update WordPress Address and Site Address to HTTPS.
• Fix mixed content warnings.
• Use secure cookies where supported.
• Use HTTPS for REST API and Application Password integrations.
• Consider HSTS only after confirming HTTPS is fully working.

wp-config.php SSL admin rule:

define( 'FORCE_SSL_ADMIN', true );

Be careful with HSTS. If configured incorrectly, it can lock users into HTTPS before your SSL setup is ready.

19. Add Security Headers Carefully

Security headers can help browsers enforce safer behavior, but bad header configuration can break scripts, fonts, embeds, analytics, checkout, and admin workflows. Add them carefully and test the whole site.

Common useful headers:

• Strict-Transport-Security
• X-Frame-Options or CSP frame rules
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy
• Content-Security-Policy

Beginner-safe Apache examples:

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>

Be careful with CSP

Content Security Policy is powerful, but it can break inline scripts, analytics, payment widgets, page builders, ads, fonts, embeds, and WordPress admin screens if you apply it without testing.

FyrePress tool: For Apache/LiteSpeed security rule examples, use the FyrePress .htaccess Security Builder.

20. Hide or Protect Sensitive Files

Sensitive files should not be publicly accessible. Some files reveal configuration, versions, plugin details, backups, database dumps, or deployment information.

Check for exposed files:

• wp-config.php
• .env
• debug.log
• backup.zip
• database.sql
• old-site.zip
• phpinfo.php
• composer.json and composer.lock where sensitive
• .git/ directories

Remove old migration archives and database exports immediately after use. Many compromises start with files left behind after development or migration.

21. Turn Off Public Debug Display

Debug output can expose server paths, plugin names, database errors, API responses, or sensitive stack details. Use private logging instead of displaying errors to visitors.

Production-safe debug settings:

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

Temporary private debug logging:

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

If you enable debug logging temporarily, review and remove the log file after troubleshooting if it contains sensitive information.

FyrePress tool: Use the FyrePress Server Log Analyzer to review log excerpts for security, PHP, plugin, or server issues.

22. Monitor Logs and Suspicious Activity

Monitoring helps you detect problems before they become full incidents. Logs can show brute-force attempts, exploit probes, suspicious uploads, REST API abuse, XML-RPC attacks, file changes, and plugin errors.

Monitor these logs:

• Web server access logs.
• Web server error logs.
• PHP error logs.
• WordPress debug logs.
• Security plugin logs.
• Firewall/CDN logs.
• WooCommerce logs for stores.
• Hosting account login logs if available.

Watch for:

• Repeated failed logins.
• Requests to old plugin vulnerability paths.
• Requests to xmlrpc.php at high volume.
• Unknown PHP files in uploads.
• Suspicious admin user creation.
• Unexpected plugin/theme file changes.
• Unusual REST API traffic.
• Unexpected redirects or injected scripts.

23. Use Malware Scanning and File Integrity Checks

Malware can hide in plugins, themes, uploads, mu-plugins, cache folders, or modified core files. File integrity checks compare known WordPress core files against expected versions and can help identify suspicious changes.

Scanning checklist:

• Scan core files for modifications.
• Scan plugins and themes for suspicious code.
• Check uploads for PHP files.
• Review recently modified files.
• Check unknown admin users.
• Check suspicious cron jobs.
• Check hidden files and unusual directories.
• Check injected JavaScript in posts, widgets, and theme options.

Do not rely only on one scanner. If a business-critical site is compromised, combine scanner results with logs, file review, database inspection, and clean restoration.

24. Secure WooCommerce Sites More Strictly

WooCommerce sites need stronger controls because they handle customers, orders, addresses, payment workflows, account pages, emails, subscriptions, and integrations.

WooCommerce hardening checklist:

• Use HTTPS everywhere.
• Enable MFA for admins and shop managers.
• Keep payment plugins updated.
• Use only trusted payment gateways.
• Protect checkout, cart, and account pages from bad cache rules.
• Review user roles and shop manager access.
• Back up the database frequently.
• Monitor failed orders and payment errors.
• Secure webhooks and API keys.
• Do not expose order/customer data through custom REST endpoints.
• Review abandoned cart, invoice, shipping, and tax plugins carefully.

For WooCommerce, a database restore can remove recent orders. Use careful incident planning and frequent backups.

25. Harden WordPress for Agencies and Client Sites

Agencies need repeatable security processes. Every client site should not have a different ad-hoc setup.

Agency checklist:

• Create a standard security baseline for all client sites.
• Use unique admin accounts per team member.
• Remove developer accounts after handoff.
• Use password managers and MFA.
• Document hosting, DNS, backup, and restore access.
• Use staging for major updates.
• Run scheduled plugin/theme audits.
• Keep client plugin stacks lean.
• Monitor uptime and security alerts.
• Prepare an incident response template.

The best agency security system is boring, documented, and repeatable.

26. Incident Response: What to Do If WordPress Is Hacked

A hardening checklist is incomplete without recovery planning. If a site is compromised, do not randomly delete files or restore blindly before understanding the scope.

Emergency response checklist:

1. Take the site offline or restrict access if active damage is happening.
2. Change hosting, WordPress admin, SFTP/SSH, database, and email passwords.
3. Revoke unknown Application Passwords and API keys.
4. Export logs before they rotate or disappear.
5. Identify the entry point if possible.
6. Scan files and database for malware or injected content.
7. Remove unknown admin users.
8. Replace WordPress core with a clean copy.
9. Replace plugins and themes from trusted sources.
10. Restore from a known clean backup if needed.
11. Update everything after cleanup.
12. Regenerate salts and log out all users.
13. Submit reconsideration or cleanup requests if search engines flagged the site.
14. Document what happened and what changed.

If you cannot identify the entry point, the site may be reinfected. Cleanup without root-cause analysis is often temporary.

WordPress Security Checklist by Priority

Critical fixes

• Update WordPress core, plugins, and themes.
• Remove nulled or abandoned plugins/themes.
• Enable MFA for admin users.
• Use strong unique passwords.
• Set up off-server backups and test restore.
• Disable dashboard file editing.
• Use HTTPS everywhere.
• Fix public debug output.
• Remove unknown admin users.

Important hardening

• Set correct file permissions.
• Protect wp-config.php.
• Secure XML-RPC if not needed.
• Review Application Passwords.
• Add firewall/rate limiting.
• Monitor logs.
• Block PHP execution in uploads where possible.
• Use least-privilege user roles.

Advanced hardening

• Add security headers after testing.
• Use server-level WAF rules.
• Restrict admin access by IP where practical.
• Use Git/deployment workflows instead of dashboard editing.
• Use malware scanning and file integrity monitoring.
• Separate high-value sites into separate hosting accounts or servers.
• Use centralized monitoring for agency sites.

Best Security Setup by Website Type

For small blogs

Keep WordPress and plugins updated, use strong passwords, enable MFA for admins, remove unused plugins, use a trusted host, and keep off-server backups.

For business websites

Add login protection, firewall rules, form spam protection, tested backups, uptime monitoring, role audits, and careful plugin management.

For WooCommerce stores

Use stricter controls: MFA for admins/shop managers, frequent database backups, payment plugin audits, secure webhooks, strong hosting, malware monitoring, and careful restore planning.

For membership and LMS sites

Protect user data, login flows, payments, course progress, private content, and API access. Use frequent backups and audit roles regularly.

For agencies

Use a repeatable baseline across all client sites: MFA, backups, updates, plugin audits, staging, monitoring, incident response, and documented access control.

For developers

Use version control, staging, least privilege, secure custom REST endpoints, nonce/capability checks, server-level hardening, dependency audits, and deployment workflows.

Common WordPress Security Mistakes

• Installing too many security plugins instead of fixing basics.
• Using nulled themes or plugins.
• Leaving old admin accounts active.
• Using weak or reused passwords.
• Not testing backups.
• Keeping database backups in public folders.
• Leaving debug display enabled.
• Giving every team member administrator access.
• Ignoring XML-RPC and REST API abuse.
• Using 777 permissions to fix upload problems.
• Not updating abandoned plugins.
• Restoring hacked sites without finding the entry point.

Final Recommendation

The strongest WordPress security setup in 2026 is not complicated. Keep the software updated, use trusted plugins and themes, protect logins with MFA, limit administrator access, disable dashboard file editing, use correct permissions, protect sensitive files, monitor logs, and keep tested off-server backups.

For business-critical websites, add stronger controls: staging updates, firewall rules, malware scanning, frequent database backups, secure API credential management, and an incident response plan.

Security is a process, not a one-time plugin installation. The safest WordPress sites are maintained regularly, monitored properly, and built with recovery in mind.

Frequently Asked Questions

How do I harden WordPress in 2026?

Harden WordPress by keeping core, plugins, and themes updated, enabling MFA, using strong passwords, limiting admin accounts, disabling file editing, setting correct permissions, protecting wp-config.php, using HTTPS, adding backups, monitoring logs, and using a firewall.

What is the most important WordPress security step?

The most important step is keeping WordPress core, plugins, and themes updated while using trusted software only. Most WordPress compromises involve outdated, vulnerable, abandoned, or untrusted plugins and themes.

Should I use a WordPress security plugin?

A security plugin can help with firewall rules, login protection, malware scanning, and monitoring, but it cannot replace updates, strong passwords, backups, safe hosting, and good user management.

Should I disable XML-RPC in WordPress?

Disable or restrict XML-RPC if your site does not use it. However, test first because some mobile apps, Jetpack-style services, and remote publishing tools may depend on XML-RPC.

Should I disable the WordPress REST API?

Do not disable the REST API blindly because it powers the block editor, plugins, integrations, and apps. Instead, protect sensitive endpoints, use authentication, and secure custom routes with permission callbacks.

What file permissions should WordPress use?

Common WordPress permissions are 755 for directories and 644 for files. The wp-config.php file may use stricter permissions such as 600 or 640 depending on the hosting environment.

How often should I back up WordPress?

Small sites may use daily or weekly backups, while WooCommerce, membership, LMS, and high-change sites need more frequent database backups. Always store backups off-server and test restoration.

Is changing the WordPress login URL enough?

No. Changing the login URL may reduce bot noise, but it is not enough. Use MFA, strong passwords, limited login attempts, firewall rules, and user role audits.

How do I secure wp-config.php?

Secure wp-config.php by setting strict permissions, denying direct web access where possible, keeping it out of public backups, disabling file editing, and never sharing it without removing database credentials and salts.

What should I do if my WordPress site is hacked?

Restrict access, change all credentials, revoke API keys, preserve logs, identify the entry point, scan files and database, remove unknown users, replace compromised files, restore from a clean backup if needed, update everything, and regenerate salts.