WordPress security checklist: what to set, and how to know it stays set

Why a checklist done once isn't enough

Most of the risk is in plugins, and it moves fast. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 42% more than in 2024: 91% were in plugins, 9% in themes, and only 6 in WordPress itself. 46% had no fix from the developer when they were disclosed, and for the vulnerabilities attackers went after most, the median time to the first mass exploitation was 5 hours.

So a site that was secure in January can be exposed in March without anyone touching it. The measures below are the ones WordPress's hardening and brute-force pages recommend. Next to each, we say whether it can be watched continuously, and which Relvato monitor does it. Where nothing watches it, we say that too.

1. Accounts and sign-in

Use a unique, long password for every account that can sign in, and turn on two-factor authentication for every administrator. WordPress itself doesn't ship two-factor: its brute-force page says to enable it for all administrators and privileged users with a reputable plugin. The Two Factor plugin, built by WordPress contributors and listed on WordPress.org, is a good default.

Keep administrators few. Give each person the lowest role that does their job, remove accounts nobody uses, and look for administrators you don't recognise; our guide to WordPress user roles explains why every extra administrator is one more way in. Application passwords and WooCommerce API keys are worth a look too: they are meant for programs, not people, so they sign in to the REST API and XML-RPC without the login form or two-factor.

Limit login attempts. WordPress's brute-force page prefers to do this at the edge, in your host's firewall or a CDN, and says a security plugin can throttle attempts when the edge doesn't; a CAPTCHA such as Turnstile on the login form helps as well.

What can be watched: the Admin roster monitor reports a new administrator, an administrator hidden from the Users screen, a new application password or API key, more than three administrators, administrators who haven't signed in for 90 days, and administrators with no two-factor set up in the two-factor plugin the site runs. Once you turn on the activity log in the plugin, it also reports editors and authors nobody has signed in as for 90 days, and Activity log & admin logins reports spikes in failed sign-ins and administrators signing in from a new network. The Exposure scan warns when the login page is open with nothing visible protecting it: no login-protection, CAPTCHA or two-factor plugin and no firewall in front. Two-factor set up in a plugin Relvato can't read, such as Shield, isn't counted either way.

2. Updates, plugins and themes

Keep WordPress, plugins and themes up to date; WordPress's hardening page is plain that older versions aren't maintained with security updates. Install security releases as soon as they're out, update one plugin at a time, and check the pages that matter afterwards. Our WordPress maintenance guide has a schedule.

Fewer plugins means fewer vulnerabilities. Delete plugins and themes you don't use instead of only deactivating them, because inactive code can still be reached. Replace plugins that WordPress.org has closed or that haven't been updated in years, and buy premium plugins from their developer, never from a site that redistributes them.

What can be watched: the Vulnerability monitor reports plugins, themes and WordPress versions with known vulnerabilities, plugins with an update waiting (and says when the changelog mentions a security fix), plugins closed on WordPress.org or abandoned for two years, inactive plugins and themes, and active plugins that aren't from WordPress.org, so you can confirm where each came from. On paid plans, when a new advisory names a plugin your site runs, the site is scanned again.

3. HTTPS, TLS and security headers

Serve the whole site over HTTPS, and redirect every http address to it. Accept TLS 1.2 and 1.3 only: RFC 8996 deprecated TLS 1.0 and 1.1 in 2021, and says they must not be used. These settings live at your host or CDN, not in WordPress, which is why they can change when you move host or the host changes its defaults.

Add an HSTS header so browsers never fall back to http. Start with a short max-age and raise it once you're sure every subdomain works over HTTPS; the HSTS preload list asks for at least a year (31536000 seconds), but only add preload when you mean it. Our guide to HTTP security headers covers HSTS and the other headers worth sending.

What can be watched: the SSL certificate monitor reports a certificate that's expired, untrusted or close to expiry, and a server that still accepts TLS 1.0 or 1.1. Redirects & canonical host reports an http address that serves the page instead of redirecting. Mixed content finds http resources on https pages, and the Exposure scan reports missing security headers and an HSTS max-age under 180 days.

4. Turn off what you don't use

Disable XML-RPC if nothing uses it; WordPress's brute-force page says exactly that. Jetpack, the WordPress mobile app and some integrations still need it, so check before you switch it off.

Turn off the plugin and theme file editor with define( 'DISALLOW_FILE_EDIT', true ); in wp-config.php. WordPress's hardening page notes it won't stop an attacker from uploading files, but it means one stolen administrator session can't edit live PHP from the dashboard.

Stop the site from listing its users and its versions: the users endpoint of the REST API, author archives at /?author=1, the generator tag and a public readme.html all help an attacker pick usernames and vulnerable versions. And keep debug output off for visitors: PHP errors on a page give away file paths and queries.

What can be watched: the Exposure scan reports XML-RPC switched on, the file editor enabled, user enumeration through the REST API or author archives, version leaks, and debug output shown to visitors. Most of these have a one-click fix with Undo, described in WordPress security hardening. WP_DEBUG writing to a private log isn't reported, but a debug.log anyone can download is.

5. Files, permissions and what's left in the web root

WordPress's file permissions page sets the numbers: files 644 or 640, folders 755 or 750, and wp-config.php 440 or 400 so other users on the server can't read it. No folder should ever be 777, not even uploads.

Clear out what doesn't belong in the web root: database dumps, zip backups, copies of wp-config.php such as wp-config.php.bak, .env files and .git folders. Each of these can hand over the whole site to anyone who guesses the address.

What can be watched: the Exposure scan looks for exposed .env files, .git folders, wp-config.php copies, SQL dumps, backup archives and a public debug.log. With the Relvato plugin connected, the site reports these files from inside, along with PHP files in uploads and sample security keys. It also reads the permissions of wp-config.php and .htaccess: either one that anyone on the server can change, and a wp-config.php other accounts can read where PHP runs as its owner. Other files' permissions aren't monitored. The File integrity monitor compares WordPress's files with the official checksums and reports unexpected PHP files and hidden plugins, and Theme integrity reports executables dropped into uploads and malicious code added to wp-config.php or .htaccess.

6. Backups you have restored

Back up the database and the files: weekly for a small site, daily for a busy one, and always before an upgrade, as WordPress's backup page recommends. Keep copies in different places, because a backup stored on the server that gets hacked or fails goes with it.

A backup only counts if it restores. WordPress's hardening page asks for backups you have tested are valid and can be restored easily. Restore one to a staging site every few months.

What can be watched: the Backups monitor reads UpdraftPlus, BackWPup, Duplicator, WPvivid and other backup plugins. It reports a last completed backup older than seven days, failed or stalled backups, no schedule, and backups stored only on the same server. Restores aren't tested by Relvato: that one stays on your own list.

7. Firewall, malware and the signs a scanner misses

Put a web application firewall in front of the site, at your host or CDN, or as a plugin. Don't count on the host alone: in Patchstack's tests, hosting defences blocked only 26% of the attacks. Our comparison of Wordfence vs Sucuri covers the two best-known options.

Relvato doesn't report whether a firewall is in front of your site. It watches for what gets through: Signs of a hack looks for spam pages, cloaking and off-site redirects the way visitors and Google see them, and Third-party scripts reports a script from a new origin on your key pages, including the checkout, which is how card skimmers get in.

If something does get in, our WordPress hacked checklist covers what to do first, including the places no scanner can see. After a cleanup, Quarantine mode watches the site's files, administrators and scripts every hour for 48 hours.

What monitoring needs, and what it can't do

Most of the inside items, such as administrators, plugins, backups and file integrity, need the Relvato WordPress plugin connected, which also proves you own the site. The outside items, such as certificates, TLS, redirects and headers, work on any site. How often they run depends on the plan: at most weekly on Free, daily on Pro and hourly on Business, and after every plugin or theme update on Pro and up.

Monitoring tells you when an item stops being true. It doesn't set the items for you, and it doesn't replace a firewall, a backup plugin or two-factor sign-in. Treat this checklist as two lists: the measures you set once, and the ones you want to hear about the day they change.