Practical WordPress hardening: updates, wp-config, permissions, logins, SSL, plugins, XML-RPC, .htaccess, firewall, scans, and backups in a sensible order.
Topics Hardening & checklists Beginner guides
Updated Published
Hardening WordPress means changing configuration so the usual doors are closed. This guide is the deeper “how to set it up” companion. For habits and monthly routines, use best practices. For a tickable list, use the security checklist.
Think in layers:
wp-config.php, updates, file edit locks)Most compromises still start with outdated plugins or weak admin access. Start there even if you never touch Apache configs.
Use staging for fragile sites. Auto-update trusted plugins when you can. After bigger updates, re-run security tests and a vulnerability scan.
wp-config.phpGenerate fresh WordPress salts/keys after a compromise, or when you inherit a site.
On production:
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );Stop theme/plugin file editing from wp-admin (worth doing on almost every live site):
define( 'DISALLOW_FILE_EDIT', true );Only use DISALLOW_FILE_MODS if you intentionally manage updates outside wp-admin. It blocks plugin/theme installs and updates from the dashboard.
A custom table prefix helps a little against dumb automated scripts. It is not a substitute for updates and strong logins. Changing prefix on a live site needs care; do it on new installs when you can.
wp-config protectionExact values depend on the host, but a common baseline is:
755644wp-config.php: tighter when possible (600 or 640)Avoid 777. If the site breaks after tightening permissions, ask the host what their WordPress stack expects instead of opening everything up.
On Apache, you can also deny web access to wp-config.php in .htaccess. Change one rule at a time, test the homepage and /wp-admin/, and keep a backup of the file. Full snippets and rollback notes: .htaccess security guide.
Core Scanner helps spot unexpected changes to WordPress core files after hardening.
Rename alone is not enough. Combine it with rate limiting and 2FA. More depth: login security guide.
Scan installed software for known issues with the vulnerability scanner (included free). Deeper plugin hygiene: plugin security risks.
Server deep-dives (custom TLS ciphers, DB privilege surgery, Apache module surgery) help when you control the VPS. On shared or managed WordPress hosting, spend your time on updates, logins, firewall, and backups first.
If your host or a security plugin can set headers, useful ones include:
Strict-Transport-Security (HSTS) after HTTPS is solidX-Content-Type-Options: nosniffReferrer-Policy with a sensible defaultContent-Security-Policy only if you can maintain it (easy to break the site)Headers help browsers behave better. They do not replace patching plugins.
XML-RPC helps some mobile apps, Jetpack-related flows, and remote tools. It is also a common brute-force and pingback abuse path.
On Apache, add rules one at a time and test. Details and safer patterns: .htaccess guide.
Hardening without monitoring still fails quietly.
Scheduled scans matter because most site owners do not open the dashboard every day. Set the schedule, then check failures.
Hardening reduces risk. Backups limit damage.
Details: backup plan after an attack.
Store backup credentials outside the site. If malware can read your wp-admin, you do not want the only restore path living in the same compromise.
A good security plugin should help you enforce and verify hardening, not replace updates and strong logins.
A WordPress security plugin like Security Ninja covers security tests, vulnerability checks, and core integrity free. Pro adds Cloud Firewall (600M+), malware scanner, scheduled scans, login protection, and 2FA. The install wizard turns on sensible defaults so you are not guessing which toggles matter first. Avoid stacking three overlapping security plugins; they fight each other. See plugin conflicts and best WordPress security plugins if you are still choosing.
Day 1
This week
DISALLOW_FILE_EDIT, debug off on productionwp-config access if Apache allows itOngoing
Do I need to rename the wp-content folder?
Usually no. It breaks things, and bots already probe plenty of other paths. Focus on updates, logins, and scanning.
Should I disable XML-RPC?
Only if nothing you use needs it. Blindly disabling it can break integrations. Prefer firewall rate limits and strong auth when you still need the feature.
Is renaming the login URL enough?
No. It reduces noise. Pair it with failed-login limits and 2FA.
Can I harden once and forget it?
No. New plugin CVEs show up constantly. Hardening is a baseline plus a maintenance habit.
Do not “harden” over active malware and call it done. If you are unsure, tell if your WordPress site has been hacked first. Remove WordPress malware or restore, then harden so they do not walk back in. Guide: WordPress site hacked. Need help? Hire cleanup or a review.
Found this useful? Share it.
