WordPress Security After Four Months of Production Sites

WordPress powers a huge slice of the internet and attracts a corresponding share of attacks. Four months of running production sites has given me a concrete list of security practices that pull their weight. Not theoretical. Things I have seen save me.

Start With the Host

Managed WordPress hosting is my default for clients. The hosts run at the infrastructure level the protections that plugins run at the app level. Rate limiting, DDoS absorption, malware scanning. If your host is shared cheap bulk hosting, nothing at the app level compensates.

I have watched two sites get compromised on budget shared hosting and zero on managed WordPress hosting. The cost difference pays for itself the first time an attack gets blocked at the edge.

Turn Off File Editing

By default WordPress lets admins edit PHP files through the dashboard. This is convenient for developers and catastrophic for hacked admin accounts. One line in wp-config.php kills the feature and the corresponding attack surface.

// wp-config.php additions I apply to every site
define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', true);  // also blocks plugin/theme install via admin
define('FORCE_SSL_ADMIN', true);
define('AUTOMATIC_UPDATER_DISABLED', false);

DISALLOW_FILE_MODS is stricter: it blocks plugin and theme installs from the admin. I use this on sites where plugin updates flow through a deployment pipeline rather than wp-admin.

Strong Authentication

Two-factor authentication on every admin account. Non-guessable usernames (never 'admin'). Strong passwords enforced by a plugin. These sound basic. They are. They also block the most common attacks which are credential stuffing and brute force.

Keep It Patched

The single highest-leverage thing you can do is keep WordPress core, themes, and plugins updated. The vast majority of WordPress compromises are against known vulnerabilities with available patches. The fix exists. The site owner did not apply it.

I run auto-updates for security releases. I review and deploy feature updates weekly. This rhythm has kept me clean.

Backups You Have Actually Restored From

A backup you have never restored is a hope, not a backup. Every new site gets a documented restore test in the first week. If the restore fails, the backup strategy is wrong and I find out before disaster instead of during it.

See the WordPress hardening documentation for the official guide. The practices above are the ones that actually moved the needle on sites I run. Security is discipline, not products.