How to harden WordPress in an afternoon

Hardening is the set of one-off configuration changes that reduce what an attacker can do if they get a foothold. It is not a substitute for updating weekly — nothing is — but it is a few hours that keeps paying.

Back up before you start. Several of these involve editing wp-config.php, and a typo there takes the site down.

In wp-config.php

Add these above the line that says "That's all, stop editing".

Disable the file editor

define( 'DISALLOW_FILE_EDIT', true );

The highest-value line here. Without it, anyone reaching your admin can edit theme and plugin PHP directly in the browser. This is how a stolen password becomes a permanent backdoor, and you almost certainly never use the editor anyway.

Disable plugin and theme installation

define( 'DISALLOW_FILE_MODS', true );

Stronger, and more disruptive: it also blocks updates from the admin. Sensible on a site where updates are applied via deployment or by a maintenance provider, wrong if you update by clicking.

Force SSL for logins and admin

define( 'FORCE_SSL_ADMIN', true );

Rotate your salts

The security keys in wp-config.php. Generate a fresh set from the WordPress secret-key service and paste them in. This invalidates every existing session, which is exactly what you want after any suspected compromise or when someone leaves.

Limit post revisions

define( 'WP_POST_REVISIONS', 5 );

Not security, but it keeps the database from bloating, which affects backups and speed.

In WordPress itself

Remove unused accounts, downgrade the rest

Users → All Users. Anyone who left should be gone. Anyone who does not need Administrator should be Editor or lower. This is the most commonly skipped step and one of the more effective.

Rename or remove predictable admin usernames

"admin", "administrator", "root". WordPress cannot rename a user, so create a new administrator, log in as them, delete the old one and reassign its content.

Two-factor on every administrator

Ten minutes, and it stops credential stuffing dead.

Delete unused themes and plugins

Not deactivate. Delete. Inactive code is still code on your server.

At the server level

Block PHP execution in uploads

The uploads folder should never run PHP. If an attacker manages to place a file there, this stops it executing. Add to wp-content/uploads/.htaccess on Apache:

<Files *.php> deny from all </Files>

On nginx your host needs to add an equivalent location block — ask them.

Protect wp-config.php

<files wp-config.php> order allow,deny deny from all </files>

Correct file permissions

Directories 755, files 644, and wp-config.php at 600 or 640. Anything set to 777 is a genuine finding — it lets any process on the server write into your site, which on shared hosting includes other accounts.

Security headers

Add X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Strict-Transport-Security. A security plugin can set these, or your host can do it at server level.

Restrict rather than disable XML-RPC

Blanket-disabling XML-RPC is common advice and breaks the WordPress mobile app, Jetpack and several integrations. It is also the vector for the pingback amplification attacks people are worried about.

The better answer is to restrict it: block the system.multicall and pingback.ping methods, which is what most security plugins offer, rather than turning the whole endpoint off.

Not worth your time

Hiding the login URL. Reduces log noise, stops nothing serious.

Changing the database prefix on an existing site. Marginal benefit, real chance of breaking things.

Removing the WordPress version number. It is inferable from a dozen other signals. Obscurity is not a control.

Blocking all of xmlrpc.php — see above.

What this actually buys you

Hardening limits the blast radius. It does not stop the initial compromise, which will almost always come through an outdated plugin.

So do this afternoon's work, then set up the weekly routine — or have someone run it. Hardening plus neglect is still a hacked site, just one where the attacker had to work slightly harder.