Secure WordPress

WordPress is not inherently weak: abandoned plugins, weak accounts and postponed updates cause incidents. Securing a site means reducing the attack surface, then being able to roll back if a change breaks something.

Updates and plugins

Enable automatic updates for minor and security releases of the core. For a major version, back up files and database before updating, then test the site.

• Update theme and plugins as soon as a security fix ships.
• Delete anything inactive: a disabled plugin is still code on disk.
• Replace abandoned plugins, even popular ones, when they no longer receive fixes.
• Keep PHP 8.4 in KeyHelp and check plugin compatibility before switching versions.

Accounts and authentication

An administrator named admin makes password attacks easier. Use a neutral username, a unique password stored in a manager, and a second administrator account as a fallback.

Enable two-factor authentication (TOTP) with a reputable plugin, and confirm it works before closing your session. Grant the weakest role that fits: an author does not need administrator rights.

If you suspect a compromise, change the wp-config.php keys: every existing session is invalidated.

Harden the configuration

In wp-config.php, disable the built-in file editor, which turns admin access into code execution:

define('DISALLOW_FILE_EDIT', true);
define('FORCE_SSL_ADMIN', true);

If you do not use XML-RPC, filter it out. You can also block file installation when you deploy over SFTP only, but note that this stops updates from the dashboard:

define('DISALLOW_FILE_MODS', true);

Keep 755 for directories and 644 for files. A 777 on wp-content is enough to let a malicious PHP file be written.

Plugins, theme and logs

Install only plugins from the official repository or a known vendor, never a "nulled" build. Before adding a security plugin, check that it is maintained; an outdated security plugin is one more risk.

A lean theme reduces the code executed on every page. Avoid unmaintained themes and page builders that load old libraries.

Watch failed logins and file changes with a dedicated plugin or the hosting logs. Login rate limiting slows brute-force attacks; it does not replace a strong password and 2FA.

Check after each change

• You can log in with 2FA and the fallback account works.
• The file editor is no longer available in the admin.
• http:// redirects to https:// and the certificate is valid.
• A recent backup is stored off the site and its restore has been tested.
• Roles match what each person actually needs.

Hiding the login page is not a security measure: it slows bots a little and does nothing for a weak account. Do not rely on removing the displayed version to stop a targeted attack either.