Harden WordPress security across the sites you manage

Reduce avoidable WordPress login exposure

Login lockouts reduce repeated guessing. Hiding detailed login errors and restricting common username discovery paths make account information less convenient to probe. Strong-password controls apply when supported publishing accounts set or change their passwords. They do not change existing passwords for you.

Sentinel also supports controls for reserved usernames and XML-RPC access. Review the selected policy rather than assuming every protection level enables the same controls. A website that needs a service should have a deliberate exception, not an accidental outage.

Restrict code changes and execution where appropriate

Removing the plugin and theme editors from wp-admin reduces one route for changing code after an account compromise. It does not prevent every file upload or every way an attacker could execute code. Existing server configuration can also take precedence over the setting.

The uploads protection aims to stop PHP running from the media library. The website verifies whether the server honors the rule. A host that ignores the rule needs equivalent server configuration; an enabled switch alone should never be read as protection. Pair this with file integrity monitoring.

Review integration access separately

Application-password and REST API restrictions have separate compatibility implications. They are not a reason to disable every API on every website. A backup service, publishing app, form or page builder may need access that a broad restriction would remove.

Use approved-address exceptions only when they fit the website architecture and test its normal workflows after a change. The REST access restriction is intended for suitable sites behind Cloudflare; it can break visitor features on other sites. Keep vulnerability scanning, updates and backups alongside hardening.