WordPress Security Best Practices: The Checklist That Actually Matters

Why most advice misses the point

Search “WordPress security best practices” and most of what comes back is a list of plugins to install. A security plugin is useful — it scans, it logs, some of them include a basic firewall — but it does not fix a weak password, an outdated plugin with a publicly known vulnerability, or file permissions left wide open after a migration. Those are the actual entry points. A plugin sitting on top of them is a smoke detector in a house with the door unlocked.

This list is ordered by how much each item actually closes off, not by how easy it is to sell. The first three or four matter far more than the rest.

1. Keep everything updated — core, plugins, themes

Almost nobody hacks a WordPress site by discovering something new. Bots scan millions of sites at once for a specific, already-known, already-patched vulnerability — the update that would have closed it was published days, sometimes years, before the attack. The delay between a patch existing and a site actually running it is the single biggest exposure window on most WordPress installs.

Turn on automatic updates for minor core releases, and review major core, plugin and theme updates promptly rather than letting them sit for months. If a site is complex enough that an update might break something, that is what staging is for — not a reason to skip the update indefinitely.

2. Use strong, unique credentials everywhere

Not just the WordPress admin password — hosting/cPanel, the database, FTP/SSH, and any third-party service connected to the site each need their own strong, unique credential. Credential-stuffing attacks work by trying passwords leaked from a completely unrelated breach against thousands of sites at once, on the assumption that people reuse passwords. They are right often enough that this remains a common entry point.

Add two-factor authentication to wp-admin specifically. It is the single highest-value five-minute change on this entire list, because it stops a correct password from being enough on its own.

3. Delete what you don’t use

An inactive plugin or theme is still code sitting on the server, and a vulnerability in it is still exploitable even while it is deactivated — deactivating does not remove the files, it just stops them from running on a normal request, which does not protect against every way a vulnerability can be reached. Delete anything not actively in use, rather than leaving it switched off "just in case." The same goes for default sample content, old backup archives left inside the web root, and any staging or test copy of the site that is still technically reachable.

4. Limit login attempts and lock down wp-admin

Rate-limit login attempts so a brute-force script cannot try thousands of password combinations unopposed. Disable XML-RPC if nothing on the site actually uses it (most sites don’t) — it is a long-standing, well-known brute-force and amplification vector. If the site is only ever administered from a small, known set of locations, restricting /wp-admin/ and wp-login.php by IP at the server level is one of the more effective, least-visible changes available.

Renaming the default login URL is worth mentioning because it is so often recommended: it reduces noise from the least sophisticated automated scans, but it is not protection on its own and should never be the only measure in place.

5. Fix file and folder permissions

Directories at 755, files at 644, and wp-config.php tighter still where the host allows it, is the standard, safe baseline. Permissions left too open — often from a migration, a restore, or a host-side default — let an attacker who has gained any foothold at all write new files directly, which is exactly how a single compromised plugin turns into a persistent backdoor.

6. Put a firewall in front of the site

A web application firewall — Cloudflare, Sucuri, Wordfence's firewall specifically — absorbs automated scanning and known-exploit traffic before it ever reaches WordPress at all. This is a genuinely different job from malware scanning, even though the two are frequently bundled and marketed together: a scanner tells you something already got in, a firewall is what reduces how often that happens in the first place.

7. Back up automatically, off-site

Automated, off-site backups turn an incident into a restore instead of a forensic exercise. Off-site matters specifically: an attacker who gains real server access can delete on-site backups just as easily as the rest of the site, which defeats a backup that only ever lived in the same place. Verify a backup can actually be restored occasionally — an untested backup is a belief, not a safety net.

8. Disable file editing from wp-admin

WordPress ships with a built-in theme and plugin file editor inside wp-admin. Adding define('DISALLOW_FILE_EDIT', true); to wp-config.php disables it. This closes a common post-compromise escalation step: an attacker who obtains any admin-level login — through a leaked password, a session cookie, or a separate vulnerability — can otherwise edit theme or plugin files directly from the dashboard and plant a backdoor without ever touching FTP.

The checklist, in priority order

1. Update WordPress core, plugins and themes promptly — automatic for minor releases.
2. Strong, unique credentials everywhere, plus two-factor authentication on wp-admin.
3. Delete unused plugins, themes, sample content and stray backup files, rather than deactivating.
4. Rate-limit logins, disable unused XML-RPC, and restrict wp-admin access where feasible.
5. Correct file and folder permissions — 755 directories, 644 files, tighter on wp-config.php.
6. A web application firewall in front of the site, not just a scanner behind it.
7. Automated, off-site, occasionally-tested backups.
8. Disable file editing from wp-admin via DISALLOW_FILE_EDIT.

None of these are exotic. Together, they close the entry points that account for the overwhelming majority of WordPress compromises — not a single one of them requires a specialist, and most take under an hour.

When hardening isn’t enough

This list is realistic to work through yourself on a site you understand well. It is worth having it done properly in one pass — whether the site has just been cleaned up after an incident or has never been compromised at all — when you would rather have someone verify each item was actually applied correctly than assume it was, or when the site is complex enough (multiple admins, a WooCommerce store, several editors with FTP access) that "everyone follows good practice" is not a plan.

That is what WordPress Security Hardening is for — a one-time pass that closes these off properly, either as prevention or immediately after a clean-up.