One plugin cannot secure a WordPress site by itself. A trusted plugin may add two-factor authentication, monitoring, or rate limits. The web server can reject some requests before PHP runs. Updates and tested backups reduce the damage when another layer fails.
A practical plan assigns responsibility across hosting, the server, WordPress, user accounts, and monitoring.
Keep the installed surface small
Update WordPress core, themes, and plugins to supported versions. Remove unused components instead of leaving them deactivated. Install software only from the official directory or the vendor you trust.
Review major updates in staging when the site handles orders or sensitive integrations. Know how you will detect a failed update and how you will restore a working version.
Protect accounts
Use unique passwords stored in a password manager and enable two-factor authentication for administrators. WordPress does not provide 2FA in core, so choose a maintained plugin or an identity provider.
Reduce the number of administrators. Give integrations Application Passwords instead of a shared administrator password. An application credential can be revoked without changing the person’s login.
Changing the login URL may reduce automated noise, but it is not a replacement for strong authentication and rate limits.
Rate limit before PHP when possible
A CDN or host-level firewall can stop repeated login requests before they consume application resources. An in-app security plugin can also limit attempts, but PHP still has to process the request.
Monitor false blocks. Permanent IP bans are a weak single control because attackers rotate addresses and legitimate users move between networks.
Protect configuration and permissions
wp-config.php contains sensitive settings. On Apache 2.4, direct access can be denied with current Require syntax. Nginx does not read .htaccess, so it needs a server configuration rule instead.
Do not apply a copied rule until you know which server is running and how the host manages overrides.
Avoid 777 permissions. The common 755 directory and 644 file pattern is only a starting point. The correct setting depends on ownership, groups, and the PHP runtime. Understand those before applying recursive permission changes.
Disable the built-in theme and plugin editor if the content team does not need it:
define('DISALLOW_FILE_EDIT', true);This reduces what a stolen administrator session can do through the dashboard, but it cannot stop someone who already controls the filesystem.
Make an explicit XML-RPC decision
xmlrpc.php receives repeated brute-force traffic, but Jetpack and other integrations may still use it. Inventory dependencies first. If the site does not need XML-RPC, block it at the edge or server and verify that publishing and integrations still work.
Backups need restore proof
Keep database and file backups outside the production server. Define retention, encryption, and access. Most importantly, perform a restore test. A dashboard that says “backup completed” does not prove that the archive is complete or that the team knows how to recover.
Write down the recovery point objective, recovery time objective, DNS access, and the person authorized to restore production.
Monitor changes that matter
Alert on unavailable pages, unexpected administrator creation, changed core files, malware findings, failed scheduled jobs, and unusual login patterns. Logs should be retained somewhere an attacker cannot erase by deleting the site.
Security is routine operating work. The strongest site is not the one with the largest security plugin. It is the one with a smaller attack surface, controlled accounts, observable changes, and a recovery process that has been tested.