WordPress Security Checklist (2026)

This WordPress security checklist is a practical guide to securing a WordPress website on shared or managed hosting. Work through it top to bottom on a new site, or use it to audit the one you already run. Items marked ★ stop most real-world compromises. We built it from the checks we run on our own site every week.

Why plugins come first: in Patchstack’s State of WordPress Security in 2026 report, 91% of the 11,334 new WordPress vulnerabilities found in 2025 were in plugins and 9% in themes; WordPress core had only 6, all low priority. 46% had no fix from the developer when they were made public, and about half of the high-impact ones were attacked within 24 hours.

Want a quick outside view first? Run our free website safety check and email security checker. They grade the HTTPS, header and email items below in seconds.

1. Before you start

  • Take a full backup (files and database) and confirm you can restore it
  • Write down what you run: WordPress version, PHP version (Tools → Site Health → Info), active plugins and theme
  • List every user with the Administrator role and confirm you know each one
  • If your host offers a staging copy, test big changes there first

2. Updates ★

  • Run the latest WordPress release. In October 2026 that is 7.1.3, and WordPress.org says only the latest release in the 7.1 series is safe to use
  • Keep automatic minor and security updates on (the default). To allow major updates as well, use Dashboard → Updates or define( 'WP_AUTO_UPDATE_CORE', true ); in wp-config.php
  • Turn on auto-updates for well-maintained plugins and themes (Plugins → Enable auto-updates) and check Dashboard → Updates every week
  • Use PHP 8.3 or newer, as WordPress recommends. PHP 8.2 stops getting security fixes on 31 December 2026, and 8.1 and older are already end-of-life. Your host’s control panel usually has a PHP version switch
  • Never set AUTOMATIC_UPDATER_DISABLED to true just to stop update e-mails

3. Plugins and themes ★

  • Delete plugins and themes you don’t use. Deactivated code can still be attacked if its files are reachable
  • Keep one default theme as a fallback, and delete the rest
  • Before you install a plugin, check when it was last updated, how many sites use it and whether it was closed on WordPress.org
  • Buy premium plugins and themes only from the developer. “Nulled” copies often contain backdoors
  • Sign up for vulnerability alerts for your plugins (Patchstack, Wordfence Intelligence or WPScan). When an alert says “no fix yet”, deactivate the plugin or block it with your firewall until a fix ships
  • Each year, ask of every plugin: do we still need it, and does something we already run do the same job?

4. Logins and user accounts ★

  • No account called admin; every person has their own named account
  • Use long, unique passwords from a password manager
  • Turn on two-factor authentication (2FA) for every Administrator and Editor. WordPress has no built-in 2FA, so use a plugin such as the official Two Factor plugin or your security plugin
  • Give people the lowest role they need: writers are Authors or Contributors, not Administrators. Remove accounts of people who have left
  • Review Users → Profile → Application Passwords for each admin and revoke any you don’t recognise. They give API access and can be used without 2FA
  • Limit login attempts at your host, CDN or firewall. Moving the login page (for example with WPS Hide Login) cuts bot noise, but it is not a defence on its own
  • XML-RPC: if nothing uses it, disable it. If Jetpack or a mobile app needs it, keep it on but block the system.multicall and pingback methods (one multicall request can test hundreds of passwords)
  • Usernames are public by design in WordPress (author archives and the REST API show them), so rely on strong passwords and 2FA rather than hiding usernames

5. Lock down wp-config.php ★

Add these lines above /* That’s all, stop editing! */ in wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );   // removes the theme/plugin code editor from wp-admin
define( 'FORCE_SSL_ADMIN', true );      // logins and wp-admin only over HTTPS
define( 'WP_DEBUG', false );            // no debug output on a live site
define( 'WP_DEBUG_DISPLAY', false );
  • If you need a debug log, write it outside the website folder, for example define( 'WP_DEBUG_LOG', '/home/USER/logs/wp-errors.log' );. The default wp-content/debug.log can be downloaded by anyone
  • Set wp-config.php permissions to 440 or 400 (600 if your host requires it). Folders 755, files 644. Never 777
  • Regenerate the security keys (salts) after an incident or when an admin leaves: paste new ones from api.wordpress.org/secret-key/1.1/salt/ or run wp config shuffle-salts. Everyone has to log in again
  • DISALLOW_FILE_MODS also blocks plugin installs and updates from wp-admin. Use it only if updates come from your host, WP-CLI or a deployment pipeline

6. No exposed files or backups ★

Open each of these in a private browser window. Every one should show “403 Forbidden” or “404 Not Found”, never a download or a page of text:

  • Backups of the config file: /wp-config.php.bak, .old, .save, .orig, /wp-config.php~
  • Logs: /wp-content/debug.log, /error_log
  • Developer leftovers: /.git/HEAD, /.env, /phpinfo.php, /info.php
  • Backup plugin folders: /wp-content/updraft/, /wp-content/ai1wm-backups/, Duplicator’s folder
  • Archives in the site root: .zip, .tar, .tar.gz, .sql files left by a migration or a previous host. These often contain the whole database
  • Folder listings: /wp-content/uploads/ should not show a list of files
  • Version giveaways: /readme.html, /license.txt

On Apache or LiteSpeed hosting, this block at the end of .htaccess (outside the # BEGIN WordPress section) blocks most of them. Test your site straight after adding it; if it shows a 500 error, remove the Options -Indexes line (some hosts don’t allow it):

# Block sensitive files
Options -Indexes
<FilesMatch "^(wp-config\.php|readme\.html|license\.txt|wp-config-sample\.php|error_log|phpinfo\.php|\.user\.ini)$">
Require all denied
</FilesMatch>
<FilesMatch "\.(log|sql|bak|old|orig|save|swp|env)$">
Require all denied
</FilesMatch>
<IfModule mod_rewrite.c>
RewriteEngine On
# archives in the site root only, so downloads in wp-content still work
RewriteRule ^[^/]+\.(zip|tar|tgz|gz|7z|rar)$ - [F,L]
RewriteRule ^\.git/ - [F,L]
</IfModule>

Keep backups out of the website folder altogether: store them off-site (see section 9) and delete old copies from public_html.

7. HTTPS and security headers

  • HTTPS on every page, with automatic certificate renewal. Let’s Encrypt is shortening certificate lifetimes (64 days from February 2027), so manual renewal will not keep up
  • Strict-Transport-Security: max-age=31536000; includeSubDomains (only add includeSubDomains once every subdomain works over HTTPS)
  • X-Content-Type-Options: nosniff
  • X-Frame-Options: SAMEORIGIN (or CSP frame-ancestors 'self') to stop clickjacking
  • Referrer-Policy: strict-origin-when-cross-origin
  • Permissions-Policy that turns off what you don’t use, for example camera=(), microphone=(), geolocation=()
  • Cross-Origin-Opener-Policy: same-origin-allow-popups. Plain same-origin can break payment and “Sign in with Google” pop-ups
  • Content-Security-Policy: start in Content-Security-Policy-Report-Only mode, fix what it reports, then enforce it
  • Don’t advertise versions: no X-Powered-By: PHP/… header and no WordPress or plugin version in <meta name="generator"> tags
  • Publish /.well-known/security.txt with a Contact: and an Expires: line (RFC 9116) so people can report problems to you

8. Firewall, scanning and file integrity

  • Use a web application firewall (WAF): at your host or CDN, or a plugin such as Wordfence. With Wordfence, switch the firewall to Extended Protection so it loads before WordPress and plugins
  • Schedule malware scans and check that they actually complete. A scan that never finishes protects nothing
  • Compare core and plugin files with the official copies: wp core verify-checksums and wp plugin verify-checksums --all (works for plugins from WordPress.org)
  • Look for unexpected admin users, unknown scheduled tasks and code snippets you didn’t add

9. Backups ★

  • Follow 3-2-1: three copies, on two kinds of storage, one off-site (for example cloud storage your web host can’t delete)
  • Back up the database daily on a busy site, weekly at least on a quiet one; keep at least 7 days of history
  • Encrypt backups that leave your host. They contain customer data and your database password
  • Test a restore every quarter, to a staging site if you have one. An untested backup is a guess

10. Email and domain

  • SPF, DKIM and DMARC for your domain, with DMARC at p=quarantine or p=reject once reports look clean. Check them with our email security checker
  • Send WordPress e-mail (password resets, orders) through an authenticated SMTP service, not plain PHP mail
  • Turn on the registrar lock and auto-renew for your domain, and put 2FA on the registrar, hosting and DNS accounts

11. Monitoring and incident response

  • Turn on login and change alerts in your security plugin, and an uptime monitor
  • Add the site to Google Search Console and check Security issues and Manual actions monthly
  • Write a one-page plan for a hack: who to call, how to take the site offline, where the clean backup is
  • After an incident: restore a clean backup, update everything, change all passwords (WordPress, hosting, database, FTP/SFTP), regenerate the salts and revoke application passwords
  • If customer data may be affected, Indian law has deadlines: CERT-In expects a report within 6 hours, and from May 2027 the DPDP Act requires telling affected people and the Data Protection Board. See our DPDP compliance checklist

12. Your weekly 10-minute routine

  1. Apply pending updates (Dashboard → Updates)
  2. Read this week’s security alerts for your plugins
  3. Check that the last malware scan completed and the last backup ran
  4. Glance at the user list and the security plugin’s login log
  5. Run the website safety check and compare the grade with last week

WP-CLI commands for your WordPress security checklist

If your host gives you SSH and WP-CLI, these read-only commands cover much of the list above:

wp core version && wp core check-update
wp core verify-checksums
wp plugin list --fields=name,status,version,update
wp plugin verify-checksums --all
wp theme list
wp user list --role=administrator
wp user application-password list <user>
wp cron event list --fields=hook,next_run
wp option get siteurl

Need this done for you? We audit WordPress sites against every item on this WordPress security checklist and fix what we find. Get in touch, or see our security services. More checklists are on our free resources page.

Sources

Last updated: 27 October 2026.