Harden a Fresh WordPress Install in Thirty Minutes

Most WordPress hardening guides are an unordered list of twenty items. In practice the entry point on a compromised site is almost always one of three things: a weak or reused administrator password, an outdated plugin with a published exploit, or file permissions a host set far too loosely.

So this guide is ordered. The first three items cover those three causes. Everything after is real but incremental, and you can stop whenever you run out of time.

First: your recovery path

Login hardening is the step most likely to lock you out of your own site. Set this up first so a mistake costs two minutes instead of a support ticket.

1. Fix the administrator account

Not the password policy — the account itself. If your install has a user literally called admin, half of every brute-force attempt already has the username correct.

Create a new administrator with a non-obvious username, log in as that user, then delete the old account and reassign its content. Set a passphrase of four or more unrelated words rather than a short complex string: length beats character variety against modern cracking.

2. Close the plugin gap

The fix here is unglamorous: remove what you do not use, and update what you keep on a schedule you actually follow.

Check	Action	Time
Deactivated plugins	Delete them. Deactivated code still exists on disk.	2 min
Not updated in 12 months	Replace. An abandoned plugin is a scheduled vulnerability.	10 min
Nulled or pirated	Remove immediately and treat the site as compromised.	—
Minor auto-updates	Enable. The breakage risk is lower than the patch risk.	1 min

3. Lock down file permissions

Some shared hosts set directories to 777 so their own tooling works, which means any process on that server can write to your files. Set them back:

# directories
find . -type d -exec chmod 755 {} \;

# files
find . -type f -exec chmod 644 {} \;

# wp-config.php, tighter
chmod 600 wp-config.php

If updates stop working afterwards, the problem is file ownership, not permissions. Your web server user needs to own the files. Ask your host to correct ownership rather than loosening permissions again.

4. Disable file editing in the dashboard

The theme and plugin editors let anyone with administrator access write PHP straight into your site, which is exactly what an attacker does after stealing a session. One line in wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

There is no real cost. If you need to edit a theme file you should be doing it over SFTP in a child theme anyway.

5. Two-factor on every administrator

This is the highest-value remaining change, and it is why the recovery path came first. Use a plugin supporting app-based codes with stored backup codes, enable it on your own account, confirm you can log in with it, then enforce it for the administrator role.

6. Limit login attempts

Rate-limit failed logins at the server or firewall level if you can, and with a lightweight plugin if you cannot. The goal is to make credential stuffing expensive, not to block it entirely.

7. Keep salts fresh after any incident

The authentication keys and salts in wp-config.php sign every session cookie. Regenerating them invalidates all active sessions, which is what you want after any suspected compromise or after removing a user.

8. Move wp-config.php out of the web root

Optional, and only if your hosting layout supports it cleanly. WordPress looks one directory above the web root automatically. The benefit is modest; the risk of breaking a deployment process is real, so skip it if your setup is fragile.

What we skip, and why

• Changing the login URL. It reduces log noise, not risk, and it breaks password managers.
• Hiding the WordPress version. Fingerprinting works from a dozen other signals.
• Full security suites. They scan, firewall, cache and optimise, do each adequately, and cost real page speed.

Common questions

Do I need a security plugin at all?

For a standard site, no. The changes above cover the attack paths that actually get used. A plugin becomes worth it when you need logging and alerting across many sites.

Will any of this break my site?

File permissions and two-factor are the two that can cause problems, which is why both come after the recovery path. The rest are safe on a live site.

How often should I redo this?

The setup is one-time. The maintenance is the plugin update schedule, which is monthly. Re-audit permissions after any host migration.

My site is already hacked. Does this help?

Not on its own. Hardening a compromised site leaves the attacker inside. Clean it first, then harden.