
How to Secure a WordPress Site: A Plain Checklist

WordPress's own documentation is a better security guide than most plugin sales pages. Its handbook says the most important thing you can do is keep WordPress, your plugins and your theme up to date, and pick plugins and themes that are still getting updates (WordPress handbook). It also says security means reducing risk, not removing it, so you plan for recovery too.
I host and look after existing WordPress sites on LiteSpeed servers I run. This checklist follows WordPress's Hardening guide and the pages around it, and links each step to its source.
Keep WordPress, plugins and themes updated
When WordPress fixes a security hole, the details needed to exploit it are almost certainly public, so old versions are more open to attack. Older versions of WordPress don't get security updates at all (Hardening WordPress).
Two settings do some of the work for you:
- WordPress itself. Since version 5.6, new installations update themselves for both minor and major releases by default. Sites installed earlier keep the old setting, minor releases only, until someone changes it (WordPress handbook). Dashboard > Updates shows which one your site uses, with a link to switch.
- Plugins and themes. By default these update themselves only when WordPress.org's security team pushes a fix for a critical vulnerability. Since WordPress 5.5 you can turn on automatic updates one plugin or theme at a time (WordPress documentation).
Get WordPress only from wordpress.org, and plugins and themes only from the WordPress.org directory or well-known companies (Hardening WordPress).
Back up before you update and check the site after. My 10 monthly maintenance tasks walk through the routine.
Use strong, unique passwords and two-factor sign-in
The Hardening guide's passwords to avoid: anything built from your name, username, company or site name; a dictionary word in any language; anything short; and anything that's all numbers or all letters. Use WordPress's strength meter, and let a password manager create a different password for every account (Brute Force Attacks).
Then add a second step. WordPress's handbook recommends two-factor sign-in for every administrator, and says WordPress core doesn't include it, so you add it with a plugin (Brute Force Attacks). Its two-step authentication page lists plugins from the WordPress.org directory, and points out the catch: if your second step is your phone and the phone isn't with you, you can't sign in.
Three more:
- Don't use
adminas a username. It's one of the first names attackers try. - Use SFTP, not FTP, so your password isn't sent unencrypted.
- Change the other passwords too. Your hosting control panel, SFTP and database logins protect the same site (FAQ My site was hacked).
Give each person the lowest role that works
WordPress has five standard roles on a single site (Roles and Capabilities):
| Role | What it can do |
|---|---|
| Administrator | Everything in the dashboard, including plugins, themes, users and settings |
| Editor | Publish and manage everyone's posts and pages |
| Author | Publish and manage their own posts |
| Contributor | Write and manage their own posts, but not publish them |
| Subscriber | Manage their own profile |
An Editor can run the content side of a site without being able to install plugins, switch themes or change settings. Give everyone their own login with the lowest role that does the job, and remove accounts when people leave. The handbook also suggests keeping administrators few and using a lower role for day-to-day work (Brute Force Attacks).
Delete plugins and themes you don't use
The Hardening guide says it plainly: if you're not using a plugin, delete it. Deactivating isn't enough, because a deactivated plugin stays on the server.
WordPress's Site Health screen (Tools > Site Health) flags inactive plugins as a target for attackers. For themes, it suggests removing every one you aren't using except your active theme, its parent if yours is a child theme, and one default WordPress theme, which WordPress falls back on if something goes wrong with yours (Site Health's checks).
Use HTTPS everywhere
HTTPS encrypts the connection between a visitor's browser and your server. WordPress's handbook strongly recommends it to protect your logins and your visitors, and notes that a certificate is free in many cases (HTTPS). Site Health warns you if your WordPress Address and Site Address aren't set to HTTPS (Site Health's checks).
Once HTTPS works, one line in wp-config.php makes every login and admin session use it:
define( 'FORCE_SSL_ADMIN', true );
Set up HTTPS on the server first, or the site won't work properly with that line in place.
Keep backups you can restore
A backup has two parts, the database and the files, and WordPress's handbook says you need both to fully restore a typical site. It suggests keeping at least three to five recent copies in different places (Backups).
Why more than one: a site hacked on May 1 might not be noticed until May 12, and regular snapshots leave you a copy from before the break-in (Hardening WordPress). Practice a restore now and then, too; the handbook recommends tested backups (Brute Force Attacks). More on backups in what it takes to look after a WordPress site.
Lock down file permissions and the dashboard editor
File permissions decide who can read and change each file. The Hardening guide says to lock them down as far as you can and loosen them only when something needs to write. When WordPress updates itself, it sets folders to 755 and files to 644. wp-config.php, which holds your database password, should be readable only by you and the web server (400 or 440).
WordPress's file permissions page warns against 777, which lets every user and process on the server read, write and run a file. If a guide tells you to use it, ask why. On shared or managed hosting, ask your host before changing anything: the right settings depend on how the server runs PHP.
The dashboard file editor lets administrators edit plugin and theme code from inside WordPress. The Hardening guide notes it's often the first tool an attacker uses after getting in, because it lets them run code. One line in wp-config.php turns it off:
define( 'DISALLOW_FILE_EDIT', true );
It won't stop an attacker from uploading malicious files, the guide says, but it might stop some attacks (Hardening WordPress). One caveat: a few plugins check for the editing permission this removes, so if a plugin stops working afterward, this may be why (Editing wp-config.php).
The table prefix and other hiding tricks
You'll often read that changing WordPress's database table prefix from wp_ stops SQL injection. WordPress doesn't say that. The Hardening guide files it under security through obscurity, which it calls "generally an unsound primary strategy". It says many published WordPress SQL injection attacks assume the default wp_ prefix, so changing it can block at least some of them (Hardening WordPress).
Note "at least some". A different prefix doesn't fix the flaw that let an injection in; updating the plugin or theme does. On a new install, choosing a prefix other than wp_ costs nothing. On a running site, the prefix starts every table's name, so changing it means changing the database to match, not just one line in wp-config.php. WordPress asks you to keep backups you know how to restore before changing settings like this (Editing wp-config.php).
Hiding the login page is similar: the handbook says it cuts down bot noise but shouldn't be your only defense (Brute Force Attacks).
Keep an eye on plugin vulnerabilities
The Hardening guide says the most common attacks on WordPress fall into two groups: requests built to exploit a known hole, such as one in an outdated plugin, and password guessing. The gap is the time between a hole becoming known and you finding out.
Your dashboard says an update is waiting, not why. Security companies publish databases of known vulnerabilities in WordPress core, plugins and themes; two you can look through are Patchstack's database and WPScan's list of plugin vulnerabilities. Look up the plugins you depend on most. If one has a known hole:
- There's a fix: update now, to the fixed version or later.
- There's no fix: delete the plugin until there is one, or replace it. Each plugin's page on WordPress.org shows when it was last updated. One that hasn't changed in years may never get a fix.
If your site is hacked
Start with WordPress's FAQ My site was hacked. In short:
- Stay calm and write it down: what you're seeing, when you noticed (with the time zone), and anything that changed recently, like a new plugin.
- Scan the site, and your own computer. Many attacks start with malware on the owner's computer that captures logins.
- Talk to your host. It may be able to tell a hack from an outage, and on shared hosting the problem may reach beyond your site.
- Lock everyone out. Change every password: every WordPress user, your hosting panel, SFTP and the database. Replace the secret keys in
wp-config.phpto sign out anyone still logged in. My post on resetting a WordPress password without email covers getting back in and finding administrator accounts you didn't create. - Back up the hacked site before you clean anything, so you have a copy to refer to.
- Clean it up. If you have a backup from before the hack, restore it. If not, the FAQ suggests replacing the
wp-adminandwp-includesfolders with fresh copies of the same WordPress version over SFTP, not with the dashboard's reinstall option, then working carefully throughwp-contentand checking.htaccess, a file attackers often change. - Update everything, then change the passwords again, now that the site is clean.
- Check Google Search Console. If Google has found hacked content or malware, its Security issues report shows it. Once everything is fixed, request a review there; Google says it can take from a few days to a few weeks.
- Work out how they got in, and close that route.
The FAQ also points to WordPress.org's support forums, where the community helps with hacked sites.
How I can help
If you'd rather hand the upkeep to someone else, I host and look after existing WordPress sites case by case, on LiteSpeed servers I run. Every site I host sits behind Cloudflare, whose firewall runs a set of custom rules I've written and keep up to date. Tell me about yours and I'll send a written quote for hosting and upkeep before anything changes. Content and design changes aren't included. A $500 deposit starts the quote. It's refundable until you accept, and credited to the work. Ask for a quote.

Jamin Giersbach
Jamin Giersbach is one of the three designers who started Popproxx in New York City in 2000. Early clients included WebMD, MSD Capital and Bookmans. In 2007 he took Popproxx to Oregon, and he has run it on his own ever since.
Read the full story →


