WordPress hardening: 16 one-click fixes and what each changes
WordPress hardening means closing the doors a default install leaves open: an API most sites no longer use, a code editor in the dashboard, uploads folders that can run PHP. Most hardening checklists tell you what to change and leave the how to you.
BetterShield turns sixteen of those changes into switches. Each one says what it will change before you turn it on, and each one is logged. This guide covers all sixteen, what each can affect, and which to watch on real traffic first.
Quick summary
- Ten fixes are on BetterShield › Protect › Hardening. The six that change how people sign in are under Signing in on Protect › Login & Access.
- Every fix starts off. Preview the change lists what applying would do and changes nothing.
- Five fixes offer Monitor first: they count matching requests for an hour, a day or a week before anything is enforced.
- Turning a switch off undoes the fix. Two effects sit outside any undo: sessions ended by a key change, and an HSTS setting browsers already saw.
- Five audit findings have an Apply fix button, and Quick Setup offers five fixes that cannot lock anyone out.
How to harden WordPress with BetterShield
The Hardening screen shows your score, then a card titled Protect with a count such as “3 of 10 on”. Its own line sums up the rules: “Each item applies on its own and reverts on its own. Nothing here is batched, and every change is recorded.”
Every fix works the same way:
- Fill in any field the fix has, then press Preview the change. It lists what applying would do and says: “This is a preview. Nothing was changed and nothing was written.”
- Turn the switch on. The row shows On since and Undo never expires.
- To undo, turn the switch off. A fix that wrote a file takes out what it added.
If another security plugin already does a fix’s job, the row says so. A fix your server cannot run shows Not available here with the reason. Safe mode, started from your recovery link, pauses every fix and keeps its settings.
The WordPress hardening checklist, fix by fix
The sixteen fixes, in the screen’s own groups and order.
What the site reveals
| Fix | What it changes | What it can affect |
|---|---|---|
| Block public user listing | Stops the REST API, author links, the users sitemap and embeds from naming your users. A wrong password and an unknown username get the same answer. | A mistyped address on the lost-password form is told a link is coming, and none arrives. |
| Stop uploads directories listing their contents | Adds a blank index.php to uploads folders without an index file, two levels deep. | Works on every web server. |
| Hide sensitive files from visitors | .htaccess rules answer 404 for logs, wp-config backups, readme.html, license.txt, .git and .env. | Needs a server that reads .htaccess. On nginx, the row says so. |
| Stop publishing the WordPress version | Removes the version from the generator tag, feeds and asset addresses. | Plugin and theme versions stay. |
What can run
| Fix | What it changes | What it can affect |
|---|---|---|
| Disable XML-RPC | Answers xmlrpc.php with 403. The REST API is untouched. | The WordPress mobile app and Jetpack, if you publish through them. |
| Disable the dashboard file editor | Removes the plugin and theme code editors. | In the plugin’s words, “Files stay editable over SFTP and through your host.” |
| Stop PHP running in uploads | An uploads .htaccess rule answers 404 for PHP files there. | Needs a server that reads .htaccess. Images and documents are unaffected. |
What browsers are told
| Fix | What it changes | What it can affect |
|---|---|---|
| Tell browsers to refuse plain HTTP | Sends HSTS for Five minutes, to prove it works or six months. | A browser that saw six months keeps it after you undo. Start short. |
| Find out what a content policy would break | Sends a report-only content policy and lists what it would block. | Nothing is blocked. Start enforcing this policy waits for 7 days with no reports. |
| Send security response headers | Adds four standard headers, leaving any your server sends. | Another site that frames your pages stops showing them. |
Signing in
| Fix | What it changes | What it can affect |
|---|---|---|
| Change the sign-in address | Serves sign-in at your New sign-in address. wp-login.php answers 404. | Keep the address off the site. The recovery link restores the standard page. |
| Refuse application passwords | Refuses them for Accounts that can manage this site or Every account. Nothing is deleted. | Tools that sign in with one stop working. |
| Refuse passwords found in known breaches | Checks a new password against Pwned Passwords, sending five characters of its hash. | Signing in is never affected. |
| Keep low-privilege accounts out of the dashboard | Sends the roles you choose (Subscriber is preselected) from wp-admin to the front page, except their profile. | Never a role that can manage the site or has work in the dashboard. |
| Hide the dashboard from visitors | Signed-out visitors get a 404 at /wp-admin/. | admin-ajax.php and admin-post.php keep working. |
| Strengthen and rotate the sign-in keys | Mixes a strong secret into the keys that sign sessions, and adds Rotate keys now. | Applying, rotating and undoing all sign every other account out. |
Two pairs work well together. Change the sign-in address notes that /wp-admin/ still sends signed-out visitors to the new address, and suggests Hide the dashboard from visitors too. And Disable XML-RPC leaves application passwords working over the REST API, which Refuse application passwords covers.
Field-by-field details are in the Hardening guide.
Monitor first: try a fix on real requests
The preview cannot see your traffic. Monitor first can. It is offered for Disable XML-RPC and four sign-in fixes: Change the sign-in address, Refuse application passwords, Keep low-privilege accounts out of the dashboard and Hide the dashboard from visitors.
- Press Monitor first at the end of the row and choose a New observation window: 1 hour, 24 hours (preselected) or 7 days.
- Press Start monitoring with the fields above. Nothing is blocked while it watches.
- The panel counts what arrives, as “38 requests observed; 3 matched this rule.”
- When the window ends, press Enforce reviewed settings. It needs a working recovery link or printed recovery codes, and the normal undo still works.
Keep low-privilege accounts out of the dashboard adds Automatic undo for the first 24 hours, after 1, 5 or 10 signed-in denials. Keep undo manual is preselected.
Read the counts with care. As the panel says, matches show what the rule would affect, not proven breakage, and bots can add to them. Requests handled before WordPress are not counted, so an empty count proves nothing either.
For XML-RPC and application passwords, Preview the change also answers from your activity log, with a line such as “Nothing has used this in the last 30 days, which is as far back as this site’s log goes.”
Sign-in fixes check your way back in first
Applying a Signing in fix first checks for a working recovery link or an unused printed code, checked within the last day. If that fails, Check the way back in first opens with Check now or Open Recovery. Go ahead anyway is allowed, and is written to the activity log with the check that did not pass.
What undo cannot reach
Turning a switch off reverses the fix. Two effects reach beyond the site, and the fixes say so before you apply them:
- Strengthen and rotate the sign-in keys: people it signed out stay signed out until they sign in again. Rotate keys now has no undo.
- Tell browsers to refuse plain HTTP: a browser that saw the six-month setting keeps insisting on HTTPS until it expires. At five minutes, it forgets within five minutes.
Where to start
- Quick Setup’s five safe fixes: Turn off the file editor, Hide the WordPress version, Block directory browsing, Stop username discovery and Add security headers. See Install and set up.
- Findings with Apply fix: XML-RPC, the file editor, public user listing, the WordPress version and the missing headers. Worth doing first on the Overview lists up to three. See Score and findings and the checklist.
- The rest, one at a time: preview each, watch the ones that offer Monitor first, and apply them on a quiet day.
From WP-CLI or an AI assistant
wp bettershield harden lists every fix with its ID. wp bettershield harden xmlrpc --dry-run previews one, --user=admin applies it, and --undo reverses it. See WP-CLI commands.
A connected assistant allowed to make changes can apply seven fixes directly. The sign-in fixes, and taking any fix off, need a plan you agree to in the conversation. See Connect an AI assistant.
Common mistakes
- Turning on several sign-in fixes at once. If something stops working, you will not know which one did it.
- Starting HSTS at six months. Prove it at five minutes first.
- Doing the same job in two plugins. If a row says another plugin already does it, leave it to one of them.
- Reading a quiet Monitor first window as a green light. Read it with the preview, and choose a week for anything that connects now and then.
Frequently asked questions
Is WordPress hardening safe on a live site?
Every fix shows what it will change before you apply it, and turning the switch off reverses it, with the two limits above. Five fixes that can stop a tool or a person also offer Monitor first.
Do I have to apply all 16 fixes?
No. Each fix applies on its own, so choose the ones that suit your site. Some depend on your setup: the .htaccess fixes need a server that reads .htaccess, and HSTS needs an HTTPS address.
Does hardening change my files?
Three fixes write files: Stop uploads directories listing their contents adds blank index.php files, and Hide sensitive files from visitors and Stop PHP running in uploads add a marked block to .htaccess. Undo takes out what they added. The other thirteen work while WordPress runs and write no files.
What happens to the fixes if I delete BetterShield?
They stay applied by default, .htaccess rules included, so undo any you do not want first. Under Settings › General you can choose for deletion to remove BetterShield’s records instead, which also takes its server rules back off.
Conclusion
WordPress hardening works best as small steps you can see and reverse. Start with the fixes that cannot lock anyone out, close the findings that offer Apply fix, then watch the sign-in fixes on real traffic before you enforce them.
BetterShield is free on WordPress.org. The features page shows everything else it does.