WordPress security starts with reducing trusted code and privileged access. Renaming a login URL may reduce noise, but it is not a substitute for authentication, updates and monitoring.
Administrative baseline
- Give each administrator a separate account.
- Use unique passwords and MFA.
- Remove unused administrators, themes and plugins.
- Apply core and extension security updates promptly.
- Disable dashboard file editing when deployment does not require it.
Limit the blast radius
Use the lowest role that supports each job. Protect hosting, DNS, email and database accounts because WordPress cannot defend a stolen control-panel login.
Back up and monitor
Keep restorable copies outside the web root, review new administrator accounts and investigate unexpected plugin installation or file changes. Test restore steps before an incident.
Avoid plugin accumulation
Every plugin adds code and update responsibility. Choose maintained extensions with a clear purpose and remove rather than merely deactivate abandoned ones.
Protect automation credentials
Application passwords, deployment tokens and backup keys can bypass the interactive login. Inventory them, use dedicated users with only the required capabilities, revoke unused credentials after staff changes and never place them in public repositories. Core application passwords inherit user capabilities rather than offering independent per-password permission scopes.
Separate editing from hosting
Where practical, deploy code through a controlled process instead of editing production files in the dashboard. That creates reviewable changes and makes unexpected modifications easier to identify.
Keep recovery and access review operational
Keep day-to-day publishing separate from plugin and theme administration. Review rate controls, unusual login patterns and accountability for privileged changes. A security plugin can improve visibility but cannot compensate for abandoned extensions or an unpatched server.
Back up and prove restore before major changes. Confirm update sources and test important journeys after patching. Review application passwords and API integrations when staff responsibilities change.
Test recovery for the primary administrator, including loss of the usual mailbox or phone. Secure recovery codes offline and confirm the hosting provider's identity process before an emergency.