How to lock down WordPress admin access

Start by listing the people who genuinely need the WordPress dashboard and what each person must do. WordPress roles control capabilities such as publishing, moderating comments, managing plugins and changing settings, so do not give every account the Administrator role. Grant only the capabilities required for the job.

Check Users and remove old accounts, shared logins and unused administrator accounts. Use separate named accounts so you can revoke one person’s access without changing everyone else’s password. WordPress recommends using roles and capabilities rather than treating every user as an administrator.

Use long, unique passwords for administrator accounts and enable two-factor authentication through a reputable security or identity plugin. Keep WordPress, themes and plugins updated, because outdated software is a common route into a site. WordPress’s hardening guidance specifically recommends two-step authentication and regular updates.

Do not treat a changed login URL as your main protection. It may reduce casual scanning, but it does not replace strong authentication, limited privileges, updates and monitoring.

Add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php, above the line that says WordPress should stop editing. This removes the built-in theme and plugin editor from the dashboard, reducing the damage an attacker could do after gaining an administrator session.

This does not prevent malicious uploads or replace a firewall. It also means you must update files through your normal deployment, hosting or file-management process. WordPress documents this constant as a hardening measure.

For a simple site, a small site-specific plugin can redirect logged-in users who lack a chosen capability. The usual place to run this check is admin_init, and the check should use current_user_can() rather than comparing a role name. Exclude AJAX requests with wp_doing_ajax(), because admin-ajax.php can support front-end features for non-administrator users.

The logic is: if the current user lacks the required capability and the request is not AJAX, send them to a permitted front-end page or show an access-denied response, then stop execution. Keep the code in a custom plugin rather than a theme, so changing themes does not remove the restriction. The admin_init hook runs for admin screens as well as admin-ajax.php and admin-post.php, which is why the exclusions matter.

This manual route is fine when you have one clear rule, such as allowing only users with manage_options into the dashboard. It becomes awkward when different roles need different screens, redirects, exceptions or a settings interface.

If the site needs a second barrier, ask your host about password-protecting wp-admin/ or limiting it by VPN or IP address. Server-level protection sits before WordPress and can stop many automated requests before WordPress loads.

Test every front-end form, editor, checkout and logged-in feature afterwards. A blanket password rule on wp-admin/ can break admin-ajax.php, and some maintenance endpoints do not load plugins or themes, so a WordPress redirect cannot cover every URL. WordPress documents this trade-off in its hardening guidance.

Use a separate test account for each role. Confirm that administrators can sign in, editors can perform their assigned work, restricted users reach the intended page and logged-out visitors cannot access the dashboard. Also test media uploads, front-end forms, REST-powered blocks and any membership or ecommerce workflows.

Keep an administrator session open while testing. The common Friday failure is redirecting every admin request, including AJAX or a plugin’s required background request, then locking yourself out of the tools needed to fix it. If a redirect loop appears, disable the custom plugin through hosting file access or your host’s recovery tools, then inspect caching, security plugins and server rules.

If you need to hide dashboard sections, restrict wp-admin access for several user groups and redirect public pages while a site is being used mainly for management, MainWP Clean and Lock is a more convenient route than maintaining custom code. It is aimed at making a management site less visible and centralising these controls.

The manual approach is still a good choice for one straightforward capability check. Choose the plugin route when you need configurable restrictions, multiple sites or an interface that other administrators can maintain without editing PHP.