How to Secure a WordPress Site

Close the common doors

  • Remove any user named admin and use unique names per person.
  • Enforce two-factor authentication for every administrator.
  • Limit login attempts and rate-limit wp-login.php and xmlrpc.php.
  • Disable file editing in the dashboard so a stolen session cannot inject code.
  • Keep core, themes and plugins updated; enable auto-updates for minor core releases and trusted plugins.
  • Delete abandoned plugins — an unmaintained plugin is a scheduled breach.

Config and server hardening

// wp-config.php
define( 'DISALLOW_FILE_EDIT', true );
define( 'FORCE_SSL_ADMIN', true );
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Protect sensitive paths

# .htaccess — block direct access to config and disable PHP in uploads
<Files wp-config.php>
  Require all denied
</Files>

<FilesMatch "^\.(htaccess|htpasswd|env)$">
  Require all denied
</FilesMatch>

Also disable PHP execution inside wp-content/uploads — it stops an uploaded image from being run as a script, which is how most WordPress compromises escalate.

If you are already compromised

  • 1 Take the site offline or into maintenance mode and change every password: hosting, cPanel, database, WordPress admins, FTP.
  • 2 Take a forensic copy before cleaning, so you can investigate later.
  • 3 Compare core files against a clean copy of the same WordPress version and remove anything unexpected.
  • 4 Look for injected admin users, unknown scheduled tasks, modified .htaccess rules and base64-encoded strings in theme files.
  • 5 Reinstall core, themes and plugins from official sources rather than patching individual files.
  • 6 Rotate salts in wp-config.php to invalidate all sessions.
  • 7 Request a malware scan from support, then submit a review request if search engines flagged the site.

Ongoing routine

  • Weekly: apply updates on staging, then production; review user list.
  • Monthly: verify a restore works, review security logs, check for plugin abandonment.
  • Quarterly: audit third-party integrations and API keys, and remove what is unused.

Frequently asked questions

Is a security plugin enough?

It helps, but it runs inside the application it is defending. Server-level firewalling, current PHP, tight permissions and disciplined updates matter more.

Does changing the database prefix help?

Marginally, against automated scripts. It is worth doing at install time and not worth a risky migration afterwards.

Need a hand applying this?

Our engineers can do it for you. Open a ticket and we will help.

See plansTalk to us