WordPress Hardening Checklist | OneWebDesk

Security score 0% (0/15)

Not secure yet. Start with the unchecked items.

Login security

Enabled two-factor auth (2FA) for admin accountsEven if a password leaks, a second factor blocks login. Prefer an authenticator-app (TOTP) plugin.Changed the default login URL (/wp-login.php, /wp-admin)Moving the default path blocks most automated bot brute-forcing and cuts log noise.Applied login attempt rate limitingLocks out after repeated failures, defeating brute force. Combine per-IP and per-account lockouts.Enforced strong passwords for every userRequire 12+ characters and unguessable passwords; remove default usernames like 'admin'.

Core, plugin & theme updates

Keeping WordPress core on the latest versionSecurity patches ship as core minor updates. Keep automatic security updates enabled.Updating plugins regularlyVulnerable plugins are the most common entry point. Get alerts and back up before applying.Removed unused plugins and themesDeactivating is not enough — leftover code is still attack surface. Delete it entirely.

Files & permissions

Protected wp-config.php from external accessBlock direct access via server config (.htaccess/nginx) and restrict permissions to 640 or 600.Disabled in-dashboard code editing via DISALLOW_FILE_EDITAdd define('DISALLOW_FILE_EDIT', true); to wp-config.php to stop code tampering if an admin is hijacked.Set correct directory/file permissions (755 / 644)Directories 755, files 644 is the standard. Never use 777.

Minimize exposure

Removed exposed WordPress version infoThe generator meta tag and readme.html expose your version to targeted attacks. Reduce exposure.Disabled unused XML-RPCXML-RPC is abused for brute-force amplification and pingback DDoS. Turn it off if you have no integrations.Blocked REST API user enumeration/wp-json/wp/v2/users and ?author=1 redirects leak usernames. Block unauthenticated access.

Backups & HTTPS

Automated backups are stored off-siteBack up files + database regularly and actually test restores. Do not keep them only on the same server.Enforced HTTPS everywhere with HTTP redirectsForce the whole site to HTTPS with a valid cert and enable HSTS to prevent session hijacking.

Why WordPress hardening matters

Most WordPress compromises start not with a zero-day but with neglected defaults and outdated plugins. Attackers brute-force /wp-login.php, harvest usernames via/wp-json/wp/v2/users, and scan for plugins with known vulnerabilities. Hardening is about shrinking that automated attack surface.

Core measures, in priority order

Login security: two-factor auth (2FA), login attempt limits and strong passwords give the best return.
Updates: keep core, plugins and themes current, and delete anything you no longer use.
File protection: block access to wp-config.php and set DISALLOW_FILE_EDIT to disable in-dashboard code editing.
Reduce exposure: hide version info, block unused XML-RPC, and stop REST API user enumeration.
Be ready to recover: automated backups and end-to-end HTTPS decisively limit damage when something goes wrong. Verify your response carries the right headers with the security headers check, and tighten your content policy with the CSP generator.

Permission baseline

As a rule of thumb, set directories to 755, files to 644, andwp-config.php to 640 or 600. Minimize directories the web server can write to, and never use 777.

Frequently asked questions

Is anything I enter sent to a server?

No. Your checkbox state and the readiness calculation happen entirely in your browser and are never transmitted or stored externally.

Does changing the login URL really make me safer?

It is not a fundamental defense, but it blocks most automated bot traffic, cutting log noise and brute-force attempts. It works best alongside 2FA and attempt limits.

Do I really need to disable XML-RPC?

If you do not use Jetpack, mobile apps or external publishing tools, disabling it is recommended. XML-RPC can be abused for brute-force amplification and pingback DDoS.

What does DISALLOW_FILE_EDIT do?

Adding define('DISALLOW_FILE_EDIT', true); to wp-config.php disables the plugin/theme code editor in the dashboard. Even if an admin account is hijacked, editing server code directly becomes much harder.

Is a single security plugin enough?

Security plugins help but are not a silver bullet. Real protection requires the fundamentals too — updates, strong passwords, backups and least-privilege permissions.