Security hardening, fifteen toggles, applied with one click.

Hardening is the other half of security, and it is the half that gets skipped because it produces no dashboard number. Detection tells you something happened. Hardening means it could not.

WordPress ships with defaults chosen for a decade-old web, where being immediately usable mattered more than being closed by default. Several of those defaults hand an attacker capability they have no legitimate need for on a typical site, and every one you remove is an entire class of attack that no longer has a route.

The classic example is the built-in file editor. It lets an administrator edit PHP directly from the browser, which means a stolen admin session becomes arbitrary code execution in about four clicks. Almost nobody uses it deliberately. Disabling it costs you nothing and removes the shortest path from a compromised login to a compromised server.

File editor lockdown removes in-browser PHP editing. XML-RPC control shuts down an interface that predates the REST API and is still routinely used for amplified brute-force attacks, where hundreds of credential guesses arrive in a single request and never touch your login form.

Directory listing prevention stops a misconfigured server from handing out a browsable index of your files, which is reconnaissance handed over for free. Version disclosure suppression removes the WordPress, plugin and theme version numbers that let an attacker match your site against a vulnerability list without touching it.

User enumeration blocking closes the endpoints that turn author archives and the REST API into a list of valid usernames. It is not a vulnerability on its own, it halves the work of a credential attack, which is quite enough reason to close it.

Hardening advice usually arrives as a list of things you should switch on, with no mention of what switching them on costs. Then something breaks two weeks later, nobody connects it to the security plugin, and the whole set gets turned off.

So each toggle explains what it changes and what depends on it before you enable it. XML-RPC is the honest example: disabling it is right for most sites and wrong for a few, because the Jetpack plugin and the official WordPress mobile apps use it. That should be your decision, made in advance, rather than a support ticket.

Hardening arrives at Basic, alongside login protection, because they solve the same problem from two directions: one removes the capability, the other protects the door. Neither replaces scanning, which stays free.