How To Limit Dashboard Access With BetterShield?
Send subscribers, customers and other low-privilege accounts from wp-admin to the front page while they keep their own profile, and trial it first.
In BetterShield, subscribers and a store’s customers have no work in wp-admin. Dashboard lock for customers and subscribers sends them to the front page when they ask for a dashboard screen, while they keep their own profile, where their password, two-factor and signed-in devices are. It is under Signing in on BetterShield › Protection › Login & Access, and it starts off.
What it does
- Redirects the chosen roles to the front page from any dashboard screen except their own profile, where they can still change their password, manage two-factor and end a sign-in they do not recognize.
- Leaves admin-ajax.php and admin-post.php working, which front-end features rely on while someone is signed in.
- Hides the admin bar for those accounts on the front end. It still shows on their profile screen.
- Never applies to an account that can manage this site or BetterShield, or to a super admin, checked on every request.
- Never applies to an account with work in the dashboard: one that can edit posts, upload files, list users or moderate comments, even when it also holds a chosen role. An editor who also became a customer keeps the dashboard.
Signed-out visitors are not affected; Hide the dashboard covers them. Safe mode pauses this fix, and it stops while BetterShield is deactivated.
Step 1: Open BetterShield › Protection › Login & Access
Open BetterShield › Protection › Login & Access and find Dashboard lock for customers and subscribers under Signing in.
Step 2: Keep subscribers and customers out of the dashboard
- Under Which accounts to keep out, tick the roles to keep out; you can tick more than one. Only roles with no work in the dashboard are listed, usually Subscriber and, on a store, Customer.
- Press Preview the change. Its first line says how many accounts it reaches, as “Send 240 accounts home when they ask for a dashboard page other than their own profile.”, leaving out every account the fix never applies to. Nothing changes.
- Turn the switch on. The row names the roles, with On since and Undo never expires.
| Option | What it does | Default |
|---|---|---|
| Which accounts to keep out | The roles sent to the front page, one or several. Roles with work in the dashboard, or that can manage the site, are not offered. | Subscriber |
The choice is hidden while the fix is on. To change it, turn the fix off, choose again and turn it on.
Before it applies
Like every Signing in fix, applying it first checks your way back in: a working recovery link or unused recovery code, checked within the last day. If that fails, Check the way back in first offers Check now (or Open Recovery) and Go ahead anyway, which is logged. See Set up recovery. Applying needs a signed-in browser, not an application password.
Monitor first
Monitor first, at the end of the row, counts real dashboard requests without sending anyone away: each one is observed, and it is matched when it came from an account in one of the chosen roles asking for a page other than its profile.
- Tick the roles, then a New observation window (1 hour, 24 hours, which is preselected, or 7 days), and press Start monitoring with the fields above.
- The panel reads, for example, “310 requests observed; 4 matched this rule.” End monitoring now stops early.
- When the window ends, choose Automatic undo for the first 24 hours (below), then press Enforce reviewed settings. It applies the roles saved with the window, needs a usable recovery link or recovery codes and safe mode off, and leaves the usual undo. Like the switch, it first checks your way back in: if that check fails, Check the way back in first opens, and Go ahead anyway is logged.
Checkout traffic is not counted. Counts are kept for a week after the window ends.
Automatic undo for the first 24 hours
When you enforce from Monitor first, this fix alone also offers Automatic undo for the first 24 hours: Keep undo manual (the default), or Undo after N authenticated denials with 1, 5 or 10. For 24 hours after you enforce, each time a signed-in account in one of the chosen roles is sent home counts once, and at your number BetterShield undoes the fix. Signed-out visitors cannot trigger it, but a restricted account can, so the panel suggests it only while testing. It runs with the site’s scheduled tasks, so the undo can come late, and it waits while you lack permission to manage BetterShield, have no usable recovery link or codes, or safe mode is on. Once it acts, the panel reads “Automatically undone after the selected denial threshold”.
From WP-CLI
wp bettershield harden admin_area_access --dry-run
wp bettershield harden admin_area_access --roles=customer --user=admin
wp bettershield harden admin_area_access --roles=subscriber,customer --user=admin
Several roles go in one --roles, separated by commas. Without --roles, it keeps Subscribers out. The command runs the same check of your way back in as the screen: if it fails, the command stops and says why, and adding --force goes ahead anyway, which is recorded in the activity log. A connected AI assistant can only propose this fix, as a plan you agree to. See WP-CLI commands.
Recommended settings
We recommend it on any site where people register for an account: everything they need is on the front end and their profile.
| Site | What we recommend |
|---|---|
| Blog or brochure site | Subscriber, if anyone can register. With no registered readers it has nothing to do. |
| Store (WooCommerce) | Customer. The row notes that WooCommerce already sends customers to its own account page; applying this as well is safe, but check where a customer lands afterwards. |
| Membership or course site | Your members’ role, if it is listed. Run Monitor first for 24 hours to see whether members reach the dashboard for anything. |
| Agency or many sites | Run Monitor first for 7 days on a client site before enforcing, with automatic undo only while you are watching. |
What it can break, and how to undo
- Links and screens in the dashboard. A link that takes a signed-in member to a dashboard page other than their profile now takes them home, and a dashboard screen a plugin built for members is out of their reach.
- The admin bar is gone for those accounts on the front end; it still shows on their profile screen.
- WooCommerce or bbPress. With either active, the row says it already keeps customers out of the dashboard, and whichever runs first decides where they land.
To undo, turn the switch off. Everyone reaches the dashboard as before. Undo needs a signed-in browser, and your password if Ask for my password before removing a protection is on. From the terminal: wp bettershield harden admin_area_access --undo --user=admin.
Final Outcome
A test account. Sign in as an account in a chosen role and open yoursite.com/wp-admin/: you land on the front page, with no admin bar. yoursite.com/wp-admin/profile.php still opens.
- The row. The roles’ names, and “This one has no effect a page view can check, so it is reported from your settings.”
- The activity log. “Hardening applied” and “Hardening undone” name the fix, including an automatic undo. Each Monitor first start, stop or enforce is “Setting changed”.
- Findings. No finding opens while it is off. While it is on, Some protections that are switched on are not working (Medium) names it if it reads as on but is no longer in force, for example because another plugin took it off.
On multisite
Each site has its own switch, and the role list shows that site’s roles. A super admin is never kept out.
Related
This is how you can limit dashboard access with BetterShield.
Getting Stuck? Feel free to contact our Dedicated Support Team.