WordPress security checklist: hardening that actually holds

Updated: 2026-10-27

You install a security plugin, it shows a green shield, and you close the tab feeling safe. Three months later a plugin you forgot about, last updated years ago, lets someone in through the side door. The shield was green the whole time.

Security is not a product you install. It is a short list of boring habits, and most hacks happen because one of them slipped. The WordPress security checklist below is that list.

The shift: from “add security” to “remove openings”

The common approach adds layers:

security plugin → firewall plugin → login limiter → another scanner → a slower site with the same holes

The approach in WordPress.org’s own hardening guide does the opposite. It removes what an attacker can use:

fewer plugins → everything updated → unique passwords and two-step login → least privilege → no file editing from the dashboard → backups you have tested → logs you can read

Almost every item below comes from the WordPress Advanced Administration handbook (developer.wordpress.org, Hardening WordPress). I have ordered it by how much it matters for a typical small site, not by how clever it sounds.

The checklist, step by step

1. Updates

• Run the latest WordPress version. Older versions stop receiving security fixes. Automatic background updates have been built in since WordPress 3.7; leave them on.
• Update plugins and themes, and delete the ones you do not use. A deactivated plugin is still code sitting on the server.
• Download WordPress only from wordpress.org, and install plugins and themes only from the WordPress.org directory or companies you know. “Nulled” premium plugins are a common way in.

2. Passwords and logins

• Use long, generated passwords from a password manager. The handbook’s list of what to avoid: anything tied to your name, company or site; dictionary words; short passwords; all-letters or all-numbers.
• Change passwords on every access point, not just WordPress: hosting panel, FTP/SFTP and database. They are all doors to the same house.
• Turn on two-step authentication for every account that can publish or install.

3. Least privilege

• Give each person the lowest WordPress role that lets them do their job. An author does not need to be an administrator.
• Remove users who no longer work on the site.
• Give each WordPress install its own database and database user where you can, so one compromised site does not open the others. The handbook notes normal operation only needs SELECT, INSERT, UPDATE and DELETE; it also warns that revoking more (DROP, ALTER, GRANT) can break updates that change the database, so only do that if you also keep tested backups.

4. Lock the configuration

• Disable the built-in theme and plugin editor by adding this to wp-config.php:

  define( 'DISALLOW_FILE_EDIT', true );

  The handbook is honest about the limit: it stops anyone editing code from the dashboard, but it does not stop an attacker uploading files.

• Restrict wp-config.php to the owner and the web server (the handbook suggests permissions of 400 or 440), and on Apache deny web access to it in .htaccess.
• Consider a table prefix other than the default wp_ on new installs. The handbook’s reasoning: many published SQL injection attacks assume the default.

5. File permissions

• The handbook’s baseline: directories 755, files 644.
• Core folders (/, /wp-admin/, /wp-includes/) and /wp-content/plugins/ should be writable only by your user account, not by the web server.
• Give the web server write access to /wp-content/ and uploads only where something really needs it.

6. Encrypted connections

• Serve the admin area over HTTPS so logins and session cookies are not sent in the clear.
• Use SFTP, never plain FTP. FTP sends your password unencrypted.

7. A firewall, if it earns its place

The handbook lists three options: a firewall plugin, a web-server firewall such as ModSecurity, or a reverse-proxy service in front of the site. Pick one. Stacking three rarely adds protection and often adds conflicts.

8. Backups you have actually restored

• Back up the database and the files; you need both to restore a site. The handbook recommends multiple dated snapshots kept somewhere you trust, so a compromise you discover late can still be rolled back.
• Store at least one copy away from the server. A backup that lives on the hacked server is part of the hack.
• Restore one backup to a test location now and then. A backup you have never restored is a hope, not a plan.

The full routine, including what to back up and how often, is in our guide on how to back up a WordPress site, both files and database.

9. Logs

Keep the web server’s access and error logs. The handbook’s point is practical: they record IP addresses, timestamps and actions, and they are how you answer “how did they get in?” after an incident. Without them, the forensic step of any cleanup is guesswork.

10. Scan your own computer

WordPress.org’s hacked-site FAQ notes that many infections start on the owner’s machine, with a trojan that captures FTP or admin logins (WordPress.org, FAQ My site was hacked). The strongest server settings do not help if the password is typed into an infected laptop.

A worked example

No client case studies exist on this site yet, so here is a hypothetical one.

Say you inherit a WordPress site with dozens of plugins, a few administrator accounts nobody can explain, and a backup plugin that saves to the same server. My agent would go through it in this order: list every plugin with its last update date and whether it is active; remove the inactive ones; flag any that look abandoned for a decision; downgrade or remove the unexplained administrators; add DISALLOW_FILE_EDIT; check permissions against 755/644; move the backup destination off the server; then restore the latest backup to a staging copy to prove it works. Each change goes into a short report, and a human reviews it before anything is applied to the live site.

Common mistakes

• Treating a security plugin as the checklist. It is one item on it.
• Keeping inactive plugins “just in case”. If you are not using it, delete it.
• Hiding the login URL and stopping there. Obscurity slows bots down; it does not fix a weak password or an outdated plugin.
• Setting permissions to 777 to make an error go away. That makes the files writable by every account on the server.
• Backups on the same server. When the server goes, so does the backup.
• Never testing a restore. You find out it fails on the worst day to find out.

If you are already hacked

Hardening is for a clean site. If you are reading this because something already looks wrong, harden afterwards: follow the guide for a hacked WordPress website first, then come back here and close the door. If you would rather not do the cleanup yourself, malware cleanup by Wayback Press removes injected code, replaces modified core files, rotates credentials and names the likely entry point, with a human review before delivery. No ranking promises. Hack cleanup is $79; see pricing.

My stance: do items 1, 2 and 8 this week. They are the cheapest items on the list, the ones most often skipped, and none of them costs anything but an afternoon.

The green shield was never the lock. The lock is the plugin you finally deleted.

Wayback Press (waybackpress.com) is an independent restoration and hacked-site cleanup service. Not affiliated with the Internet Archive or the Wayback Machine, nor with the Shift8 open-source “WaybackPress” command-line tool of the same name.